std:vec for classes with constructor?

Jonathan Wakely jwakely@redhat.com
Thu Aug 6 10:48:35 GMT 2020


On 06/08/20 12:31 +0200, Richard Biener wrote:
>On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>>
>> On 06/08/20 06:16 +0100, Richard Sandiford wrote:
>> >Andrew MacLeod via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>> >> On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote:
>> >>> On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor <mjambor@suse.cz> 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?
>> >>> It's definitely not what we want. You have to find another solution to this problem.
>> >>>
>> >>> Richard.
>> >>>
>> >>
>> >> Why isn't it what we want?
>> >>
>> >> This is a small vector local to the pass so it doesn't interfere with
>> >> our PITA GTY.
>> >> The class is pretty straightforward, but we do need a constructor to
>> >> initialize the pointer and the max-size field.  There is no allocation
>> >> done per element, so a small number of elements have a couple of fields
>> >> initialized per element. We'd have to loop to do that anyway.
>> >>
>> >> GCC's vec<> does not provide he ability to run a constructor, std::vec
>> >> does.
>> >
>> >I realise you weren't claiming otherwise, but: that could be fixed :-)
>>
>> It really should be.
>>
>> Artificial limitations like that are just a booby trap for the unwary.
>
>It's probably also historic because we couldn't even implement
>the case of re-allocation correctly without std::move, could we?

I don't see why not. std::vector worked fine without std::move, it's
just more efficient with std::move, and can be used with a wider set
of element types.

When reallocating you can just copy each element to the new storage
and destroy the old element. If your type is non-copyable then you
need std::move, but I don't think the types I see used with vec<> are
non-copyable. Most of them are trivially-copyable.

I think the benefit of std::move to GCC is likely to be permitting
cheap copies to be made where previously they were banned for
performance reasons, but not because those copies were impossible.



More information about the Gcc-patches mailing list