[tuple] problem with global tuples::get() in vacpp 6.00
Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking Boost.MultiIndex and a test of Boost.Iterator. Please find below a very simple and totally conformant fix. This has not actually been tested with vacpp, but I checked it does not break anything with some other compilers. 1. Could anybody check locally if this solves the aforementioned problems in vacpp? 2. If 1 is positive, can I commit this to the CVS? Anyone sees a problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo **************DIFF************** 201c201,203 < >::non_const_type>(c); ---
>::non_const_type, HT,TT >(c);
216c218,220 < >::const_type>(c); ---
>::const_type, HT,TT >(c);
Joaquín Mª López Muñoz wrote:
Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking
Boost.MultiIndex and a test of Boost.Iterator.
Please find below a very simple and totally conformant fix. This has not
actually been tested with vacpp, but I checked it does not break anything with some other compilers.
1. Could anybody check locally if this solves the aforementioned problems in vacpp?
This solves the aforementioned problem. But now we stumble on another problem: Now vacpp reports a problem on line 212 on boost/tuple/detail/tuple_basic.hpp. Is says that detail::get_class<1>::get is not declared
Toon Knapen ha escrito:
Joaquín Mª López Muñoz wrote:
Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking
Boost.MultiIndex and a test of Boost.Iterator.
Please find below a very simple and totally conformant fix. This has not
actually been tested with vacpp, but I checked it does not break anything with some other compilers.
1. Could anybody check locally if this solves the aforementioned problems in vacpp?
This solves the aforementioned problem. But now we stumble on another problem:
Now vacpp reports a problem on line 212 on boost/tuple/detail/tuple_basic.hpp. Is says that detail::get_class<1>::get is not declared
Ummm... line 212 is a weird place to get an error at. Could you please send me (preferrably thru private email) your modified tuple_basic.hpp and the complete copmiler output? Thank you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz <joaquin@tid.es> writes:
Ummm... line 212 is a weird place to get an error at. Could you please send me (preferrably thru private email) your modified tuple_basic.hpp and the complete copmiler output? Thank you.
If it's just the two of you working on this problem, maybe you should take the whole thing off-list until something of general interest shows up? Just a thought... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Of course those of us that do not dwell in the land of Windows are very interested in Boost working better on various *nix platforms whether or not we participate directly in any particular email thread. So if you take it off-list then we don't learn of the foibles of the many compilers we work with nor the clever work-arounds that are discussed on this list. Just another thought. David Abrahams wrote:
Joaquín Mª López Muñoz <joaquin@tid.es> writes:
Ummm... line 212 is a weird place to get an error at. Could you please send me (preferrably thru private email) your modified tuple_basic.hpp and the complete copmiler output? Thank you.
If it's just the two of you working on this problem, maybe you should take the whole thing off-list until something of general interest shows up? Just a thought...
John Mulhern <jfmulhern@comcast.net> writes:
Of course those of us that do not dwell in the land of Windows are very interested in Boost working better on various *nix platforms whether or not we participate directly in any particular email thread. So if you take it off-list then we don't learn of the foibles of the many compilers we work with nor the clever work-arounds that are discussed on this list.
That's fine, too. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
With a lot of help from Joaquin we've been able to succesfully compile most of the multi_index library and some other libraries which use the tuple library by using the attached patch. Is it OK to commit the patch? In the final version also I intend to add a small comment in the code why we need the workaround for IBM because AFAICT the problem is the member-template-keyword: For version 6.0 of VisualAge, BOOST_NO_MEMBER_TEMPLATE_KEYWORD is intentially *not* defined. However in the attached patch you can see that I removed the 'template' keyword and that this makes it work. However sometimes putting the 'template' keyword makes it compile, sometimes ommitting the keyword makes it compile and sometimes we never succeed to compile such constructs (e.g. in the program-options library). For instance I tested defining the BOOST_NO_MEMBER_TEMPLATE_KEYWORD but the regression results overall were worse. Joaquín Mª López Muñoz wrote:
Toon Knapen ha escrito:
Joaquín Mª López Muñoz wrote:
Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking
Boost.MultiIndex and a test of Boost.Iterator.
Please find below a very simple and totally conformant fix. This has not
actually been tested with vacpp, but I checked it does not break anything with some other compilers.
1. Could anybody check locally if this solves the aforementioned problems in vacpp?
Index: tuple_basic.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.23 diff -u -r1.23 tuple_basic.hpp --- tuple_basic.hpp 28 Oct 2003 09:42:43 -0000 1.23 +++ tuple_basic.hpp 15 Jun 2004 10:26:17 -0000 @@ -97,12 +97,16 @@ template<class RET, class HT, class TT > inline static RET get(const cons<HT, TT>& t) { +#ifndef __IBMCPP__ return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); +#else + return get_class<N-1>::get<RET>(t.tail); +#endif } template<class RET, class HT, class TT > inline static RET get(cons<HT, TT>& t) { - return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); + return get_class<N-1>::get<RET>(t.tail); } }; @@ -194,11 +198,17 @@ typename element<N, cons<HT, TT> >::type >::non_const_type get(cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { - return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#ifndef __IBMCPP__ + return get_class<N>::BOOST_NESTED_TEMPLATE +#else + return get_class<N>:: +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::non_const_type>(c); + >::non_const_type, + HT,TT + >(c); } // get function for const cons-lists, returns a const reference to @@ -209,11 +219,17 @@ typename element<N, cons<HT, TT> >::type >::const_type get(const cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { +#ifndef __IBMCPP__ return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#else + return detail::get_class<N>:: +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::const_type>(c); + >::const_type, + HT,TT + >(c); } // -- the cons template --------------------------------------------------
Toon Knapen <toon.knapen@fft.be> writes:
With a lot of help from Joaquin we've been able to succesfully compile most of the multi_index library and some other libraries which use the tuple library by using the attached patch. Is it OK to commit the patch?
I don't know, it seems like you just need to #define BOOST_NESTED_TEMPLATE for this compiler and you could forget about patching tuple. No? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I don't know, it seems like you just need to
#define BOOST_NESTED_TEMPLATE
for this compiler and you could forget about patching tuple.
No? No ;-(
I try to explain this in my previous mail: <quote from previous mail> For version 6.0 of VisualAge, BOOST_NO_MEMBER_TEMPLATE_KEYWORD is intentially *not* defined. However in the attached patch you can see that I removed the 'template' keyword and that this makes it work. However sometimes putting the 'template' keyword makes it compile, sometimes ommitting the keyword makes it compile and sometimes we never succeed to compile such constructs (e.g. in the program-options library). For instance I tested defining the BOOST_NO_MEMBER_TEMPLATE_KEYWORD but the regression results overall were worse. </quote from previous mail> IIUC, this responds to your question or is there soth. else (and the quote above is probably not written very clearly as well) ?
Toon Knapen <toon.knapen@fft.be> writes:
David Abrahams wrote:
I don't know, it seems like you just need to #define BOOST_NESTED_TEMPLATE for this compiler and you could forget about patching tuple. No? No ;-(
I try to explain this in my previous mail:
<quote from previous mail> For version 6.0 of VisualAge, BOOST_NO_MEMBER_TEMPLATE_KEYWORD is intentially *not* defined.
Oh. I just didn't make the connection between BOOST_NO_MEMBER_TEMPLATE_KEYWORD and BOOST_NESTED_TEMPLATE. :( -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
What compiler patch level are you at with vacpp 6.0? Against which code level is the patch a patch against? What OS level are you compiling under and what patches have been applied to the OS? Toon Knapen wrote:
With a lot of help from Joaquin we've been able to succesfully compile most of the multi_index library and some other libraries which use the tuple library by using the attached patch. Is it OK to commit the patch? In the final version also I intend to add a small comment in the code why we need the workaround for IBM because AFAICT the problem is the member-template-keyword:
John Mulhern wrote:
What compiler patch level are you at with vacpp 6.0?
As is mentioned on the top of the regression test page for vacpp, I'm using the April PTF (IBM parlance for a 3-monthly bunch of patches)
Against which code level is the patch a patch against?
Which code level of boost ? The trunk of yesterday, version 1.13 of tuple_basic.hpp as you can see in the 'cvs diff'.
What OS level are you compiling under Aix 5.1
and what patches have been applied to the OS? oslevel 4. But woudl the maintenance level of the OS have an influence you think? When installing a new PTF for the compiler, it regularly has a prerequisite on a new PTF for the runtime. So this covers all depdencies of the compiler on the system I guess.
participants (4)
-
David Abrahams -
Joaquín Mª López Muñoz -
John Mulhern -
Toon Knapen