This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: can we rename vec<>.safe_push() to vec<>.push()?
Richard Biener <richard.guenther@gmail.com> writes:
> On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> So.... ok to default to a lazy one, or are suggesting we leave things
>> as they are?
>
> Either leave as-is or default to the lazy one.
FWIW, I think we should leave it. The risk isn't just laziness:
it could make quick_push sound more like a niche operation for
special cases, rather than the one we want to use where possible.
Like you say, it's useful to force people to make the choice.
It's like forcing the choice between ordered_remove and unordered_remove
(which I think we should keep too).
Thanks,
Richard
>
> Richard.
>
>> Aldy
>>
>> On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>>>> I understand the need for .quick_push(), when we know the size of the
>>>> allocated elements before hand, but do we really need to call the
>>>> common variant safe_push? Can't we just call it push()?
>>>>
>>>> Or is there some magic C++ rule/idiom that prohibits us from doing this?
>>>>
>>>> I volunteer to provide a patch if y'all agree.
>>>
>>> I think having quick_push and safe_push makes you think which one to use
>>> while push would be the obvious lazy one. Aka nobody thinks of
>>> pre-allocating
>>> stuff and using quick_push anymore.
>>>
>>> Just my 2 cents...
>>>
>>> Richard.
>>>
>>>> Aldy