Re: [Patch] libstdc++/23425

[Paolo Carlini <pcarlini at suse dot de>]

Howard Hinnant wrote:

> I don't have contrary opinion, just a note that we need more of this.
>
> clear() is best not thought of as a special case of erase().  It is 
> best thought of as a special case of a private function which I'll call:
>
> void __erase_at_end(size_type n);
>
> Erases the last n elements from the vector.  This is needed in the 
> following public members of vector:
>
> All forms of assign.
> All forms of erase.
> All forms of resize.
> clear.
>
> I haven't studied it thoroughly yet but because of the structure of 
> this implementation of vector, the following variant might be 
> slightly more efficient:
>
> void __erase_from(T* p);
>
> where everything in [p, end()) gets erased.
>
> Given such a private helper, we can optimize it just as you show for 
> clear, but then propagate that optimization around to all of these 
> other places in vector too.  clear() then becomes a trivial inline:
>
> void clear() {__erase_from(this->_M_impl._M_start);}
>
> All that being said, I have no objection to the patch as is for now.  
> This is just a note of a direction that I think would be good to take 
> in the future.

Thanks: this is certainly something we can work on for 4.2, I'm going to
file an enhancement PR in order to make sure we don't forget.

> On the issue of inlining, and I'm speaking from an standpoint of 
> great ignorance here, it could well be that __erase_from is a 
> function that we want inlined if it is optimized (i.e. when the 
> destructor is trivial), and not inlined if it is not optimized.  We 
> can overload __erase_from on tr1::has_trivial_destructor<T>::value, 
> inlining for true and not for false.
>
> Before we do that though we need to improve has_trivial_destructor 
> with compiler knowledge about the type.  Right now it just rings true 
> for scalars and that is far too restrictive for prime time use.

Yes, indeed today I was coming to the same conclusions:
has_trivial_destructor would be handy in order to be very accurate wrt
inlining, we can improve a lot in that area.
Unfortunately I don't think there is ongoing work to improve compiler
support to type_traits, in general. Are you aware of any? Or maybe Apple
is interested?

(aligned_storage is a special case, the only one well known, probably:
see the PRs mentioned in type_traits)

Paolo.