[Boost-users] [Bind][Lambda] Processing containers of pointers

[Robert Jones]

Hi All

I believe boost.bind has the capability to look through pointers and smart pointers to
transparently process the pointed-to objects. Does boost.lambda.bind also have this
capability?

I.e., this bit of code (and I am specifically using boost 1.37 for this btw)

#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <boost/lambda/construct.hpp>
#include <boost/shared_ptr.hpp>
#include <algorithm>
#include <vector>

struct A
{
    A( int );
    void f( );
};

int main( )
{
    using namespace boost::lambda;

    std::vector< A * > pv;
    std::vector< boost::shared_ptr< A > > sv;
    std::for_each( pv.begin( ), pv.end( ), bind( &A::f, _1 ) );
    std::for_each( sv.begin( ), sv.end( ), bind( &A::f, _1 ) ); // error here.

}

Thanks,

- Rob.

[Roman Perepelitsa]

2010/3/24 Robert Jones <robert...@gmail.com>

Hi All

I believe boost.bind has the capability to look through pointers and smart pointers to
transparently process the pointed-to objects. Does boost.lambda.bind also have this
capability?

As your code demonstrates, lambda.bind works for  pointers, but not for smart pointers.

Roman Perepelitsa.

[Peter Dimov]

Robert Jones wrote:
> Hi All
>
> I believe boost.bind has the capability to look through pointers and smart
> pointers to
> transparently process the pointed-to objects. Does boost.lambda.bind also
> have this
> capability?

No, but you should be able to use bind( &A::f, *_1 ) for that.

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Steven Watanabe]

AMDG

Peter Dimov wrote:

> Robert Jones wrote:
>> I believe boost.bind has the capability to look through pointers and
>> smart
>> pointers to
>> transparently process the pointed-to objects. Does boost.lambda.bind
>> also
>> have this
>> capability?
>
> No, but you should be able to use bind( &A::f, *_1 ) for that.

This should work unless A is an abstract type.

In Christ,
Steven Watanabe

[Robert Jones]

On Wed, Mar 24, 2010 at 11:39 AM, Peter Dimov <pdi...@pdimov.com> wrote:

Robert Jones wrote:

Hi All

I believe boost.bind has the capability to look through pointers and smart
pointers to
transparently process the pointed-to objects. Does boost.lambda.bind also
have this
capability?

No, but you should be able to use bind( &A::f, *_1 ) for that.

Which I imagine passes by value? Hence the original objects pointed to by
the container pointers are unchanged?

Is that the semantics implemented by boost::bind when it looks through smart pointers?

Thanks,

- Rob.

[Peter Dimov]

Robert Jones wrote:
> On Wed, Mar 24, 2010 at 11:39 AM, Peter Dimov <pdi...@pdimov.com> wrote:
>
>> Robert Jones wrote:
>>
>>> Hi All
>>>
>>> I believe boost.bind has the capability to look through pointers and
>>> smart
>>> pointers to
>>> transparently process the pointed-to objects. Does boost.lambda.bind
>>> also
>>> have this
>>> capability?
>>>
>>
>> No, but you should be able to use bind( &A::f, *_1 ) for that.
>
> Which I imagine passes by value?

It should pass by reference.

You could also use bind( mem_fn( &A::f ), _1 ), if you like that better.
This is what boost::bind does under the hood, more or less.

[Robert Jones]

On Wed, Mar 24, 2010 at 3:15 PM, Steven Watanabe <watan...@gmail.com> wrote:

AMDG

Peter Dimov wrote:

Robert Jones wrote:

I believe boost.bind has the capability to look through pointers and smart
pointers to
transparently process the pointed-to objects. Does boost.lambda.bind also
have this
capability?

No, but you should be able to use bind( &A::f, *_1 ) for that.

This should work unless A is an abstract type.

I don't understand this; if this passes by reference as Peter states in this thread, why can
A not be an abstract type?

- Rob.

[Steven Watanabe]

AMDG

Robert Jones wrote:
> On Wed, Mar 24, 2010 at 3:15 PM, Steven Watanabe <watan...@gmail.com>wrote:
>

>> Peter Dimov wrote:
>>
>>> No, but you should be able to use bind( &A::f, *_1 ) for that.
>>>
>> This should work unless A is an abstract type.
>>
> I don't understand this; if this passes by reference as Peter states in this
> thread, why can
> A not be an abstract type?
>

Because of a long standing bug in the return type deduction mechanism.