Boost logo

Boost :

Subject: Re: [boost] [type_traits] has_equal_to< std::vector<T> > alwaystrue_
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-10-22 06:18:00

Le 22/10/11 10:25, John Maddock a écrit :
>> Thanks for highlighting this major issue. I understand that there is
>> nothing to do apart from specializing the traits for those particular
>> std classes. This would however not work with user classes. As the
>> beta is due on Monday, I believe it is too short to submit a working
>> and tested patch. Maybe once the beta is out, you can start to work on
>> a proposed contribution?
>> Meanwhile, as suggested I will add a warning in the doc.
> It's a tricky one, because strictly speaking vector<T> always does
> have an equality operator - it's just that depending upon T it may not
> compile :-(
> There's no general solution to this, because there's no way in the
> language to test whether something does or does not compile - we can
> only test whether it's declared or not.

I'm not sure I understand the standard correctly. The standard says
container requirements "Requires: T is EqualityComparable".

Does this means that the operator== must not participate in overload
resolution when the requirements are not meet, or that the compilation
will fail?
IMO, it is the first. In other parts of the standard the wording is more
explicit. For example in the chrono part, every function that has some
constraints in the template types, state something like:

"Remarks: This operator shall not participate in overload resolution
unless Rep2 is implicitly convertible to CR(Rep1, Rep2)."

The same kind of wording is found for std::pair:

template<class U, class V> pair(const pair<U, V>& p);
Requires: is_constructible<first_type, const U&>::value is true and
is_constructible<second_- type, const V&>::value is true.
Effects: Initializes members from the corresponding members of the
Remark: This constructor shall not participate in overload resolution
unless const U& is implicitly convertible to first_type and const V& is
implicitly convertible to second_type.

I don't know if the standard is not enough precise respect to the
operator== for container, but this merits clarification anyway.


Boost list run by bdawes at, gregod at, cpdaniel at, john at