Re: [Lilypond-auto] Issue 3656 in lilypond: Problems building Lilypond 2.17.95 with libc++ for use with llvm

[lilypond]

Comment #15 on issue 3656 by address@hidden: Problems building Lilypond  
2.17.95 with libc++ for use with llvm
http://code.google.com/p/lilypond/issues/detail?id=3656

The proposal is doing something entirely wrong in more than one respect.   
It would appear that clang++ has difficulties picking a suitable candidate  
to_string from a host of available options, but a typecast to int should  
likely resolve the perceived ambiguity.  However, it will _not_ resolve the  
ambiguity with
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:3999:8:
 note: candidate function
string to_string(int __val);
       ^
../flower/include/std-string.hh:44:8: note: candidate function
string to_string (int i, char const *format = 0);
       ^
Since we clearly have two candidates for int, even without looking  
further.  As well as for several others.

So the principal question is: why does std-string.cc redefine functionality  
already available in a standard string library?  How did we get the  
standard string library to compete?

Should we have autoconf tests that only define to_string versions in  
std_string.cc when the normal string class doesn't have them?

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings