l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:11

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] C++ static checker
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] C++ static checker

On Tue, 9 Oct 2001, Peter Jay Salzman wrote:

> begin: Jeff Newmiller <jdnewmil@dcn.davis.ca.us> 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.

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:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.