std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

[Richard Biener]

On August 5, 2020 5:41:01 PM GMT+02:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>On 8/5/20 5:09 PM, Martin Jambor wrote:
>
>> On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote:
>>>
>> 
>> [...]
>> 
>>>
>>> * ipa-cp changes from vec<value_range> to std::vec<value_range>.
>>>
>>> We are using std::vec to ensure constructors are run, which they
>aren't
>>> in our internal vec<> implementation.  Although we usually steer
>away
>>> from using std::vec because of interactions with our GC system,
>>> ipcp_param_lattices is only live within the pass and allocated with
>calloc.
>>>
>> 
>> Ummm... I did not object but I will save the URL of this message in
>the
>> archive so that I can waive it in front of anyone complaining why I
>> don't use our internal vec's in IPA data structures.
>> 
>> But it actually raises a broader question: was this supposed to be an
>> exception, allowed only not to complicate the irange patch further,
>or
>> will this be generally accepted thing to do when someone wants to
>have a
>> vector of constructed items?
>
>I don't want to start a precedent without further discussion, so let's 
>assume this was an exception.
>
>Is there another objection to std::vec<> other than it doesn't play
>well 
>with our GC?  Is GCC's vec<> that much faster/efficient than
>std::vec<>? 
>  Does it matter?
>
>I will note that an alternative would have been to rewrite our 
>internal's vec<> implementation so that constructors are run.  We 
>explored that, but it seemed like more work than it was worth.
>
>Andrew, do you remember the details on the C++ness issues with GCC's 
>vec<> implementation?

Note we generally want to avoid memory allocations per element so can't you use a value_range<1> or so to make it POD? 

Richard. 

>Aldy