Re: [boost] [string_ref] logical ops ambiguity errors (Re: bjam compiler error)

Subject: Re: [boost] [string_ref] logical ops ambiguity errors (Re: bjam compiler error)
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-02-25 20:04:04

On 13-02-25 03:59 PM, Marshall Clow wrote:
> 
> On Feb 24, 2013, at 10:34 PM, Eric Niebler <eniebler_at_[hidden]> wrote:
> 
>> On 2/24/2013 4:28 PM, Christian Henning wrote:
>>> Hi,
>>>
>>> I'm getting an compiler error when I try to build gil::io documentation.
>>>
>>> ...patience...
>>> ...patience...
>>> ...found 1737 targets...
>>> ...updating 5 targets...
>>> compile-c-c++ ..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj
>>> values.cpp
>>> C:\boost\tools\quickbook\src\values.cpp(444) : error C2593: 'operator
>>> ==' is ambiguous
>> <snip>
>>
>> Marshall, I took the liberty of fixing this. I hope I didn't step on any toes.
>>
>> https://svn.boost.org/trac/boost/changeset/83147
> 
> Hrm.
> That was the whole point of the Identity type name.
> That _should_ have worked.
> 
> Off to study some more.

You might be right. This is an interesting case. E.g. the following
compiles with clang trunk:

template<typename T> struct identity { typedef T type; };
template<typename T> struct string_ref {};

template<typename T>
void foo(string_ref<T>, string_ref<T>) {}

template<typename T>
void foo(string_ref<T>, typename identity<string_ref<T> >::type) {}

template<typename T>
void foo(typename identity<string_ref<T> >::type, string_ref<T>) {}

int main()
{
  string_ref<int> ref;
  foo(ref, ref);
}

Seems to rely on some partial ordering magic, even though all three are
viable matches and they all yield the same function signature. At any
rate, MSVC wasn't happy with it. It could be a compiler bug. Probably
worth investigating and filing.

-- 
Eric Niebler
Boost.org