From -5513593717525070343 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e4a62c2078e2e9a2 X-Google-Attributes: gidf78e5,public From: david@kai.com (David C. Nelson) Subject: Re: basic_ifstream<>::open() Date: 1998/06/05 Message-ID: #1/1 X-Deja-AN: 359930664 Approved: Fergus Henderson References: <6l4gej$3sr$1@shell7.ba.best.com> <6l848e$ghb$1@shell7.ba.best.com> X-Original-Date: 05 Jun 1998 11:29:47 -0500 NNTP-Posting-Date: 5 Jun 1998 16:29:51 GMT X-Trace: news10.ispnews.com 897064191 6319 206.148.222.50 (5 Jun 1998 16:29:51 GMT) Organization: ISPNews http://ispnews.com X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANXhQlOEDnX0m9pzZAQGGxQF7BmgtpZ8J24wNhg4UBPmHLr9dY5h7NEvp 1jYe5riUai9QOuVPy2Mj6UXAeaZ0RPjr =WT5h Newsgroups: comp.std.c++ Now that we've talked round the problem back into the inheritance tree, lets get back to the specific derived class, basic_ifstream. It derives from basic_istream and has its own file based stream buffer. My original inquiry related to its open() and close() methods. These methods are not available in any other stream class. I just checked a copy of the cfront library source for fstream, I see that upon success of open, close, attach and setbuf it did a clear(0). So was it intended that this bit of functionality was removed from the fstream family? We can discus the philosophy of the design until we're blue in the face, but at some point we have to own up to the question, did we intend to break the user's code? -- #include Kuck and Associates David Nelson (david@kai.com) 1906 Fox Drive http://www.kai.com/C_plus_plus/_index.html Champaign, IL 61820 KAI C++ - Cross Platform C++ Compiler (217) 356-2288 ext 36 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]