On 12/09/16 18:55 +0300, Ville Voutilainen wrote:
On 12 September 2016 at 18:49, Jonathan Wakely <jwak...@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.
