This may be a reasonable regression, but I thought I'd bring it up in case its a regression that should be fixed. My sample code and some error outputs are attached. Oh, and in case you're wondering why I would do this, its basically because I really like the find_if/bind/equal_to thing, and I need the char[64] for easy fwrite/fread'ing. Thanks
Thomas Matelich wrote:
This may be a reasonable regression, but I thought I'd bring it up in case its a regression that should be fixed. My sample code and some error outputs are attached.
This regression is caused by the fact that in 1.32, bind( &Foo::bar, _1 ) no longer returns a reference to Foo::bar; it wants to return by value instead. The change was motivated by the fact that bind( &Foo::bar, bind( createFoo ) ), where createFoo returned a Foo by value, would return a reference to an object that was already destroyed. You can fix your example by using bind<string>( &Foo::bar, _1 ), which should work on the compilers you listed. The CVS version also supports bind<string>( &Foo::bar, _1 ) == test
On Tue, 15 Mar 2005 20:26:51 +0200, Peter Dimov
Thomas Matelich wrote:
This may be a reasonable regression, but I thought I'd bring it up in case its a regression that should be fixed. My sample code and some error outputs are attached.
This regression is caused by the fact that in 1.32, bind( &Foo::bar, _1 ) no longer returns a reference to Foo::bar; it wants to return by value instead.
The change was motivated by the fact that bind( &Foo::bar, bind( createFoo ) ), where createFoo returned a Foo by value, would return a reference to an object that was already destroyed.
You can fix your example by using bind<string>( &Foo::bar, _1 ), which should work on the compilers you listed.
The CVS version also supports
bind<string>( &Foo::bar, _1 ) == test
thanks for the info and fix. tom
participants (2)
-
Peter Dimov -
Thomas Matelich