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

[optional] Comparing boost::optional<T> to NULL yield inconsistent results
by Martin B. 12 Apr '11

12 Apr '11

Hi. I have the following problem: One of our devs used (my_opt != NULL) to check an boost::optional for emptiness. This lead me to write the following test case: ... using namespace std; boost::optional<int> num_opt; boost::optional< std::string > obj_opt; if(obj_opt) { cout << "(3) Object: " << *obj_opt << endl; } // Compiles and does what the user intended - // BUT is this what the boost optional interface intends?? - // namely checking the optional for empty: if(obj_opt != NULL) { cout << "(4) Object: " << *obj_opt << endl; } if(num_opt) { cout << "(1) Integer: " << *num_opt << endl; } // Compiles and crashes, because the user actually // should have written if(num_opt) but, being used to pointers, // wrote the below, which compiles fine, but does not check for empty // but for equality with zero: if(num_opt != NULL) { cout << "(2) Integer: " << *num_opt << endl; } ... I find the behaviour of boost::optional<int> vs. opt<ClassType> highly un-intuitive. Wouldn't it be better if comparing an boost::optional always required to "dereference" it? I checked the headers (Boost 1.44) and sadly there doen't seem to be a preprocessor switch to disable the implicit comparison operators ... I would appreciate if other users could comment on my observations. Thanks! cheers, Martin

1 0

[PBGL] add_edge return type
by Cosimo Calabrese 12 Apr '11

12 Apr '11

Hi to all, I'm trying to use the PBGL lib on VS2010, WinXP, with OpenMPI support; I've compiled without any problem the "dijkstra_shortest_paths.cpp" that I've found in \boost\libs\graph_parallel\example. So I've tried to add a new edge to the graph, and to assign a property value to it. The "classical" mode that I always have used in sequential BGL is: boost::graph_traits<Graph>::edge_descriptor ed; bool inserted; boost::tie( ed, inserted ) = boost::add_edge( boost::vertex( 0, g ), boost::vertex( 0, g ), g ); But the compiler scream... it seems that I can't initialize a tie object in that manner (I've reported the compiler log below). Instead if I first add an edge (with no assignment to tie object), and retrive it with boost::edge function, all works: boost::property_map<Graph, boost::edge_weight_t>::type weightMap = boost::get( boost::edge_weight, g ); boost::graph_traits<Graph>::edge_descriptor ed; bool exists; boost::add_edge( boost::vertex( 0, g ), boost::vertex( 0, g ), g ); boost::tie( ed, exists ) = boost::edge( boost::vertex( 0, g ), boost::vertex( 0, g ), g ); weightMap[ ed ] = 10; What's wrong? Thanks, Cosimo Calabrese. 1>src\main.cpp(75): error C2679: '=' binario: non è stato trovato alcun operatore che accetti un operando destro di tipo 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty>::lazy_add_edge'. È anche possibile che non vi siano conversioni accettabili. 1> with 1> [ 1> OutEdgeListS=boost::vecS, 1> VertexListS=boost::distributedS<boost::graph::distributed::mpi_process_group,boost::vecS>, 1> DirectedS=boost::undirectedS, 1> VertexProperty=vertex_prop, 1> EdgeProperty=boost::property<boost::edge_weight_t,float> 1> ] 1> D:\dev\lib\boost\boost/tuple/detail/tuple_basic.hpp(588): potrebbe essere 'boost::tuples::tuple<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9> &boost::tuples::tuple<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::operator =(const boost::tuples::tuple<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9> &)' 1> with 1> [ 1> T0=boost::detail::parallel::edge_descriptor<boost::detail::edge_desc_impl<boost::directed_tag,unsigned int>> &, 1> T1=bool &, 1> T2=boost::tuples::detail::tie_traits<void>::type, 1> T3=boost::tuples::detail::tie_traits<void>::type, 1> T4=boost::tuples::detail::tie_traits<void>::type, 1> T5=boost::tuples::detail::tie_traits<void>::type, 1> T6=boost::tuples::detail::tie_traits<void>::type, 1> T7=boost::tuples::detail::tie_traits<void>::type, 1> T8=boost::tuples::detail::tie_traits<void>::type, 1> T9=boost::tuples::detail::tie_traits<void>::type 1> ] 1> durante la ricerca di corrispondenza con l'elenco di argomenti '(boost::tuples::tuple<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>, boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty>::lazy_add_edge)' 1> with 1> [ 1> T0=boost::detail::parallel::edge_descriptor<boost::detail::edge_desc_impl<boost::directed_tag,unsigned int>> &, 1> T1=bool &, 1> T2=boost::tuples::detail::tie_traits<void>::type, 1> T3=boost::tuples::detail::tie_traits<void>::type, 1> T4=boost::tuples::detail::tie_traits<void>::type, 1> T5=boost::tuples::detail::tie_traits<void>::type, 1> T6=boost::tuples::detail::tie_traits<void>::type, 1> T7=boost::tuples::detail::tie_traits<void>::type, 1> T8=boost::tuples::detail::tie_traits<void>::type, 1> T9=boost::tuples::detail::tie_traits<void>::type 1> ] 1> and 1> [ 1> OutEdgeListS=boost::vecS, 1> VertexListS=boost::distributedS<boost::graph::distributed::mpi_process_group,boost::vecS>, 1> DirectedS=boost::undirectedS, 1> VertexProperty=vertex_prop, 1> EdgeProperty=boost::property<boost::edge_weight_t,float> 1> ]

1 0

How to skip a sub-directory with filesystem3::recursive_directory_iterator in case of exception?
by Tan, Tom (Shanghai) 12 Apr '11

12 Apr '11

> >Again, I tried something like below. >for (recursive_directory_iterator itr(root, ec), itr_end; itr!=itr_end; >) >{ > ... ; > itr.increment(ec); > if(ec) itr.pop(); >} > This time itr.pop() assertion fails because "pop() on >recursive_directory_iterator with level < 1" > >Anybody got some advice? Thanks. For others facing the same problem, I've reported it as a bug and created Ticket #5403(https://svn.boost.org/trac/boost/ticket/5403). A fix was also attached

1 0

[serialization] enable_if managed serialize function
by Noah Roberts 11 Apr '11

11 Apr '11

I want to do something like so: template < typename Archive, typename T > typename boost::enable_if<some_meta_check<T>>::type serialize(Archive & ar, T & rec, unsigned int const) { ar & boost::serialization::base_object<T::type>(rec); } Unfortunately I run into trouble with ambiguous function call referring to a different <Archive,T> version of serialize declared in the serialization library. Does anyone know of a workaround for this?

1 0

[optional] Could (& should) optional be more space efficient?
by David Blaikie 11 Apr '11

11 Apr '11

>From my initial look through boost::optional's implementation, it seems as though it's doing nothing to optimize its space usage in some trivial cases. The first one I was surprised by was optional<T&> - still uses sizeof(struct { T& t; }) + sizeof(bool) space, rather than simply using a pointer to represent both the reference and the unspecified state (using null, since a reference doesn't use that state). Is there a reason for this (perhaps I'm missing something & a reference is smaller than a pointer in certain implementations). Similarly - would it be worth considering optimizing optional<bool> (though, as per the documentation, this is perhaps a little "tricky" at best, owing to the implicit bool of optional itself) to use one byte instead of two? [long term - I'm wondering if a generic "efficient optionality" could be implemented by arbitrary types - privately exposing an extra unused state from their representation for use by optional only. Then, potentially, making versions of (boost/std)::shared_ptr/unique_ptr that would be never-null (only constructible via make_shared like machinery) & optional<shared_non_null_ptr<T>> would then be an explicit representation of the optional situation, but without any overhead - shared_non_null_ptr<T> would simply expose its null state only to optional<shared_non_null_ptr<T>>]

2 1

Seeking to particular array element while deserializing
by rajiv82 11 Apr '11

11 Apr '11

I have a structure like: struct Header { vector foo; vector bar; }; I have created an array of above structure: Header *ptr = new Header[1000]; Now doing serialization/deserialization works fine with binary_oarchive. But, in some situation, I want to just deserialize particular element of array(say element at index 80). Is it possible using binary archive ? I have a work around of writing each element one by one & while de-serialization, ignore irrelevant data(in our case index 0-79) & then use proper data. But it is not optimum solution. I even tried xml archive with name as index & value as binary object by using make_binary_object. Doing something like: for(int i = 0 ; i<1000; i++) { stringstream ss ; ss << i; ar << make_nvp(ss.str().c_str(), make_binary_object(&ptr[i], 1)) ; } And deserializing 80th index object like: ar >> make_nvp("80", make_binary_object(&ptr[80], 1)) ; Program compiles fine, but result is inconsistent. Please suggest is there any better way to read(deserialize) just one element of an array. -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-to-particular-array-element-whil… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Monitoring thread liveness using multiple threads with a single asio io_service
by Krajnak, Mike (GE Healthcare) 11 Apr '11

11 Apr '11

We have a server implemented with boost::asio that uses a vector of threads with a single io_service as in the asio http server 3 sample program. We want to check on the liveness of threads by having each thread periodically call back to a thread manager so that we can confirm it is still running. To do that we have an inner loop that uses run_one() so we can call our heartbeat function after each action is completed (pseudo code): do { num_ops = io_svc.run_one(ec) heartbeat_to_thread_manager(); } while (num_ops > 0); However, asio makes no garantees on how work is dispatched to threads. In our testing work seems to go prefentially to one thread for several iterations before going to another thread with no pattern that we can find. Is there some way we can change this solution so that we can be reasonably sure each thread will be called at least once in a some period of time or some other mechanism for monitoring thread liveness? Thanks, Mike

1 0

Re: [Boost-users] Compiling Boost with 4 byte packing...
by Brian Nantz 11 Apr '11

11 Apr '11

I finally got boost to build with visual studio 2008 and 4-byte packing. Here is what I had to do: 1. Edit the tools\build\v2\user-config.jam and add: using msvc : vc9 : "D:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe" : <compileflags>-DBOOST_HAS_ABI_HEADERS <compileflags>-DBOOST_PROTO_MAX_ARITY=10 <compileflags>-DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS <compileflags>-DBOOST_MPL_LIMIT_METAFUNCTION_ARITY=10 <compileflags>-DWIN32 <compileflags>-D_DEBUG <compileflags>-D_LIB <compileflags>-D_WIN32_WINNT=0x0501 <compileflags>-D_UNICODE <compileflags>-DUNICODE <compileflags>-DBOOST_ASIO_ENABLE_BUFFER_DEBUGGING <compileflags>-Gm <compileflags>-EHsc <compileflags>-RTC1 <compileflags>-MTd <compileflags>-Zp4 <compileflags>-W4 <compileflags>-c <compileflags>-ZI <compileflags>-TP <linkflags>/MACHINE:X86 ; 2. On the bjam command line use the options: --toolset=msvc-9.0 cxxflags=-Zp4 3. Edit boost/config/user.hpp: // BOOST_ABI_PREFIX: A prefix header to include in place of whatever // boost.config would normally select, any replacement should set up // struct packing and alignment options as required. #define BOOST_ABI_PREFIX <boost/config/abi/saplib_prefix.hpp> // BOOST_ABI_SUFFIX: A suffix header to include in place of whatever // boost.config would normally select, any replacement should undo // the effects of the prefix header. #define BOOST_ABI_SUFFIX <boost/config/abi/saplib_suffix.hpp> The prefix header just contains #pragma pack(push,4) and the suffix just has #pragma pack(pop) 4. For some reason ASIO does not use the boost ABI header prefix and suffix. It has its own. Edit boost/asio/detail/push_options.hpp to use #pragma pack(push,4). The boost build now completes cleanly (with no errors or warnings) on boost 1.43. There seems to be some room for simplification or improvement here?

1 0

[boost-users][parameter] ArgumentPack Documentation Best Practices
by Christoph Heindl 11 Apr '11

11 Apr '11

Hi, I wonder if anyone could share his best practices as far as documenting Boost.Parameter enabled constructors is concerned. I'm currently doing something along the lines of /** Construct from named parameters and use defaults where parameters are empty * * * \tparam Opts ArgumentPack of options. The following options are supported * - \a min_group_size minimum number of supporting correspondences to form a group. * - \a ntrials number of times to form basis from two randomly selected correspondences. * - \a bin_size_pos quantization size for transformed point coordinates. * - \a bin_size_orientation quantization in radians for surface orientation angles. * */ template<class Opts> group_geo_hash(const Opts &opts) { this->init( opts[Keywords::_min_group_size | 10], opts[Keywords::_bin_size_pos | LibFundament::rasFloat(10)], opts[Keywords::_orientation_rad | LibFundament::rasFloat(0.2)], opts[Keywords::_ntrials | 0]); } } which is sub-optimal, because default values for options and option types are missing. Doxygen can deduce types for regular parameters as well as default values. Ideally this should work for boost.parameters as well :) Even better, Doxygen could warn about undocumented parameters. Any thoughts? Best regards, Christoph

2 3

Re: [Boost-users] [Boost.Thread] Multithreaded Multithreaded Server (Ian Mallett)
by Marat Abrarov 11 Apr '11

11 Apr '11

> Hi, > > Fairly new to Boost. Bear with me. > > I'm trying to write a multithreaded multithreaded server (two multithreaded > operations): ideally, there should be a single process, containing at least two threads. The first > thread handles various tasks (and can start other threads to help it as well). The other thread waits > for incoming connections, and adds a new thread for each one: http://sourceforge.net/projects/asio-samples/ Look at projects "echo_server" and "qt_echo_server". They use 2 thread pools among main (GUI) thread. One thread pool (size is 1-2 threads) executes session management loop: acceptance (with limited number of active sessions), start of accepted session, end of all sessions. Second thread pool (by default is CPU number bounded) executes sessions' loops: start of asynchronous read, start of asynchronous write, IO operation completion handling. Regards, Marat Abrarov.

1 0