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

Re: [Boost-users] Boost.Random Generator ignores seed
by Alex Hagen-Zanker 13 Nov '10

13 Nov '10

> I'm using mt19937 random number generator, belonging to Boost.Random >library, and it looks to ignore my call to seed. > I show relevant code. > > static mt19937 gen; > static MiniUni cien(1, 100); > static variate_generator d100(gen, cien); > > int main() { > { > struct timeval time; > gettimeofday( > gen.seed(time.tv_usec); > } > > And it generates the same sequence over and over. I've double-checked >that time.tv_usec really changes. Could it be that variate_generator d100(gen, cien) defaults to variate_generator<mt19937, MiniUni> d100(gen,cien) whereas you really need variate_generator<mt19937&, MiniUni> d100(gen,cien)? The constructor of the variate_generator now makes a copy of gen and changing the seed of gen afterwards does not affect the variate_generator. Solution: explicitly use variate_generator<mt19937&, MiniUni>(gen,cien). Kind regards, Alex

1 0

Re: [Boost-users] Boost.Random Generator ignores seed
by alfC 13 Nov '10

13 Nov '10

On Nov 13, 2:09 pm, Juan Antonio Farré Basurte <j...(a)tinet.org> wrote: > Hello, > > I'm using mt19937 random number generator, belonging to Boost.Random > library, and it looks to ignore my call to seed. > I show relevant code. > > static mt19937 gen; > static MiniUni cien(1, 100); > static variate_generator d100(gen, cien); > > ..... > > int main() { > { > struct timeval time; > gettimeofday( > gen.seed(time.tv_usec); > } > > .... > > And it generates the same sequence over and over. I've double-checked > that time.tv_usec really changes. > Any help would be appreciated. > Thanks, Try with a negative seed. gen.seed( - time.tv_usec); -- Alfredo

1 0

[serialization][thread] possible regressions? (was: [1.45.0] Beta 1 available from SourceForge)
by Eric Niebler 13 Nov '10

13 Nov '10

I don't know whether this is a serialization issue or a thread issue. Robert, Anthony, can you two weigh in? Eric On 11/11/2010 6:32 AM, Ruediger Berlich wrote: > Hi again, > > here is an update: I have now also tested the behaviour below ("pure virtual > method called; terminate called without an active exception" -> related to > Boost.Serialization) with Boost 1.44 and see the same problem. This does not > happen with 1.43. > > Anyway, I thought it might be important to know that whatever causes this > wasn't introduced with 1.45 but 1.44 (and of course I might be doing > something wrong which only triggers now due to 1.44's changes in the > serialization library). > > Thanks and Best Regards, > Ruediger > > > Ruediger Berlich wrote: >> Dear all, >> here are a few experiences with the beta: >> >> Beman Dawes wrote: >> [...] >>> Please download the beta, give it a try, and report any problems you >>> encounter. >> >> Platform: >> ========= >> Kubuntu 10.10 64 bit, g++ 4.4.5 >> >> Compilation: >> ============ >> Runs mostly smoothely, albeit with many warnings of the type: >> >> [...] >> libs/program_options/src/parsers.cpp:233: instantiated from here >> ./boost/function/function_base.hpp:321: warning: dereferencing type-punned >> pointer will break strict-aliasing rules >> ./boost/function/function_base.hpp:325: warning: dereferencing type-punned >> pointer will break strict-aliasing rules >> [...] >> >> This is not a new situation and has been there with many prior versions. >> It happens in different components. >> >> Compiling a complex application >> =============================== >> (The Geneva library's trunk version, close to version 0.85, see >> http://launchpad.net/geneva ; depends on probably a dozen different boost >> libraries) >> >> In order to get it to compile I hat to make a single change: >> I had to add "#include <boost/serialization/nvp.hpp>" prior to the >> inclusion of the date_time libraries in a single file (out of some 65 >> headers, some of which also include date_time), or else I would get >> messages of the type >> >> /opt/boost145/include/boost/date_time/gregorian/greg_serialize.hpp: In >> function ‘void boost::serialization::save(Archive&, const >> boost::gregorian::date&, unsigned int)’: >> /opt/boost145/include/boost/date_time/gregorian/greg_serialize.hpp:58: >> error: there are no arguments to ‘make_nvp’ that depend on a template >> parameter, so a declaration of ‘make_nvp’ must be available >> >> I _do_ serialize date_time objects in my application. This is new with >> Boost 1.45 (compared with 1.43). >> >> Running the application >> ======================= >> >> When running the application in serial. multithreaded or networked mode >> (Geneva does distributed parametric optimization, but also allows >> multithreaded optimization and has a serial mode for debugging), I get the >> error: >> >> [...] >> 1000: 4.99999977648258e-05 >> End of optimization reached >> Done ... >> pure virtual method called >> terminate called without an active exception >> Aborted >> >> "Done" is printed at the end of main(), so there are only some singletons >> left to clean up, one of which stems from the Boost.Serialization library, >> AFAIK. >> >> Running the application in gdb yields: >> >> /********************************************************/ >> (gdb) up >> #1 0x00007ffff40726b0 in abort () at abort.c:92 >> 92 abort.c: No such file or directory. >> in abort.c >> (gdb) up >> #2 0x00007ffff49126bd in __gnu_cxx::__verbose_terminate_handler() () from >> /usr/lib/libstdc++.so.6 >> (gdb) up >> #3 0x00007ffff4910906 in ?? () from /usr/lib/libstdc++.so.6 >> (gdb) up >> #4 0x00007ffff4910933 in std::terminate() () from /usr/lib/libstdc++.so.6 >> (gdb) up >> #5 0x00007ffff491128f in __cxa_pure_virtual () from >> #/usr/lib/libstdc++.so.6 >> (gdb) up >> #6 0x00007ffff4fc1f16 in >> > boost::serialization::void_cast_detail::void_caster::operator<(boost::serialization::void_cast_detail::void_caster >> const&) const () from /opt/boost145/lib/libboost_serialization.so.1.45.0 >> (gdb) up >> #7 0x00007ffff4fc282d in >> > boost::serialization::void_cast_detail::void_caster::recursive_unregister() >> const >> () from /opt/boost145/lib/libboost_serialization.so.1.45.0 >> (gdb) up >> #8 0x00007ffff4fc2f27 in >> > boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() >> () from /opt/boost145/lib/libboost_serialization.so.1.45.0 >> (gdb) up >> #9 0x00007ffff4fc289f in >> > boost::serialization::void_cast_detail::void_caster::recursive_unregister() >> const >> () from /opt/boost145/lib/libboost_serialization.so.1.45.0 >> (gdb) up >> #10 0x00007ffff72ad64f in >> > boost::serialization::void_cast_detail::void_caster_primitive<Gem::Geneva::GPersonalityTraits, >> Gem::Geneva::GObject>::~void_caster_primitive (this=0x7ffff7bb7e80, >> __in_chrg=<value optimized out>) at >> /opt/boost145/include/boost/serialization/void_cast.hpp:198 >> 198 recursive_unregister(); >> (gdb) up >> #11 0x00007ffff72ad7be in >> > boost::serialization::detail::singleton_wrapper<boost::serialization::void_cast_detail::void_caster_primitive<Gem::Geneva::GPersonalityTraits, >> Gem::Geneva::GObject> >::~singleton_wrapper ( >> this=0x7ffff7bb7e80, __in_chrg=<value optimized out>) >> at /opt/boost145/include/boost/serialization/singleton.hpp:111 >> 111 m_is_destroyed = true; >> (gdb) up >> #12 0x00007ffff40748c0 in __cxa_finalize (d=0x7ffff7baa2d0) at >> cxa_finalize.c:56 >> 56 cxa_finalize.c: No such file or directory. >> in cxa_finalize.c >> (gdb) up >> #13 0x00007ffff7016366 in __do_global_dtors_aux () >> from >> /home/rberlich/geneva-build/src/geneva/libgemfony-geneva.so.0.8.5rc0 >> (gdb) up >> #14 0x0000000000000000 in ?? () >> (gdb) up >> Initial frame selected; you cannot go up. >> /********************************************************/ >> >> Gem::Geneva::GPersonalityTraits is a purely virtual class, marked as such >> with the following code: >> "BOOST_SERIALIZATION_ASSUME_ABSTRACT(Gem::Geneva::GPersonalityTraits)" . >> GObject is the base class of all optimization-related classes. >> >> The exact same code compiles and runs fine with Boost 1.43, the last >> version I have been using excessively. I cannot really comment on Boost >> 1.44 , but would be happy to try if it helps. >> >> Note that the above problem does not seem to have any influence on the >> results of the program. The problems only appear at the very end of the >> execution, when various singletons get destroyed. >> >> Best Regards, >> Ruediger -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 5

Boost::shared_ptr and CPP_UNIT
by Barry79 13 Nov '10

13 Nov '10

Hi there, In my unit test I do something like this - void setup() { m_a = ptr_t(new A()); m_b = ptr_t(new B(m_a)); m_c = ptr_t(new C()); m_b->Register(m_c); } void tearDown() { } I was wondering if I should be implementing anything in tearDown (like calling reset on these shared pointers) where I would normally call delete, and if so, why? Thanks, Barry -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-shared-ptr-and-CPP-UNIT-tp3040738p… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

bug in date time library? local_microsec_clock::local_time() gives compilation error
by dobrov 12 Nov '10

12 Nov '10

hello Just simple call: boost::local_time::local_microsec_clock::local_time(). gives compilation error in boost header: /usr/include/boost/date_time/microsec_time_clock.hpp:116: error: no matching function for call to 'boost::local_time::local_date_time_base<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::local_date_time_base(boost::gregorian::date&, boost::posix_time::time_duration&)' I use boost 1.42 and gcc 4.4.5 I have information, that the same problem occurs with boost 1.44 and Sisual Studio. Is it a bug in library? best regards ---------------------------------------------------------------------- Najlepsza wyszukiwarka tanich lotĂłw! SprawdĹź >>> http://linkint.pl/f284a

1 0

Converting between two different enumerations
by John Dlugosz 12 Nov '10

12 Nov '10

I'm looking at a lot of boilerplate code where two different enumerations are used for the same semantic meaning, and a pair of functions (a bit switch statement) converts one to the other. In this case, all the values are #define constants, not typed enumerations. But there are lots of such pairs. I'm wondering if there is a simple "bi-map" class that can take a list of pairs and produce the effect of both functions. If one of the lists of values is consecutive it should be especially easy to initialize. - TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

2 1

[BGL] property_map for or with bundled properties
by Cedric Laczny 12 Nov '10

12 Nov '10

Hi, I was trying to use an iterator_property_map with bundled properties and ran into difficulties. For those having thought about that, I want to post my solution and also address a question. Let's start with the solution: Imagine, one uses bundled properties and has defined the following EdgeProperty: struct EdgeProperty{ int edge_index; } and typedef adjacency_list<...> Graph; Whether this makes sense or not may also be discussed but is not important for the demonstration purposes. So if you now want to define an iterator_property_map that is based on the edge_index, it get's IMHO a bit more complicated than using internal properties: typedef property_map<Graph, int EdgeProperty::*>::type EdgeIndexMap; EdgeIndexMap e_index = get(&EdgeProperty::edge_index,g); std::vector< int > flag_vec(num_edges(g), 0); // Create the external property map iterator_property_map< std::vector< int >::iterator, EdgeIndexMap > flags(flag_vec.begin(), e_index); versus an example using vertex_index that is automatically created when using vecS for the vertices: typedef property_map<Graph, vertex_index_t>::type VertexIndexMap; VertexIndexMap v_index = get(vertex_index, g); std::vector< int > flag_vec(num_vertices(g), 0); // Create the external property map iterator_property_map< std::vector< int >::iterator, VertexIndexMap > flags(flag_vec.begin(), v_index); So far for the solution. I have also a question in this place: What does the "EdgeProperty::*" exactly do? The EdgeProperty is of course the bundle, but what about the "::*" is this some sort of RegEx for "all attributes of this bundle"? I looked at the code in properties.hpp and was able to generally understand the idea, but it did not become clear to me why the "::*" is needed. Thank you. Best, Cedric

2 1

boost asio UDP issue...
by The Novice Coder 12 Nov '10

12 Nov '10

1 0

Simulating Multi domain networks in BGL
by giridhar 12 Nov '10

12 Nov '10

Hello All, I need to implement(simulate) Multi domain networks in BGL. I am thinking that each domain will be represented by each single graph. Say if there are 3 domains, then there would be 3 different graphs. And after this, I need to connect few edges of these inter-graphs. Is this good Idea to implement different domains as different graphs or is there any other better method in BGL to do this? -- Regards, Giridhar

1 0

boost::bind memory leak
by bit bit 11 Nov '10

11 Nov '10

I am using a shared_ptr to execute code on method exit as instructed in http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/sp_techniques.html#on_b… shared_ptr<void> shutdown(static_cast<void*>(0), bind(&Thread::AnnounceShutdown, this, ref(state_lock))); The above line of code causes a memory leak when an exception is thrown inside AnnounceShutdown(). I know I am not supposed to throw inside a destructor, but in this particular case I see no reason for a memory leak. AnnounceShutDown() does not allocate memory. I suspect ref() has something to do with that. debugger report: WARNING: Visual Leak Detector detected memory leaks! ---------- Block 14928 at 0x00000000006E6FF0: 56 bytes ---------- Call Stack: d:\program files\boost\boost_1_44_0\boost\smart_ptr\detail\shared_count.hpp (124): boost::detail::shared_count::shared_count<void * __ptr64,boost::_bi::bind_t<void,boost::_mfi::mf1<void,bIt::Thread,boost::upgrade_lock<boost::shared_mutex> & __ptr64>,boost::_bi::list2<boost::_bi::value<bIt::Thread * __ptr64>,boost::reference_wrapper<boos d:\program files\boost\boost_1_44_0\boost\smart_ptr\shared_ptr.hpp (199): boost::shared_ptr<void>::shared_ptr<void><void,boost::_bi::bind_t<void,boost::_mfi::mf1<void,bIt::Thread,boost::upgrade_lock<boost::shared_mutex> & __ptr64>,boost::_bi::list2<boost::_bi::value<bIt::Thread * __ptr64>,boost::reference_wrapper<boost::upgrade d:\ptyxiaki\owner\owner\thread\thread.cpp (690): bIt::Thread::Main ... .. . I have already resolved this issue using BOOST_SCOPE_EXIT instead of shared_ptr, but I am looking forward for a better solution with shared_ptr.

1 0