Le 20/10/11 17:09, Jeffrey Lee Hellrung, Jr. a écrit :
On Thu, Oct 20, 2011 at 7:55 AM, lcaminiti<lorcaminiti@gmail.com> 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. BTW Ion, it seems that your implementation on Boost.Container is not using SFINAE neither. Please, could you add them to conform to the C++11 specification? Best, Vicente