On Tue, 9 Oct 2001, Peter Jay Salzman wrote: > begin: Jeff Newmiller <[EMAIL PROTECTED]> quote > > On Tue, 9 Oct 2001, Peter Jay Salzman wrote: > > > > > i came across a post on deja.com that mentioned the -Weffc++ switch (which > > > doesn't seem to be documented in the man or info pages). > > > > > > apparently, this is a set of warnings about coding style that violates scott > > > meyer's "effective c++".
[...] > > It is cool to learn about this switch. However, it looks like it may > > require some patience to use, because it found dozens of issues in the GCC > > libraries but none in my code when I tried it out. :) > > the message that i learned about the switch from was actually a complaint > about the libraries generating tons o' errors. > > > Whether any or all > > of those warnings are justified will take some time to evaluate. > > if you make any conclusions, please post 'em! FSF disclaims responsibility, citing issues in the spec. http://gcc.gnu.org/onlinedocs/libstdc++/faq/#4_4_Weff However, I see some odd things being pointed out by the warning switch in both the implementation-specific and standard portions of the library, so I am not convinced this disclaimer is entirely justified. An example of a standard violation is that back_insert_iterator<Container>::operator++(int) is supposed to return a copy of *this by value, but it returns a reference to *this instead. If a program expects to be able to modify that return value without modifying the original iterator then it will fail. An example of unnecessarily ignoring the warning in implementation code (where design flaws in the Standard should not force them to exist) shows up in the implied downcast from ostream& to _IO_istream_withassign& in operator=(_IO_ostream_withassign&). While this won't directly cause program malfunction, downcasts should not be implied for reasons of documentation and of design robustness. Most of the warnings are about code that probably works but is dubious, or about lack of proper support for copying stream objects. FSF makes the valid case that copying streams is not a good idea, but I don't see why they cannot resolve the warnings anyway by adding the appropriate copy support member functions. --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k ---------------------------------------------------------------------------
