[v3 PATCH] Implement C++17 string searchers.

Jonathan Wakely jwakely@redhat.com
Mon Sep 12 16:21:00 GMT 2016


On 12/09/16 18:55 +0300, Ville Voutilainen wrote:
>On 12 September 2016 at 18:49, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>> Is there a reason I didn't use an alias template or variable template
>>>> here?
>>>>
>>>>  template<typename _Pred>
>>>>    using __is_std_equal_to = is_same<equal_to<void>, _Pred>;
>>>>
>>>> That avoids defining a new class template.
>>>
>>>
>>> I don't know whether that's a practical difference, the alias is
>>> shorter of course.
>>
>>
>> It's considerably lighter in terms of compilation cost. Defining a new
>> primary template adds more overhead than an alias template that uses
>> an already defined template.
>
>Sure, I'm wondering how much lighter in practical terms. Let's chalk

Enough to be worth changing.

>this up as an improvement
>that we can do once we have the promised better tests. :)

Sure.

>>>>> +         return std::make_pair(__first_ret, __second_ret);
>>>>
>>>>
>>>>
>>>> This could be simply return { __first_ret, __second_ret };
>>>
>>>
>>> That doesn't mean exactly the same thing. I can potentially concoct
>>> evil code for which the result
>>> is different with such a return and make_pair.
>>
>>
>> While you certainly know the pair constructors better than I do, I
>> don't think you can for a valid iterator type. Please don't waste your
>> time trying though :-)
>
>Again, let's do this with better tests at hand. Also, I think it's
>reasonable to do a quick walk
>over our library and see whether we have unqualified make_pairs and
>make_tuples somewhere,
>because those are subject to ADL. In this particular case, it may well
>be reasonable to just
>not use make_pair, but it should be ok for now, as in I will not lose
>sleep over it in the short term. :)

include/bits/regex_compiler.h: _M_range_set.push_back(make_pair(_M_translator._M_transform(__l),
include/experimental/memory_resource:   { return tuple_cat(make_tuple(allocator_arg, *(__ua._M_a)),
include/experimental/memory_resource:   { return tuple_cat(std::move(__t), make_tuple(*(__ua._M_a))); }
include/parallel/algobase.h:          return make_pair(__res , __begin2 + (__res - __begin1));
include/parallel/algobase.h:          return make_pair(__res , __begin2 + (__res - __begin1));
include/profile/impl/profiler_trace.h:        __stack_table.insert(make_pair(__stack,

That seems to be all of them. The memory_resource ones are definitely
bugs, and the tuple_cat calls there should be qualified too. I didn't
check if the others use program-defined types that could find
different functions via ADL, but it wouldn't hurt to qualify them
anyway.




More information about the Libstdc++ mailing list