Re: Warning on C++ catch by value on non primitive types

[Thomas Costa <tcosta at ovro dot caltech dot edu>]

On 13 Oct 2005, at 7:41 AM, Benjamin Kosnik wrote:

> > yeah, if it were in one of those books it could be added to the - 
> > weff-c+
> > + option. It doesn't seem sensible to add a different option for an
> > alternative (set of?) coding rule(s).
>
> FYI this is item 13 in MEC++.

It is on just about any decent modern C++ coding guide/list somewhere.

> I think this would be a good error to have. My suggestion is to  
> file an
> enhancement request in gcc bugzilla, with this code:
>
> #include <stdexcept>
>
> void
> foo()
> {
>   try
>     {
>     }
>   catch (std::logic_error e)
>     {
>     }
> }
>
>
> saying that with -Weffc++, you want a warning. Include a link back to
> this thread, so that who-ever works on this can read the initial
> reaction and the suggestion by Nathan to hook into  
> finish_handler_parms.

Yes, thanks for all the feedback.
I will look at the code mentioned earlier.

> In the near past, Giovanni has done a good job of enhancing the More
> Effective C++ rules. If you ask nicely, maybe he'd do the same for  
> this.

That would be great and I will ask very, very nicely and offer to  
help any way I can however...
I didn't want this totally tied to -Weffc++ unless there was also a  
separate switch for turning it on/off because:

1.) Last time I checked g++'s own standard library headers did not  
pass -Weffc++ cleanly and hence I couldn't get a clean build of my C+ 
+ code using -Weffc++.
2.) A lot of other 3rd party C++ headers including the last version  
of Boost I was using (admittedly a relatively old version, maybe  
version 1.30) didn't pass -Weffc++ cleanly.
3.) People have many times debated the validity/usefulness of some of  
the warnings that -Weffc++ produces and I think it's better to have  
individual switches for each warning in -Weffc++ and then -Weffc++  
just becomes a batch switch that turns on the individual switches en  
masse.


> best,
> benjamin