boost::variant and SGI's compose1 cause constness error
Hi there, I have a problem using boost::variant. I want apply_visitor to go through a list of pairs whose first type is a variant. Using compose1 and select1st from the SGI extensions to the STL yields a constness error. The problem is illustrated by the attached code which shoud be compiled with the g++ (the SGI extensions are here available via __gnu_cxx). What's wrong? Is it my fault using the library or is it a missing const version in apply_visitor_delayed_t()? Thanks a lot for any hints! Best, Erwin
junkmail.hoefling@arcor.de wrote:
Hi there,
I have a problem using boost::variant. I want apply_visitor to go through a list of pairs whose first type is a variant. Using compose1 and select1st from the SGI extensions to the STL yields a constness error. The problem is illustrated by the attached code which shoud be compiled with the g++ (the SGI extensions are here available via __gnu_cxx).
What's wrong? Is it my fault using the library or is it a missing const version in apply_visitor_delayed_t()?
Judging by the comments in apply_visitor_delayed.hpp, it may be missing the const overloads on purpose... but I think that this is a mistake. FWIW, for_each( v.begin(), v.end(), bind( apply_visitor(_dummy), bind<TMixed&>( &TPair::first, _1 ) ) ); works (when using boost/bind.hpp), but it isn't particularly elegant.
Thanks Peter Dimov! When I posted the message, the scales fell from my eyes and I realized a even simpler workaround: Simply perform the loop myself and use the explicit version of apply_visitor: Replace the for_each construction for_each( v.begin(), v.end(), compose1(apply_visitor(_dummy), select1st<TPair>() ) ); // yields a const error by the explicit loop for( vector<TPair>::iterator it=v.begin(); it!=v.end(); ++it ) apply_visitor(dummy(), it->first); This is a little bit less general since we have to know the type of v in advance, however, for me it works. Anyway, I would consider the problem as a bug in boost::visitor. The remark in apply_visitor_delayed.hpp about the dead reference doesn't make sense to me. As long as apply_visitor is in action, a temporary visitor object is alive, isn't it?
participants (1)
-
Erwin -
junkmail.hoefling＠arcor.de
-
Peter Dimov