--- Thorsten Ottosen <nesotto@cs.auc.dk> wrote:
In the range regression I get errors like
cc-1282 CC: ERROR File = /txusr/rwgrosse/boost_regression/boost/boost/range/empty.hpp, Line = 38 More than one instance of overloaded function "boost::begin" matches the argument list.
Function symbol function template "boost::begin(T &)" is ambiguous by inheritance. Function symbol function template "boost::begin(const T &)" is ambiguous by inheritance. The argument types are: (const std::pair<std::vector<int, std::allocator<int>>::iterator, std::vector<int, std::allocator<int>>::iterator>). return boost::begin( c ) == boost::end( c );
I don't know this compiler,
The compiler is using the old EDG 238 front end. The error above is the most dreaded one with this compiler. It is the result of a bug in the EDG front end that was fixed by EDG back in 1999:
From: "J. Stephen Adamczyk" Subject: Re: ambiguous by inheritance? Date: Thu, 21 Aug 2003 10:45:47 -0400 (EDT)
We, David Abrahams and myself, are puzzled by an error message (see below) issued by the old MIPSpro 7.3.1.3 (EDG 238) compiler. The error is reported while compiling the latest version of the Boost.Python library. The same code compiles without a problem with EDG 245 and EDG 300, and virtually any version of gcc. We are hoping that you might be able to give us a clue how we can work around this error. What does "is ambiguous by inheritance" mean?
In this case, not much, apparently. (It's supposed to mean that the name is inherited from more than one base class and doesn't mean the same thing in those base classes.)
The bug was apparently fixed by this change:
+ 12/6/99 Overload resolution gave incorrect ambiguity error + + In certain cases involving three or more viable functions, at least one + of which is a template, overload resolution incorrectly reported + ambiguity instead of picking the best function. Now fixed. + + template<class T> int getd(const T &); + int getd(char *a); + int getd(const char *a); + int main(){ + char c[5]; + getd(c); // Incorrectly gave ambiguity + }
It's hard to know how to work around that, but investigation of the exact change suggests that it's order-dependent, so you might be able to change the order of the declarations and get it to be accepted.
Steve
I don't know what to recommend in your case. It was a real challenge to get Boost.Python incl. MPL to work with this old compiler (thanks to David Abrahams and Aleksey Gurtovoy!). Unless you have a strong interest in supporting MIPSpro 7.3 it may be most practical to simply mark the tests as known to fail. Ralf _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com