Re: [boost] [multi_index + mpl + bind] Regression?
Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally. I'm afraid we're in Alexsey's hands to solve this out. BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin@tid.es> Fecha: Sábado, Septiembre 25, 2004 3:56 pm Asunto: Re: [boost] [multi_index + mpl + bind] Regression?
Vladimir, I don't have my compiler handy right now, but I think this is due to an overlook when doing the adaptation to the new MPL. In particular, the line 50 in boost/multi_index/detail/node_type.hpp:
typedef typename IndexSpecifierIterator::type index_specifier;
should be changed to
typedef typename mpl::deref<IndexSpecifierIterator>::type index_specifier;
(also, the corresponginf #include <boost/mp/defer.hpp> must be inserted) Could you please try this locally and report the results? If the problem is solved, I'll commit something along this line next Monday.
I don't know the rationale for having to use deref, since I thought these two expressions are equivalent, but there must be some difference, for Alexsey changed some of the code in multi_index to do that when mergien the new MPL.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
----- Mensaje original ----- De: Vladimir Prus <ghost@cs.msu.su> Fecha: Sábado, Septiembre 25, 2004 2:41 pm Asunto: [boost] [multi_index + mpl + bind] Regression?
The attached code, which use the multi_index library, produces screens of errors from mpl. The STLfilted log is attached too.
Commenting out #include <boost/bind/arg.hpp> makes the error go away, as well as including it after multi_index.
This happens with: gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) gcc version 3.4.1 (Debian 3.4.1-4sarge1)
The code used to work some time ago, but I can't give the exact
date.>
I've tried too look at the problem, but got lost in MPL internals.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
JOAQUIN LOPEZ MU?Z wrote:
Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally.
As I've mentioned in the other email, the change did not fix the problem.
I'm afraid we're in Alexsey's hands to solve this out.
Seems so.
BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference.
Well, I can tell one third of the story. The reverse_iter_fold.hpp has this: namespace boost { namespace mpl { template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(State) , typename BOOST_MPL_AUX_NA_PARAM(BackwardOp) , typename ForwardOp = arg<1> According to the error message, gcc associates 'arg<1>' with boost::arg (from bind/arg.hpp), while most likely mpl::arg<1> was meant. Two remaining questions are - why gcc does that. - why changing the above to mpl::arg<1> does not fix anything? - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
JOAQUIN LOPEZ MU?Z wrote:
Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally.
As I've mentioned in the other email, the change did not fix the problem.
I'm afraid we're in Alexsey's hands to solve this out.
Seems so.
BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference.
Well, I can tell one third of the story. The reverse_iter_fold.hpp has this:
namespace boost { namespace mpl {
template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(State) , typename BOOST_MPL_AUX_NA_PARAM(BackwardOp) , typename ForwardOp = arg<1>
According to the error message, gcc associates 'arg<1>' with boost::arg (from bind/arg.hpp), while most likely mpl::arg<1> was meant. Two remaining questions are - why gcc does that.
GCC applies "ADL" to almost everything. It's ridiculous.
- why changing the above to mpl::arg<1> does not fix anything?
That part I can't fathom. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Well, I can tell one third of the story. The reverse_iter_fold.hpp has this:
namespace boost { namespace mpl {
template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(State) , typename BOOST_MPL_AUX_NA_PARAM(BackwardOp) , typename ForwardOp = arg<1>
According to the error message, gcc associates 'arg<1>' with boost::arg (from bind/arg.hpp), while most likely mpl::arg<1> was meant. Two remaining questions are - why gcc does that.
GCC applies "ADL" to almost everything. It's ridiculous.
Do you know if there is bug report about this? I could not find any in gcc's bugzilla. Besides, I'm not sure gcc is at fault. Here's a completely distilled testcase: namespace boost { template<int I> class arg {}; } namespace mpl_ { template< int N > struct arg {}; } namespace boost { namespace mpl { using namespace mpl_; template<typename ForwardOp = arg<1> > struct XXX { IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
David Abrahams wrote:
Well, I can tell one third of the story. The reverse_iter_fold.hpp has this:
namespace boost { namespace mpl {
template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(State) , typename BOOST_MPL_AUX_NA_PARAM(BackwardOp) , typename ForwardOp = arg<1>
According to the error message, gcc associates 'arg<1>' with boost::arg (from bind/arg.hpp), while most likely mpl::arg<1> was meant. Two remaining questions are - why gcc does that.
GCC applies "ADL" to almost everything. It's ridiculous.
Do you know if there is bug report about this? I could not find any in gcc's bugzilla. Besides, I'm not sure gcc is at fault. Here's a completely distilled testcase:
namespace boost { template<int I> class arg {}; }
namespace mpl_ { template< int N > struct arg {}; }
namespace boost { namespace mpl {
using namespace mpl_;
template<typename ForwardOp = arg<1> > struct XXX {
IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace.
But the fact that explicit qualification doesn't fix it is surely a bug? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
namespace boost { template<int I> class arg {}; }
namespace mpl_ { template< int N > struct arg {}; }
namespace boost { namespace mpl {
using namespace mpl_;
template<typename ForwardOp = arg<1> > struct XXX {
IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace.
But the fact that explicit qualification doesn't fix it is surely a bug?
Not sure. Explicit qualification fixed the above snippet -- the gcc correctly used mpl::arg<1>, instead of boost::arg<1>. However, as Joaquín noted, there were some other cases where unqualified arg was used and they had to be fixed too. - Volodya
Vladimir Prus ha escrito:
David Abrahams wrote:
Well, I can tell one third of the story. The reverse_iter_fold.hpp has this:
namespace boost { namespace mpl {
template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(State) , typename BOOST_MPL_AUX_NA_PARAM(BackwardOp) , typename ForwardOp = arg<1>
According to the error message, gcc associates 'arg<1>' with boost::arg (from bind/arg.hpp), while most likely mpl::arg<1> was meant. Two remaining questions are - why gcc does that.
GCC applies "ADL" to almost everything. It's ridiculous.
Do you know if there is bug report about this? I could not find any in gcc's bugzilla. Besides, I'm not sure gcc is at fault. Here's a completely distilled testcase:
namespace boost { template<int I> class arg {}; }
namespace mpl_ { template< int N > struct arg {}; }
namespace boost { namespace mpl {
using namespace mpl_;
template<typename ForwardOp = arg<1> > struct XXX {
IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace.
Never heard of that rule. Do you happen to know where in the std can I learn more about it? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaqu?n M? L?pez Mu?oz wrote:
IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace.
Never heard of that rule. Do you happen to know where in the std can I learn more about it?
The first rule is 7.3.4/1: During unqualified name lookup, names appear as if they were declared in the nearest enclosing namespace which contains both the using-directive and the nominated namespace. The second rule is 3.4.3.2/2: Given X::m ... let S be the set of all declarations of m in X and the the transitive closure of all namespaces nominated by using directives in X ... So, for mpl::X, only mpl and mpl_ are searched, but not boost. HTH, Volodya
Vladimir Prus ha escrito:
Joaqu?n M? L?pez Mu?oz wrote:
IIRC, the 'arg' visible via using is considered to be declared in the nearest namespace enclosing both mpl_ and boost::mpl -- which is global namespace. So boost::arg hides mpl_::arg. For explicit mpl::aux, the name lookup ignores the 'boost' namespace.
Never heard of that rule. Do you happen to know where in the std can I learn more about it?
The first rule is 7.3.4/1: During unqualified name lookup, names appear as if they were declared in the nearest enclosing namespace which contains both the using-directive and the nominated namespace.
The second rule is 3.4.3.2/2: Given X::m ... let S be the set of all declarations of m in X and the the transitive closure of all namespaces nominated by using directives in X ... So, for mpl::X, only mpl and mpl_ are searched, but not boost.
Man, and I thought I knew C++. Thanks for the pointer! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
David Abrahams -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Vladimir Prus