Hi all, I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly. Does anybody know if the problem was fixed in later versions of GCC? Thanks, Arkadiy
Arkadiy Vertleyb wrote:
Hi all,
I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly.
Does anybody know if the problem was fixed in later versions of GCC?
That's rather disturbing to hear. I know that for 1.32 Aleksey jumped through considerable hoops specifically to avoid unintentional ADL effects that crop up with GCC because of its "interesting interpretation" of the standard. If anything, 1.32 should be much better than previous versions in this regard. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
Arkadiy Vertleyb wrote:
Hi all,
I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly.
Does anybody know if the problem was fixed in later versions of GCC?
That's rather disturbing to hear. I know that for 1.32 Aleksey jumped through considerable hoops specifically to avoid unintentional ADL effects that crop up with GCC because of its "interesting interpretation" of the standard. If anything, 1.32 should be much better than previous versions in this regard.
True. I'd like to see specific instances of the conflicting code. -- Aleksey Gurtovoy MetaCommunications Engineering
David Abrahams writes:
Arkadiy Vertleyb wrote:
Hi all,
I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote previous
posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly.
Does anybody know if the problem was fixed in later versions of GCC?
That's rather disturbing to hear. I know that for 1.32 Aleksey jumped through considerable hoops specifically to avoid unintentional ADL effects that crop up with GCC because of its "interesting interpretation" of the standard. If anything, 1.32 should be much better than previous versions in this regard.
True. I'd like to see specific instances of the conflicting code.
Here is an emulation -- I use my own unqualified call instead of STL (and AFAIK g++ STL makes lots of unqualified calls): ----------- a.cpp -------------------------------- #include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp> namespace X { template<class T> void find(const T&) {} template<class T> struct row {}; void foo() { find(row<boost::mpl::vector0<> >()); } } int main() { X::foo(); return 0; } ---------------------------------- The result is: C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class Sequence, class T> struct boost::mpl::find' is not a function, a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' a.cpp:13: error: in call to `find' As you can see, the parameter to foo() makes the compiler consider the boost::mpl namespace for ADL. The combination of unqualified call and g++ finding class templates during ADL produces the error. Regards, Arkadiy
Here is an emulation -- I use my own unqualified call instead of STL (and AFAIK g++ STL makes lots of unqualified calls):
----------- a.cpp --------------------------------
#include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp>
namespace X { template<class T> void find(const T&) {} template<class T> struct row {}; void foo() { find(row<boost::mpl::vector0<> >()); } }
int main() { X::foo(); return 0; } ----------------------------------
The result is:
C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class Sequence, class T> struct boost::mpl::find' is not a function, a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' a.cpp:13: error: in call to `find'
Surely that's a gcc bug (anyone reported this?), there is no argument to find that is in the mpl namespace, an X::row<boost::mpl::vector0<> > doesn't count! John.
On Tue, Dec 21, 2004 at 10:46:44AM -0000, John Maddock wrote:
Here is an emulation -- I use my own unqualified call instead of STL (and AFAIK g++ STL makes lots of unqualified calls):
----------- a.cpp --------------------------------
#include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp>
namespace X { template<class T> void find(const T&) {} template<class T> struct row {}; void foo() { find(row<boost::mpl::vector0<> >()); } }
int main() { X::foo(); return 0; } ----------------------------------
The result is:
C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class Sequence, class T> struct boost::mpl::find' is not a function, a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' a.cpp:13: error: in call to `find'
Surely that's a gcc bug (anyone reported this?), there is no argument to find that is in the mpl namespace, an X::row<boost::mpl::vector0<> > doesn't count!
Comeau considers boost::mpl::find if its a function, but not if it's a type. That implies it should be looking in that namespace. The problem is that GCC finds non-functions by ADL, which is bug 17365. jon -- "Ye have locked yerselves up in cages of fear; and behold, do ye now complain that ye lack freedom." - Lord Omar Khayyam Ravenhurst "Epistle to the Paranoids," HBT
On Mon, Dec 20, 2004 at 09:00:04PM -0800, Arkadiy Vertleyb wrote: [snip]
The result is:
C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class Sequence, class T> struct boost::mpl::find' is not a function, a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' a.cpp:13: error: in call to `find'
As you can see, the parameter to foo() makes the compiler consider the boost::mpl namespace for ADL. The combination of unqualified call and g++ finding class templates during ADL produces the error.
According to GCC's bugzilla whether this is wrong is an open Core issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365 I'm not sure which DR Gaby is referring to there, possibly 405 ? This is why GCC hasn't been "fixed" to ignore the non-function. jon -- "You have attributed conditions to villainy that simply result from stupidity." - Robert Heinlein
According to GCC's bugzilla whether this is wrong is an open Core issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
I'm not sure which DR Gaby is referring to there, possibly 405 ?
Aha: you're right this is active issue 218 (http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n1729.html#218), so gcc appears to be correct, even though it results in some really unfortunate behaviour. Thanks for clearing that up, John.
On Tue, Dec 21, 2004 at 04:35:46PM -0000, John Maddock wrote:
According to GCC's bugzilla whether this is wrong is an open Core issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
I'm not sure which DR Gaby is referring to there, possibly 405 ?
Aha: you're right this is active issue 218 (http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n1729.html#218), so gcc appears to be correct, even though it results in some really unfortunate behaviour.
Thanks for clearing that up,
It's also worth mentioning that nothing in the standard requires libstdc++ to qualify calls to find() etc. If libstdc++ chooses to make those functions points of customisation then they should be left unqualified, so that ADL is invoked intentionally. I don't think it was ever intended for them to be points of customisation, the lack of qualification was an oversight that has been corrected in newer releases. We'd certainly never documented that they were points of customisation. (AFAIK the whole "points of customisation" topic is something that only came up in the last year or two.) All this means that any code that breaks because of this GCC feature is relying on implementation-defined behaviour (as distinct from undefined behaviour). jon -- "Those who don't understand UNIX are doomed to reinvent it, poorly." - Henry Spencer
Jonathan Wakely wrote:
On Tue, Dec 21, 2004 at 04:35:46PM -0000, John Maddock wrote:
According to GCC's bugzilla whether this is wrong is an open Core issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
I'm not sure which DR Gaby is referring to there, possibly 405 ?
Aha: you're right this is active issue 218 (http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n1729.html#218), so gcc appears to be correct, even though it results in some really unfortunate behaviour.
Thanks for clearing that up,
It's also worth mentioning that nothing in the standard requires libstdc++ to qualify calls to find() etc.
http://open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225
On Tue, Dec 21, 2004 at 09:01:32PM +0200, Peter Dimov wrote:
Jonathan Wakely wrote:
It's also worth mentioning that nothing in the standard requires libstdc++ to qualify calls to find() etc.
http://open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225
Aaah, thank you! Shouldn't have written that so hastily. jon --
On Tue, Dec 21, 2004 at 01:27:12PM +0000, Jonathan Wakely wrote:
On Mon, Dec 20, 2004 at 09:00:04PM -0800, Arkadiy Vertleyb wrote:
[snip]
The result is:
C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class Sequence, class T> struct boost::mpl::find' is not a function, a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' a.cpp:13: error: in call to `find'
As you can see, the parameter to foo() makes the compiler consider the boost::mpl namespace for ADL. The combination of unqualified call and g++ finding class templates during ADL produces the error.
According to GCC's bugzilla whether this is wrong is an open Core issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
I'm not sure which DR Gaby is referring to there, possibly 405 ?
Found it: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#218
This is why GCC hasn't been "fixed" to ignore the non-function.
-- "Political satire became obsolete when Henry Kissinger was awarded the Nobel Prize." - Tom Lehrer
Jonathan Wakely <cow@compsoc.man.ac.uk> writes: | On Mon, Dec 20, 2004 at 09:00:04PM -0800, Arkadiy Vertleyb wrote: | | [snip] | > The result is: | > | > C:\ark\gcctest>g++ -I c:\boost\boost_1_32_0 a.cpp | > c:/boost/boost_1_32_0/boost/mpl/find.hpp: In function `void X::foo()': | > c:/boost/boost_1_32_0/boost/mpl/find.hpp:29: error: `template<class | > Sequence, | > class T> struct boost::mpl::find' is not a function, | > a.cpp:8: error: conflict with `template<class T> void X::find(const T&)' | > a.cpp:13: error: in call to `find' | > | > As you can see, the parameter to foo() makes the compiler consider the | > boost::mpl namespace for ADL. The combination of unqualified call and g++ | > finding class templates during ADL produces the error. | | According to GCC's bugzilla whether this is wrong is an open Core issue | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365 | | I'm not sure which DR Gaby is referring to there, possibly 405 ? http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#218 -- Gaby
Arkadiy Vertleyb writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
True. I'd like to see specific instances of the conflicting code.
Here is an emulation -- I use my own unqualified call instead of STL (and AFAIK g++ STL makes lots of unqualified calls):
----------- a.cpp --------------------------------
#include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp>
namespace X { template<class T> void find(const T&) {} template<class T> struct row {}; void foo() { find(row<boost::mpl::vector0<> >()); } }
int main() { X::foo(); return 0; }
In general, MPL works around this GCC quirk by putting its "data types" into an unrelated namespace ('mpl_') and bringing them into 'boost::mpl' through a 'using' directive/declarations. This breaks the ADL link between the data types and the algorithms, resolving the issue for many typical use cases. The reason why the above fails is that currently the workaround is not applied to MPL sequences (it was planned, but never implemented). I'll look into fixing this for the next release. -- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, Dec 19, 2004 at 07:40:35AM -0800, Arkadiy Vertleyb wrote:
Hi all,
I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly.
Does anybody know if the problem was fixed in later versions of GCC?
Sorry for the late reply. Yes, this is fixed in GCC 3.4.0 and higher. There might still be some calls that need qualifying, but those are bugs and will get fixed. All calls to std::find(), std::find_if() et al in <algorithm> are qualified, if you find calls that are missing the qualification please let the libstdc++ mailing list know (or shout about them here and I'll get them fixed if I read it). jon -- "A foolish consistency is the hobgoblin of little minds..." - Ralph Waldo Emerson
On Tue, Dec 21, 2004 at 10:11:00PM +0800, Allen Yao wrote:
I tried Arkadiy's example with G++ 3.4.2 on my Debian Linux, and got the same error messages.
I meant the unqualified names are fixed, <algorithm> qualifies std::find() so that class boost::mpl::find won't be considered. Arkadiy's example tests whether non-functions are found by ADL, which is still the case for the latest GCC, but since libstdc++ doesn't make unqualified calls there is no ADL, so non-functions aren't found. jon -- "It is always the best policy to tell the truth, unless, of course, you are an exceptionally good liar." - Jerome K. Jerome
"Allen Yao" <yaozhen@ustc.edu> wrote
I tried Arkadiy's example with G++ 3.4.2 on my Debian Linux, and got the same error messages.
Well, you should :-) Jonathan said unqualified calls in STL have been fixed -- not the ADL issue. My example doesn't actually use STL -- I emulate it. If you qualify the call in my example, the problem should go away, as it should if the calls in the g++ STL have been actually qualified. Regards, Arkadiy
On Sun, Dec 19, 2004 at 07:40:35AM -0800, Arkadiy Vertleyb wrote:
Hi all,
I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote previous
posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly.
Does anybody know if the problem was fixed in later versions of GCC?
Sorry for the late reply. Yes, this is fixed in GCC 3.4.0 and higher.
There might still be some calls that need qualifying, but those are bugs and will get fixed. All calls to std::find(), std::find_if() et al in <algorithm> are qualified, if you find calls that are missing the qualification please let the libstdc++ mailing list know (or shout about them here and I'll get them fixed if I read it).
After I switched to g++ 3.4.2 things got much better for me. However there are still a few unqualified calls to copy in bits/vector.tcc. I had to fix them manually on my copy in order to be able to compile. Any idea if it is going to be fixed and when? Regards, Arkadiy
On Fri, Dec 24, 2004 at 08:25:28PM -0800, Arkadiy Vertleyb wrote:
After I switched to g++ 3.4.2 things got much better for me. However there are still a few unqualified calls to copy in bits/vector.tcc. I had to fix them manually on my copy in order to be able to compile.
I've found three calls, was that all of them?
Any idea if it is going to be fixed and when?
I'll look for similar problems elsewhere, run the testsuite and ask for approval to commit the change, I'll let you know if/when it's approved. I have no idea how long it will take as I'll be on holiday for another week and others might be too. Thanks for letting me know, jon -- "Convictions cause convicts" - Mal2
On Fri, Dec 24, 2004 at 08:25:28PM -0800, Arkadiy Vertleyb wrote:
After I switched to g++ 3.4.2 things got much better for me. However
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote there
are still a few unqualified calls to copy in bits/vector.tcc. I had to fix them manually on my copy in order to be able to compile.
I've found three calls, was that all of them?
I think that's it.
I'll look for similar problems elsewhere, run the testsuite and ask for approval to commit the change, I'll let you know if/when it's approved.
Thanks a lot! Arkadiy
On Mon, Dec 27, 2004 at 04:18:17PM -0800, Arkadiy Vertleyb wrote:
On Fri, Dec 24, 2004 at 08:25:28PM -0800, Arkadiy Vertleyb wrote:
After I switched to g++ 3.4.2 things got much better for me. However
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote there
are still a few unqualified calls to copy in bits/vector.tcc. I had to fix them manually on my copy in order to be able to compile.
I've found three calls, was that all of them?
I think that's it.
I'll look for similar problems elsewhere, run the testsuite and ask for approval to commit the change, I'll let you know if/when it's approved.
I'm testing the fixes and will commit them to the 3.4 and 4.0 sources, possibly tomorrow but definitely before the next releases. jon -- "The Sage treasures Unity and measures all things by it" - Lao Tzu
On Mon, Jan 03, 2005 at 10:34:08PM +0000, Jonathan Wakely wrote:
On Mon, Dec 27, 2004 at 04:18:17PM -0800, Arkadiy Vertleyb wrote:
On Fri, Dec 24, 2004 at 08:25:28PM -0800, Arkadiy Vertleyb wrote:
After I switched to g++ 3.4.2 things got much better for me. However
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote there
are still a few unqualified calls to copy in bits/vector.tcc. I had to fix them manually on my copy in order to be able to compile.
I've found three calls, was that all of them?
I think that's it.
I'll look for similar problems elsewhere, run the testsuite and ask for approval to commit the change, I'll let you know if/when it's approved.
I'm testing the fixes and will commit them to the 3.4 and 4.0 sources, possibly tomorrow but definitely before the next releases.
Arkadiy, The qualifications for std::copy() were committed to vector.tcc while I was on holiday, so will be in the next releases. jon -- To conquer oneself is a greater task than conquering others. - Buddha
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes: | Any idea if it is going to be fixed and when? Things get fixed quicker when actual PRs are submitted.
participants (8)
-
Aleksey Gurtovoy -
Allen Yao -
Arkadiy Vertleyb -
David Abrahams -
Gabriel Dos Reis -
John Maddock -
Jonathan Wakely -
Peter Dimov