[cfe-dev] Determining whether Container<T>()==Container<T>() can compile?

Mailing List Email mailinglistx at gmail.com
Wed May 29 01:12:27 PDT 2013


Well, actually, having thought about it, the following might work:

template<typename T, typename U>
struct IsEqComparable
{
private:
    typedef struct { char dmy; } yes;
    typedef struct { char dmy[2]; } no;

    template<typename T2, typename U2>
    static auto test(void*) -> typename std::enable_if<std::is_same<
            decltype(*std::declval<T2>().begin() ==
*std::declval<U2>().begin()),
            decltype(*std::declval<T2>().begin() ==
*std::declval<U2>().begin())
        >::value, yes>::type;

    template<typename T2, typename U2> static no test(...);
public:
    static const bool value = sizeof(test<T, U>(nullptr)) == sizeof(yes);
};

This works fine for comparing vectors and probably any other container that
exposes iterators through begin.
You will have to detect the possible type of the types, though.

The problem essentially comes from that there exists an operator == that
compares two vectors, hence decltype(a == b) would succeed, because
decltype does not evaluate its arguments.
Instead, the problem happens inside the operator == when it tries to
compare the elements.


On 29 May 2013 09:27, Stephen Kelly <steveire at gmail.com> wrote:

> Mailing List Email wrote:
>
>
>  That is unfortunate. I am afraid that, at  this moment, I do not know of a
>>
>
>  better solution. It would seem that  decltype erroneously makes the
>>
>
>  overloaded well-formed while the idea was  that it should not.
>>
>
>  Perhaps someone else will have another  suggestion.
>>
>
>
> It appears there is no known solution. Boost hit the same problem:
>
>
> http://stackoverflow.com/**questions/16791391/**determining-whether-**
> containert-containert-can-**compile<http://stackoverflow.com/questions/16791391/determining-whether-containert-containert-can-compile>
>
>
> However, as I wrote before, the problem becomes solvable if trailing
> return types are used:
>
>
>
>  >> Adding auto and trailing  return type seems to be helpful:
>>>
>>
>  >>
>>>
>>
>  >>  http://thread.gmane.org/gmane.**comp.lib.qt.devel/11120/focus=**11157<http://thread.gmane.org/gmane.comp.lib.qt.devel/11120/focus=11157>
>>>
>>
>
>
> So, I'm wondering if we can change libcxx to use trailing return types for
> operators like that? Would such a change have to go into the c++ standard
> itself?
>
>
> Thanks,
>
>
> Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130529/9367b988/attachment.html>


More information about the cfe-dev mailing list