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 ..\..\..\..\boost/utility/string_ref.hpp(275): could be 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(270): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(265): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] while trying to match the argument list '(boost::string_ref, boost::string_ref)' C:\boost\tools\quickbook\src\values.cpp(499) : error C2593: 'operator ==' is ambiguous ..\..\..\..\boost/utility/string_ref.hpp(275): could be 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(270): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] ..\..\..\..\boost/utility/string_ref.hpp(265): or 'bool boost::operator ==<char,std::char_traits<char>>(boost::basic_string_ref<charT,traits>,boost::basic_string_ref<charT,traits>)' [found using argument-dependent lookup] with [ charT=char, traits=std::char_traits<char> ] while trying to match the argument list '(boost::string_ref, boost::string_ref)' call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj.rsp" ...failed compile-c-c++ ..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\values.obj... ...skipped <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>quickbook.exe for lack of <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>values.obj... ...skipped <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.xml for lack of <p..\..\..\..\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi>quickbook.exe... ...skipped <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.docbook for lack of <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi-object(xinclude-scanner)@1505>io.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\..\bin.v2\libs\gil\io\doc\msvc-10.0\debug\threading-multi>io.docbook... ...failed updating 1 target... ...skipped 4 targets... Regards, Christian
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 -- Eric Niebler Boost.org http://www.boost.org
On 25 February 2013 06:34, Eric Niebler <eniebler@boost.org> 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>
Sorry about this, I tested the changes to quickbook with Visual C++ a while ago, but I should have tested again before adding them to trunk.
Marshall, I took the liberty of fixing this. I hope I didn't step on any toes.
Thanks.
On Feb 24, 2013, at 10:34 PM, Eric Niebler <eniebler@boost.org> 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.
Hrm. That was the whole point of the Identity type name. That _should_ have worked. Off to study some more. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 13-02-25 03:59 PM, Marshall Clow wrote:
On Feb 24, 2013, at 10:34 PM, Eric Niebler <eniebler@boost.org> 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.
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
AMDG On 02/25/2013 05:04 PM, Eric Niebler wrote:
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>) {} <---- a
template<typename T> void foo(string_ref<T>, typename identity<string_ref<T> >::type) {} <---- b
template<typename T> void foo(typename identity<string_ref<T> >::type, string_ref<T>) {} <---- c
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.
I don't think that this code is legal. (b) and (c) are obviously equivalent in terms of partial ordering. Neither is more specialized than the other. Unfortunately, I can't seem to find any provision for template paramters used in non-deduced contexts (as described in 14.8.2.5p5). 14.5.6.2 and 14.8.2.4 both appear to assume that this scenario never occurs. The transformation described in 14.5.6.2p3 is technically impossible to implement in this case, as the compiler cannot instantiate a template with the synthesized type. However, I can't come up with any sensible rule under which (a) is more specialized than (b). The simplest method (which I've always assumed to hold) is to treat template<typename T> void foo(string_ref<T>, typename identity<string_ref<T> >::type) {} as if it were template<typename T> void foo(string_ref<T>, typename identity<string_ref<char> >::type) {} in which case it is obvious that (b) should be considered more specialized than (a). Or, we could synthesize a unique type to substitute for identity<string_ref<char> >::type, in which case template argument deduction fails in both directions and neither (a) nor (b) is more specialized than the other. Or, we could treat it as if it were something like: template<typename T> void foo(string_ref<T>, identity___type<string_ref<T> >) {} (effectively transforming non-deduced contexts into deduced contexts) In this case, template argument deduction fails in both directions and neither (a) nor (b) is more specialized than the other. The only way I can see this working is if there's actually some kind of parameter-order dependence in the partial ordering rules that I missed, which makes (b) more specialized than (c). In Christ, Steven Watanabe
participants (5)
-
Christian Henning -
Daniel James -
Eric Niebler -
Marshall Clow -
Steven Watanabe