Re: [v3] libstdc++/12854

[Benjamin Kosnik <bkoz at redhat dot com>]

>-Weffec++ is awful.  

-Weffc++ is useful. It's useful for other people, developing with g++,
who use a more object-orientated style. Remember, C++ is supposed to be
multi-paradigm....

It's even useful for libstdc++ maintainers. Had we been able to use if
for 3.2, we would have found the missing virtual in the io hierarchy.

Look, I'm not saying that it's perfect (I wish it had finer
granularity), or even that all the warnings are appropriate for
libstdc++ (they are not). However, I think that getting this working, or
closer to working, is something that should be pursued.

>There is at least one case of the changes that makes me very uneasy
>because it hurts performance for no perceived benefit: The change to
>__normal_iterator. 
>
>Declaring copy-constructor for __normal_iterator *is* a hurting
>pessimization: 
>The compiler is no longer going to treat it as "normal" C-struct and
>pass it in register on plateforms (like PowerPC) it fits in a
>register. Instead, return-values or function arguments of that type
>would unconditionally be pushed on stack. That would be a step to make
>our std::vector<T>::iterator more inefficient.  It hurts effort
>like ADDRESSOF, designed precisely to remove the "abstraction penalty"
>in putting simple data in structs like __normal_iterator.

I don't this is the case any more. 

I was under the impression that tree-ssa would scalarize even C++
objects with 2-8 members. I've asked rth for clarification, but maybe
jason would know this too.

>I think, only people who insist on -Weffec++ should pay for that
>inefficiency.  Usually, they're concerned with a kind of codes where
>everything is passed by reference.  We cannot not assume that our
>implementation of STL is going to be used only in those specific
>cases. 

Using -Weffc++ with libstdc++ without these patches is pretty much
impossible.

If there is indeed an inefficiency, I'll strip that part out.

-benjamin