Gilles Detillieux's bits of Fri, 6 Sep 2002 translated to: >This is what I really hate about C++! So many of the so-called standard >classes aren't really that standard, and vary from one implementation to >another, and one release to another. How intuitive is this? bad() is >not to be taken as an antonym of good()? If what you're saying is true,
No argument. The naming leaves a lot to be desired in this case. Also the inconsistency in what the accessors do. eof() and bad() check only eofbit and badbit, respectively. fail() checks failbit *and* badbit (for historical purposes, according to a footnote). good() essentially checks all three, ensuring that none are set. >then 3.1.x's htlib/Configuration.cc code will also bomb if it can't open Yes, it will ;) I just verified this with htnotify. However for htnotify it is only an issue if -c is used, since configFile is set to DEFAULT_CONFIG_FILE by default. From what I can tell, all of the other programs are protected from this problem by a call to access() (and then reportError() if access() fails), which precedes the calls to Configuration::Read(). >the config file. So, just how standard is the behaviour you describe? Based on my experience, it is standard behavior; however I of course won't claim that that experience covers the majority of possible compiler/OS combinations. Inconsistency and naming issues aside, the standard is crystal clear in terms of specified behavior, so there is really no good excuse for a non-compliant implementation. >If we start using in.good() in htnotify.cc and Configuration.cc, instead >of !in.bad(), will the code work correctly on all supported platforms, >or will it start to bomb on some of the systems where !in.bad() used to >work fine? Do we need configure tests for all this nonsense? I would argue that any compiler that is unable to handle such a change is very much broken in this regard. For whatever it is worth, my suggestion would be to add an access() call to htnotify in the 3.1.x branch, as implemented in the other programs, and then migrate from !bad() to good() in the 3.2.x branch. I think the access() call will be enough to protect htnotify from an invalid config file argument and at the same time minimize the amount of code that needs to be touched. If there are any platforms for which configure tests are needed, hopefully that will get flushed out in the 3.2.x betas. >but I can't find any information on what the distinction is between >badbit and failbit. Is this consistent across all platforms? If so, Again based on my own experience, it is consistent. As for the distinction between the two bits, my understanding is that badbit is used for cases where the stream encounters a problem so severe that all bets are off; there is no reasonable recourse other than abandoning the stream object altogether. On the other hand, the failbit indicates that some sort of stream related failure occurred, but that recovery is not out of the question; in most cases it should be possible to clear the bit, put things back to some known state, and then continue (e.g. clear the bits, call ifstream's open using a different file name, and continue). Jim ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
