Hi, 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, but could it be that it does not configures BOOST_NO_FUNCTION_TEMPLATE_ORDERING properly? (I assume by the error above mipspro should define the macro to 1) If so, can somebody fix it? Thanks Thorsten
--- 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
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote in message news:20040922055031.79319.qmail@web20221.mail.yahoo.com... | --- Thorsten Ottosen <nesotto@cs.auc.dk> wrote: | > In the range regression I get errors like | 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: | 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. I'm not personally interested in porting to this compiler, but it seems that it should configure #define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1 this could actually make boost.range work 90% on this compiler. Can anybody see any problems in defining this flag for this compiler? br Thorsten
--- Thorsten Ottosen <nesotto@cs.auc.dk> wrote:
I'm not personally interested in porting to this compiler, but it seems that it should configure
#define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1
this could actually make boost.range work 90% on this compiler. Can anybody see any problems in defining this flag for this compiler?
I could try it out if you tell me where you want to put the define, e.g. via a patch. Ralf _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote in message news:20040922193102.44195.qmail@web20222.mail.yahoo.com... | --- Thorsten Ottosen <nesotto@cs.auc.dk> wrote: | | > I'm not personally interested in porting to this compiler, but it seems that | > it should configure | > | > #define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1 | > | > this could actually make boost.range work 90% on this compiler. Can anybody | > see any problems | > in defining this flag for this compiler? | | I could try it out if you tell me where you want to put the define, e.g. via a | patch. | Ralf it seems that mipspro does not have its own file in boost/config/compiler so maybe boost/config/compiler/common_edg.hpp should have the line #if (__EDG_VERSION__ <= 238) # define BOOST_NO_INTEGRAL_INT64_T # define BOOST_NO_SFINAE # define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1 // ADD THIS LINE #endif who knows...maybe it works :-) br Thorsten
it seems that mipspro does not have its own file in boost/config/compiler so maybe
It's boost/config/compiler/sgi_mipspro.hpp
boost/config/compiler/common_edg.hpp
should have the line
#if (__EDG_VERSION__ <= 238) # define BOOST_NO_INTEGRAL_INT64_T # define BOOST_NO_SFINAE # define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1 // ADD THIS LINE #endif
That is the correct place to add it, if it's a common EDG problem. However config_test is passing for this compiler without BOOST_NO_FUNCTION_TEMPLATE_ORDERING being set, so are you sure this is the right macro for the job? Or does the test case need updating? Thanks, John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:01ad01c4a154$a101efc0$3c590352@fuji... | > it seems that mipspro does not have its own file in boost/config/compiler | > so | > maybe | | It's boost/config/compiler/sgi_mipspro.hpp ok. | That is the correct place to add it, if it's a common EDG problem. However | config_test is passing for this compiler without | BOOST_NO_FUNCTION_TEMPLATE_ORDERING being set, so are you sure this is the | right macro for the job? Or does the test case need updating? I dunno. Sorry, but I havn't got time to inestigate this right now. If somebody would like mipspro support, I guess they should do something about it. br Thorsten
--- John Maddock <john@johnmaddock.co.uk> wrote:
boost/config/compiler/common_edg.hpp
should have the line
#if (__EDG_VERSION__ <= 238) # define BOOST_NO_INTEGRAL_INT64_T # define BOOST_NO_SFINAE # define BOOST_NO_FUNCTION_TEMPLATE_ORDERING 1 // ADD THIS LINE #endif
That is the correct place to add it, if it's a common EDG problem. However config_test is passing for this compiler without BOOST_NO_FUNCTION_TEMPLATE_ORDERING being set, so are you sure this is the right macro for the job? Or does the test case need updating?
If I add the define I get the error below while compiling one of the Boost.Python regression tests. Without the extra define there are no errors. Ralf cc-1278 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/python/iterator.hpp, Line = 36 No instance of overloaded function "boost::bind" matches the argument list. The argument types are: (two_lists::two_start, boost::arg<1>). boost::protect(boost::bind(get_start, _1)) ^ A template was detected during header processing. instantiation of "boost::python::api::object boost::python::detail::make_iterator(two_lists::two_start , std::list<int, std::allocator<int>>::iterator (two_lists::*)(), boost::python::return_value_policy<boost::python::copy_no n_const_reference, boost::python::default_call_policies>, two_lists &(*)())" at line 105 instantiation of "boost::python::api::object boost::python::range(two_lists::two_start, std::list<int, std::allocator<int>>::iterator (two_lists::*)(), boost::python::return_value_policy<boost::python::copy_no n_const_reference, boost::python::default_call_policies> *, boost::type<two_lists> *)" __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
If I add the define I get the error below while compiling one of the Boost.Python regression tests. Without the extra define there are no errors. Ralf
Sounds like defining that macro is too much of a blunt instrument, maybe a BOOST_WORKAROUND in the range headers would be more appropriate. John.
participants (3)
-
John Maddock -
Ralf W. Grosse-Kunstleve -
Thorsten Ottosen