Boost logo

Boost :

Subject: Re: [boost] [type_traits] has_equal_to< std::vector<T> > always true_
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-25 14:17:35

On Wed, Apr 25, 2012 at 10:28 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 25/04/12 15:02, lcaminiti a écrit :
>> Frédéric Bron wrote
>>> Were these traits specialized for the STL in any of the latest Boost
>>>> releases?
>>> don't think so.
>>> Do I have permission to add the specializations for STL containers to
>> trunk
>> and then the to release 1.50?
>> 1) I'd add something like this for each STL container that defines an
>> operator==:
>> template< typename T, class Alloc = std::allocator<T> >
>> struct has_equal_to< std::vector<T, Alloc> > : has_equal_to<T> {};
>> 2) I'd add similar specializations for all traits that apply !=,<=, etc.
>> 3) I'd add the specializations in the trait header
>> type_traits/has_equal_to.hpp, etc and not into special headers
>> type_traits/std/vector.hpp, .etc (because when I use has_equal_to on
>> std::vector I'd always expect it to work according to the specialized
>> version as a user and achieving expected behavior should require no extra
>> user step like including type_traits/std/vector.hpp).
>> I'm happy to change the code, check the regression tests, and I don't
>> think
>> any documentation needs to be changed (because the specializations just
>> make
>> the traits work as the user expects them to work).
>> What do you think?
> Why do you need to specialize this trait for STL containers? Do you mean
> that has_equal_to doesn't work for them? if no why?
> Sorry if this is something obvious.

As far as I've gathered, typical STL implementations won't "guard" the
declaration of vector's operator== with something like Boost.EnableIf, so
vector<X> is always reported as having an operator== regardless of what X

Lorenzo: I would be slightly more in favor of keeping the std::
specializations for has_* in a separate header, similar to how
Boost.Fusion's adaptation framework for, e.g., std::pair is in a separate
header. I sympathize with your reasoning though so I could go either way.

- Jeff

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