Per Barney:

Post #165,158 by jb4 7/20/04 11:48:04 AM Reply	Per Barney: Conversion to a C-style string could have been provided by an operator const char () rather than c_str(). This would have provided the convenience of an implicit conversion at the cost of surprises in cases in which such a conversion was unexpected. --The C++ Programming Language -- Special Edition* Bjarne Stroustrup. So there you have it! The Framers were trying to protect you from youself. Just like Java! Rejoice and be glad in their thoughtfulness! ;-\ufffd (For what it's worth, I don't like it either!) So here's a suggestion: With all the wry (or rye) sarcasm you can muster, helpfully point out to the class the thoughtful parochialism of the Framers, and then suggest the creation of a derived sString class, (for smart String) that defines an overload of operator const char (), and strongly suggest (read: demand) that this derived class be used in all your assignments. It would extend your class's understanding, and would give some useful metrics on how often (or whether) such parochialism was a hindrance as opposed to a help. (I suspect I know what these metrics will show, but real-world numbers trump my suspicions any day of the week and twice on Sunday!) jb4 shrub\ufffdbish* (Am., from shrub* + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf.* BULLSHIT
Post #165,160 by deSitter 7/20/04 11:54:06 AM Reply	It's stupid Idiomatic expressions should work without handsprings. They used to, in the "better C" days. -drl
Post #165,181 by tuberculosis 7/20/04 1:55:04 PM Reply	No, I agree with the decision to avoid the op const char*. Although I think leaving it out is a violation of the design philosophy of C++, which as far as I can tell is to follow "The Principle of Most Surprise". OTOH, I think its totally stupid to have a whole chunk of streams library implemented in terms of string ([io]stringstream) and then not have a ctor for [io]fstream that allows you to use the string. That was lovely cheese. --Wallace, The Wrong Trousers
Post #165,187 by jb4 7/20/04 2:35:09 PM Reply	Agreed...but...but... Yes, the [io]fstream most assuredly should support a string constructor (and a wstring constructor, as well). But don't you know that the [io]fstream stuff was supposed to be a "better stdio that stdio?", and so thererfore would have to support analogs to stdio's [f]open? Maybe they just took the analogs a bit too literally. Besides, I think what really happened is that in pre-ANSI stream libraries, there was no string class (at least, not a standardized one that anyone could count on being there); instead, there was a mish-mosh of non-standardized ASCII character containers, many of which were called string. By allowing the one true string class to be used as an option, it could well have broken existing compilers implementations of their proprietary garbage. Both X3J11 (ANSI C) and X3J16 (ANSI C++) committees went through hoops to try to minimize breakage of existing code (IMHO, to the detriment of both languages), and it was probably thought that the risk of breakage was too great. I would expect that C++ V2.0 would fix this rather egregious omission, and to hell with anybody's code that it breaks! jb4 shrub\ufffdbish (Am., from shrub* + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf.* BULLSHIT

Welcome to IWETHEY!