Boost logo

Boost :

Subject: Re: [boost] [type_traits] has_equal_to< std::vector<T> > always true_
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-10-21 11:38:45

Vicente Botet wrote:
> Le 20/10/11 17:09, Jeffrey Lee Hellrung, Jr. a écrit :
>> On Thu, Oct 20, 2011 at 7:55 AM, lcaminiti&lt;lorcaminiti@&gt; wrote:
>>> Hello all,
>>> has_equal_to< std::vector<T> > always returns true_ because == is
>>> defined for std::vector<T> even when it is not defined for T. However,
>>> then an attempt to compare for equality std::vector<T> will generate a
>>> compiler error in this case because there is no == for T.
> <snip>
>>> Shall has_equal_to< std::vector<T> > be smarter and return false_ if
>>> T does not have == ? (If not, this case should at least be documented.)
>> I'd venture to say this is a deficiency in std::vector's implementation
>> of
>> operator==, which ideally should SFINAE-out bindings of T which do not
>> have
>> an operator==.
> <snip>
>> In my opinion, the upshot is that std::vector's operator== is almost
>> certainly not a special case, so I don't know know if it's worth
>> specializing has_equal_to on it or not. Maybe, if it's consistently done
>> for all problematic std-defined operators?
> Hi,
> I found the same kind of issues while implementing
> is_constructible/is_assignable/is_convertible for Boost.Conversion. The
> option I taken was to specialize these traits for the c++
> implementations that were not using SFINAE. This force of course the
> user to include the specific file containing the specialization.

Would the Boost.TypeTraits authors consider adding the specializations* to
workaround STL not using SFINAE? If not, can these cases be documented?

(*) In this case it'd be nice to name the headers containing the extra
specialization consistently with other Boost libraries like
Boost.Conversion-- Vicente, how did you name the headers containing the
specialization for the STL types?


View this message in context:
Sent from the Boost - Dev mailing list archive at

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