June 2009 - Boost-users - lists.preview.boost.org

[Lambda] Compiler dependent error, can anyone explain?
by Robert Jones 15 Jun '09

15 Jun '09

Hi Peeps I have this cut down code example #include <vector> #include <map> #include <algorithm> #include <boost/shared_ptr.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> template < typename Iter, typename Pred > bool any_of_if( Iter first, Iter last, Pred pred ) { return std :: find_if( first, last, pred ) != last; } struct A { }; bool fnOfA( const A & ); typedef std :: vector< boost :: shared_ptr< A > > VecOfPtr; typedef std :: map< int, VecOfPtr > MapOfVecOfPtr; bool contains_if( const VecOfPtr &, bool ( * pred )( const VecOfPtr :: value_type :: value_type &) ); bool f( const boost :: shared_ptr< MapOfVecOfPtr > & myMap ) { using namespace boost; return any_of_if( myMap -> begin( ), myMap -> end( ), lambda :: bind( contains_if, lambda :: bind( & MapOfVecOfPtr :: value_type :: second, lambda :: _1 ), fnOfA ) ); } This compiles under gcc (3.4.4), but under Vis Studio 2008 gives a huge error message, (attached), but summarised as boost\boost/tuple/detail/tuple_basic.hpp(439) : error C2664: 'boost::tuples::detail::non_storeable_type<T>::non_storeable_type(const boost::tuples::detail::non_storeable_type<T> &)' : cannot convert parameter 1 from 'bool (__cdecl &)(const A &)' to 'const boost::tuples::detail::non_storeable_type<T> &' It also goes away if I introduce a temporary local variable for fnOfA. Is this a know bug in VisStudio or Boost, possibly with a known solution? Thanks, - Rob.

2 1

[BGL] destroying a subgraph
by fabricio 15 Jun '09

15 Jun '09

Hi all, I have a vector of subgraphs and at certain situations I have to remove some vertex from one of them. As this is not possible for now, I simply create a temporary subgraph with the vertices I want and replace the old one. The problem is that the memory allocated from the old one is not freed correctly. What should be the correct procedure to do so?? a code snippet: void modgraph::remove_a_vertex(unsigned idx, Vertex vt) { Graph* temp_subg = &g.create_subgraph(); graph_traits < Graph >::vertex_iterator itg, end; for (tie(itg,end) = vertices(*subg(idx)); itg != end; ++itg) { if( (*subg(idx)).local_to_global(*itg) != vt ) { add_vertex(*itg, *temp_subg); } } *subg(idx) = *temp_subg; } where subg is a vector of subgraphs.

1 1

Re: [Boost-users] [mpi] irecv / send problem
by Brian Wood 15 Jun '09

15 Jun '09

Nick Collier writes: > Hmm, I think it should work. Thanks though. The example I posted was > modified from: > http://ci-tutor.ncsa.illinois.edu/content.php?cid=1137 > Namely, > /* deadlock avoided */ > #include <stdio.h> > #include <mpi.h> > void main (int argc, char **argv) { > int myrank; > MPI_Request request; > MPI_Status status; > double a[100], b[100]; > MPI_Init(&argc, &argv); /* Initialize MPI */ > MPI_Comm_rank(MPI_COMM_WORLD, &myrank); /* Get rank */ > if( myrank == 0 ) { > /* Post a receive, send a message, then wait */ > MPI_Irecv( b, 100, MPI_DOUBLE, 1, 19, MPI_COMM_WORLD, &request ); > MPI_Send( a, 100, MPI_DOUBLE, 1, 17, MPI_COMM_WORLD ); > MPI_Wait( &request, &status ); > } > else if( myrank == 1 ) { > /* Post a receive, send a message, then wait */ > MPI_Irecv( b, 100, MPI_DOUBLE, 0, 17, MPI_COMM_WORLD, &request ); > MPI_Send( a, 100, MPI_DOUBLE, 0, 19, MPI_COMM_WORLD ); > MPI_Wait( &request, &status ); > } > MPI_Finalize(); /* Terminate MPI */ > } > I am not sure why MPI was added to Boost. Recently there was an effort to get Boost libs ready for the next C++ standard. I don't think the MPI library was considered in that as it's ties to C are so strong. Having to specify MPI_DOUBLE above when a and b are both declared of type double is sad. Naming it "Message Passing Interface" when you are restricted to messages of a single type is hardly an apt name. If it's going to be in Boost, it may wind up being called the Most Pitiful Interface. -- Brian Wood Ebenezer Enterprises www.webEbenezer.net "The New Deal and Great Society entrenched a welfare mentality in [the US]. The idea of the federal government as the great provider has even moved to the level of corporate America, with business 'leaders' flying to Washington in private jets to beg Congress for handouts to keep their companies afloat." Bill Ragle

3 2

Re: [Boost-users] [ptr_container] Const & non-const ptr_map iteration over mapped values
by Rodolfo Federico Gamarra 15 Jun '09

15 Jun '09

Hi Thorsten, Thanks a lot for your reply. > I would just implement this as (abbreviated) > > template< class R > > struct X > { > template< class Pair > > R operator()( const Pair& p ) const { return *p.second; } > }; umm ... yep, you're right: the T1 and T2 types weren't used in my original alternative. Your struct X needs, tough, the result_type nested typedef (maybe that's why you said "abbreviated"). > Well, why do you want to define that typedef, when it is easier to infer > the type automatically? Yep, it's easier and shorter; but this came so as to to fulfill C++ standard requirements over an "unary function" (as of my understanding). Nevertheless, it seems that (at least in this case) Boost's requirements are weaker, without requiring this other nested typedef. > Why? Dont map::value_type v = *m.find(x) work? Well, yes: at first, this came as a result of the last point: it the arg_type has to be provided (if it has...), then a function template is a no-go alternative. So, an specifically typed function has to be defined: what's the arg_type? The "detail" type shouldn't be used one, and a std::pair didn't work due to the lack of implicit conversion. Then I saw the other nested template typedefs (const_reference and reference). But the question of the to std::pair remainded: does it help with interoperability with code that worked on maps that used the standard std::pair? Is it free to provide it, or there's some impossibility? > Again, why do you want to do this? For the aforementioned reasons, but as you pointed that template parameter wasn't actually needed. Anyway, seemed reasonable to have it provided by ptr_map. Thanks a lot again. Cheers. Rodolfo.

1 0

[lambda] warnings from Lambda
by Robert Jones 15 Jun '09

15 Jun '09

I'm finding that pretty much every lambda :: bind call I make is producing a c4180 warning under Microsoft which I think is warning about the application a meaningless qualifier to the first argument of the bind call. So given, say bool f( int ); lambda::bind( f, lambd::_1 ); inside lambda_traits a const qualifier is applied to f, which is already const, hence the warning. Anyone know how to avoid this, other than #pragma to disable the warning? Thanks, - Rob.

2 3

Copy a smart pointer into allocated memory
by Tiago Alves 15 Jun '09

15 Jun '09

Hi, and sorry for the probable newbieness of this question! I want to put weak_ptr into a piece of memory previously allocated. this is my code: // construct a weak_ptr from a share_ptr boost::weak_ptr<Obj>* cameraPtr = new boost::weak_ptr<Obj>(obj_share_ptr); // lua_newuserdata allocs memory and returns a pointer to it, just like malloc. boost::weak_ptr<Obj>* camera = static_cast<boost::weak_ptr<Obj>*>(lua_newuserdata(pLuaState,sizeof(boost::weak_ptr<Obj>))); Now i want camera to be a weak_ptr of ObjPtr. I tried different ways to do this, such as *camera = boost::weak_ptr<Obj>(obj_share_ptr); or camera->swap(*cameraPtr); or *camera = *cameraPtr; I think none of these work because in fact they all do a swap() between camera and cameraPtr. Since camera is just an malloc, it will try to swap dirty memory and segfault sometimes (yes, sometimes this worked). Out of desperation, i did this: memcpy(camera,cameraPtr,sizeof(boost::weak_ptr<Obj>)); Which seems to work but it stinks. It's copying an object with memcpy instead of using its constructor. Is there a better way to do this? Thanks, Tiago Alves

4 4

[BGL] Searching for index_map
by caligulaemperorofrome＠yahoo.com 15 Jun '09

15 Jun '09

When I run my program the output gives an id to each edge and vertex like so. <edge id="e262" source="n46" target="n43"> This must be the index. So how can I access this index? When I put the following in my code it fails to compile. error: ‘index_map’ was not declared in this scope for (tie(edge_iter, edges_end) = edges(g); edge_iter != edges_end; ++edge_iter) { get(index_map, *edge_iter, g); } Do I need "get_property(index_map) or something? My Graph declaration is as follows. typedef adjacency_list < listS, vecS, directedS >::edge_descriptor edge_t; typedef adjacency_list < listS, vecS, directedS >::vertex_descriptor vertex_t; typedef adjacency_list < listS, vecS, directedS, property< vertex_predecessor_t, vertex_t, vertex_properties >, property< edge_reverse_t, edge_t, edge_properties > > graph_t; Thanks

2 1

[BGL] destroying a subgraph
by "Christian Bähnisch" 15 Jun '09

15 Jun '09

Hello, I'm trying to implement the IncidenceGraph concept for an non-BGL undirected graph like datastructure. Following the boost documentation the target function used with edges from out_edges(u,g) must give vertices != u. Can somebody please explain me why this requirement is in BGL! I think it can make the adaption very difficult as it requieres to artificially orientate undirected edges for each call to out_edges. Any help would be much appreciated! Thanks in advance, Chris -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

2 2

[ptr_container] Const & non-const ptr_map iteration over mapped values.
by Rodolfo Federico Gamarra 15 Jun '09

15 Jun '09

Hi all!! In my class have an internal member of type typedef boost::ptr_map<int, Component> InternalComponentCollection; I'd like to provide const and non-const iterators, through appropriate two pairs of begin / end methods, in order to have "const Component&" and "Component&" as return type in each of the dereferencing operators. What's the way to do that? What I tried: Since the underlying storage relies in "pair" with a pointer, I thought of using a transform iterator to project "second" and then dereference the pointer; something like, for instance, ComponentIterator Begin() { return boost::make_transform_iterator(fComponents.begin(), fResolver); } where fResolver is an instance of template<class T1, class T2, class R> struct SecondResolver { typedef R result_type; template< template <typename,typename> class Pair> result_type operator()(const Pair<T1, const T2>& p) const { return * p.second; } }; and having typedef SecondResolver<KeyType, MappedType, MappedReference> ComponentResolver; typedef typename InternalComponentCollection::key_type KeyType; typedef typename InternalComponentCollection::mapped_type MappedType; typedef typename InternalComponentCollection::mapped_reference MappedReference; typedef typename InternalComponentCollection::iterator PairIterator; typedef boost::transform_iterator<ComponentResolver, PairIterator> ComponentIterator; The case for const iteration is similarly implemented, using the following typedefs: typedef SecondResolver<KeyType, ConstMappedType, ConstMappedReference> ConstComponentResolver; typedef const Component* /* No nested typedef for this...*/ ConstMappedType; typedef typename InternalComponentCollection::const_mapped_reference ConstMappedReference; typedef typename InternalComponentCollection::const_iterato PairConstIterator; typedef boost::transform_iterator<ConstComponentResolver, PairConstIterator> ComponentConstIterator; My remarks about my solution are: 1) SecondResolver is not an "UnaryFunction" in the sense of the C++ standard, since there's no "argument_type" nested typedef. Tough it seems that that isn't actually required by transform_iterator. I have problems in trying to define that typedef (see 2). 2) The actual pairs are instances of boost::ptr_container_detail::ref_pair so it wouldn't be right to typedef that as arg type (it's a "detail"). This class provides implicit conversion from std::pair, but no implicit conversion to std::pair. So that's why I wrote the operator() as a template function, since cannot give the operator an explicit type: nor ref_pair (being a detail), nor std::pair (not having the conversion). Should that conversion be provided? 3) I wrote ConstMappedType typedef explicitly, without relying in a nested typedef in the original class. Doing typedef const MappedType ConstMappedType; doesn't work because the const binds to the pointer, not to the pointed type. Other possibility I looked was to have instead (for the const case, the other one is similar): typedef typename InternalComponentCollection::const_reference ConstReference; typedef SecondResolver2<ConstMappedReference, ConstReference> ConstComponentResolver; template<class RetType, class ArgType> struct SecondResolver2 { typedef RetType result_type; typedef ArgType argument_type; result_type operator()(argument_type p) const { return * p.second; } }; Anyone is better? Thanks a lot in advance. -- Rodolfo Federico Gamarra

2 1

Unresolved symbols
by Robert Dailey 15 Jun '09

15 Jun '09

Hi everyone, I'm using Boost 1.39, and I'm getting the following linker errors on MSVC9: MainWindow.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_system_category(void)" (__imp_?get_system_category@system @boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'system_category''(void)" (??__Esystem_category@system@boost@@YAXXZ) OverlayViewModel.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_system_category(void)" (__imp_?get_system_category@system @boost@@YAABVerror_category@12@XZ) OverlayNode.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_system_category(void)" (__imp_?get_system_category@system @boost@@YAABVerror_category@12@XZ) MainWindow.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_generic_category(void)" (__imp_?get_generic_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'generic_category''(void)" (??__Egeneric_category@system@boost@@YAXXZ) OverlayViewModel.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_generic_category(void)" (__imp_?get_generic_category@system@boost@@YAABVerror_category@12@XZ) OverlayNode.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::get_generic_category(void)" (__imp_?get_generic_category@system@boost@@YAABVerror_category@12@XZ) The issues above don't really make any sense. The calling convention, according to the information above, is __cdecl, and in my project settings I'm using cdecl as well. I found several posts about this on the mailing list but no solutions were offered that I could see. How can I resolve these issues? Note that I am using static libraries.

2 2