Re: [Boost-users] boost::lambda::bind question
I came across this problem in the real project where I don't control the class that corresponds to class Y of the example, so I can't change the signature of the member function. I could write a wrapper function that takes Y*, but after some point the code with a simple 'for' loop becomes cleaner and more readable than the one using lambda. If this problem is not a bug, but an inherent limitation of the lambda library or its current implementation, it would be nice if it is mentioned in the documentation. Thanks, Eugene Vishnevetsky Roman Krylov wrote: Perhaps the only solution here is to use Y* instead of Y& with corresponding modifications; this way there is no need for var() or smth similar. Why not? Vishnevetsky, Eugene (IT) wrote: >Is it possible to use boost::ref() or boost::lambda::var() of an >abstract class as a parameter to boost::lambda::bind()? >It seems that compiler attempts to instantiate an object of that >abstract class. >Example: > >----------------- >using namespace boost; >using namespace boost::lambda; >class Y >{ >public: > virtual void foo() = 0; > void foo2 (){ } >}; >class Z : public Y >{ >public: > void foo(){} >}; > >class TT >{ >public: > void test( Y& y ) { y.foo2(); } >}; > >int main() >{ > std::vector<TT> xt; > Z z; > Y &y = z; > std::for_each (xt.begin(), xt.end(), bind(&TT::test,_1, >ref(y))); > return 0; >} >---------------------- > >And Error message from g++ (GCC) 3.2.3: > >--------------------------------- >/boost/tuple/detail/tuple_basic.hpp: In instantiation of >`boost::tuples::cons<Y, boost::tuples::null_type>': >/boost/tuple/detail/tuple_basic.hpp:326: instantiated from >`boost::tuples::cons<boost::tuples::null_type, boost::tuples::cons<Y, >boost::tuples::null_type> >' >/boost/tuple/detail/tuple_basic.hpp:326: instantiated from >`boost::tuples::cons<void (TT::*const)(Y&), >boost::tuples::cons<boost::tuples::null_type, boost::tuples::cons<Y, >boost::tuples::null_type> > >' >/boost/lambda/detail/lambda_functor_base.hpp:151: instantiated from >`boost::lambda::detail::has_null_type<boost::tuples::cons<void >(TT::*const)(Y&), boost::tuples::cons<boost::tuples::null_type, >boost::tuples::cons<Y, boost::tuples::null_type> > > >' >/boost/lambda/detail/lambda_functor_base.hpp:229: instantiated from
`boost::lambda::detail::deduce_non_ref_argument_types<boost::tuples::tu
p le<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, boost::tuples::null_type>' /boost/lambda/detail/lambda_functor_base.hpp:412: instantiated from `boost::lambda::lambda_functor_base<boost::lambda::action<3, boost::lambda::function_action<3, boost::lambda::detail::unspecified>
, boost::tuples::tuple<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >::sig<boost::tuples::null_type>' /boost/lambda/detail/lambda_functors.hpp:135: instantiated from
:lambda::action<3, boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >' lamtest.cpp:35: instantiated from here /boost/tuple/detail/tuple_basic.hpp:320: cannot declare field `boost::tuples::cons<Y, boost::tuples::null_type>::head' to be of type `Y' /boost/tuple/detail/tuple_basic.hpp:320: because the following virtual functions are abstract: lamtest.cpp:12: virtual void Y::foo() ----------------------------------------
Thanks,
Eugene Vishnevetsky --------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is
`boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost : prohibited.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
On Jul 5, 2005, at 9:06 PM, Vishnevetsky, Eugene ((IT)) wrote:
I came across this problem in the real project where I don't control the class that corresponds to class Y of the example, so I can't change the signature of the member function. I could write a wrapper function that takes Y*, but after some point the code with a simple 'for' loop becomes cleaner and more readable than the one using lambda. If this problem is not a bug, but an inherent limitation of the lambda library or its current implementation, it would be nice if it is mentioned in the documentation.
It's a bug, but requires quite a bit of changes to fix. LL/Phx fusion will (it will happen eventually :) resolve it. Best, Jaakko
Thanks, Eugene Vishnevetsky
Roman Krylov wrote:
Perhaps the only solution here is to use Y* instead of Y& with corresponding modifications; this way there is no need for var() or smth similar. Why not?
Is it possible to use boost::ref() or boost::lambda::var() of an abstract class as a parameter to boost::lambda::bind()? It seems that compiler attempts to instantiate an object of
Vishnevetsky, Eugene (IT) wrote: that
abstract class. Example:
----------------- using namespace boost; using namespace boost::lambda; class Y { public: virtual void foo() = 0; void foo2 (){ } }; class Z : public Y { public: void foo(){} };
class TT { public: void test( Y& y ) { y.foo2(); } };
int main() { std::vector<TT> xt; Z z; Y &y = z; std::for_each (xt.begin(), xt.end(), bind(&TT::test,_1, ref(y))); return 0; } ----------------------
And Error message from g++ (GCC) 3.2.3:
--------------------------------- /boost/tuple/detail/tuple_basic.hpp: In instantiation of `boost::tuples::cons<Y, boost::tuples::null_type>': /boost/tuple/detail/tuple_basic.hpp:326: instantiated from `boost::tuples::cons<boost::tuples::null_type, boost::tuples::cons<Y, boost::tuples::null_type> >' /boost/tuple/detail/tuple_basic.hpp:326: instantiated from `boost::tuples::cons<void (TT::*const)(Y&), boost::tuples::cons<boost::tuples::null_type, boost::tuples::cons<Y, boost::tuples::null_type> > >' /boost/lambda/detail/lambda_functor_base.hpp:151: instantiated from `boost::lambda::detail::has_null_type<boost::tuples::cons<void (TT::*const)(Y&), boost::tuples::cons<boost::tuples::null_type, boost::tuples::cons<Y, boost::tuples::null_type> > > >' /boost/lambda/detail/lambda_functor_base.hpp:229: instantiated from
`boost::lambda::detail::deduce_non_ref_argument_types<boost::tuples:: tu p le<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, boost::tuples::null_type>' /boost/lambda/detail/lambda_functor_base.hpp:412: instantiated from `boost::lambda::lambda_functor_base<boost::lambda::action<3, boost::lambda::function_action<3, boost::lambda::detail::unspecified>
, boost::tuples::tuple<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >::sig<boost::tuples::null_type>' /boost/lambda/detail/lambda_functors.hpp:135: instantiated from
`boost::lambda::lambda_functor<boost::lambda:: lambda_functor_base<boost : :lambda::action<3, boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<void (TT::*const)(Y&), const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Y&, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >' lamtest.cpp:35: instantiated from here /boost/tuple/detail/tuple_basic.hpp:320: cannot declare field `boost::tuples::cons<Y, boost::tuples::null_type>::head' to be of type `Y' /boost/tuple/detail/tuple_basic.hpp:320: because the following virtual functions are abstract: lamtest.cpp:12: virtual void Y::foo() ----------------------------------------
Thanks,
Eugene Vishnevetsky --------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users <http://lists.boost.org/mailman/listinfo.cgi/boost-users>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Jaakko Järvi, jarvi@cs.tamu.edu
Jaakko Järvi wrote:
On Jul 5, 2005, at 9:06 PM, Vishnevetsky, Eugene ((IT)) wrote:
I came across this problem in the real project where I don't control the class that corresponds to class Y of the example, so I can't change the signature of the member function. I could write a wrapper function that takes Y*, but after some point the code with a simple 'for' loop becomes cleaner and more readable than the one using lambda. If this problem is not a bug, but an inherent limitation of the lambda library or its current implementation, it would be nice if it is mentioned in the documentation.
It's a bug, but requires quite a bit of changes to fix. LL/Phx fusion will (it will happen eventually :) resolve it.
Definitely! Daniel Wallin has done the last remaining part of the algorithms. Dan Marsden is working on porting LL exceptions. I think we'll see it happen sooner rather than later. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Jaakko Järvi wrote:
It's a bug, but requires quite a bit of changes to fix. LL/Phx fusion will (it will happen eventually :) resolve it.
Definitely! Daniel Wallin has done the last remaining part of the algorithms. Dan Marsden is working on porting LL exceptions. I think we'll see it happen sooner rather than later.
Will it pass the boost::bind tests? :-)
Peter Dimov wrote:
Joel de Guzman wrote:
Jaakko Järvi wrote:
It's a bug, but requires quite a bit of changes to fix. LL/Phx fusion will (it will happen eventually :) resolve it.
Definitely! Daniel Wallin has done the last remaining part of the algorithms. Dan Marsden is working on porting LL exceptions. I think we'll see it happen sooner rather than later.
Will it pass the boost::bind tests? :-)
That's an affirmative :-) I just tested it a while ago to be sure. The test passes. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Peter Dimov wrote:
Joel de Guzman wrote:
Jaakko Järvi wrote:
It's a bug, but requires quite a bit of changes to fix. LL/Phx fusion will (it will happen eventually :) resolve it.
Definitely! Daniel Wallin has done the last remaining part of the algorithms. Dan Marsden is working on porting LL exceptions. I think we'll see it happen sooner rather than later.
Will it pass the boost::bind tests? :-)
That's an affirmative :-) I just tested it a while ago to be sure. The test passes.
Ooops. I misunderstood your question. I thought you asked if the test as posted by the OP passes; and sure it does. I havent tried running the boost::bind tests yet. Will do.... Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (4)
-
Jaakko Järvi -
Joel de Guzman -
Peter Dimov -
Vishnevetsky, Eugene (IT)