On Wed, Apr 25, 2012 at 10:28 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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 is. 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