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

[serialization] 1.35 problem with explicit instantiation
by Dan Thill 14 Apr '08

14 Apr '08

With 1.34, I was using the pattern described by Robert (http://lists.boost.org/boost-users/2006/01/16293.php) with non-intrusive serialization. In short, the serialization functions are merely declared in the header files. They are implemented in the .cpp file, and then explicitly instantiated for each archive type I'm using. However, with 1.35, this no longer works. The export macros create an instance of the guid initializer as follows: export.hpp:150 BOOST_PP_CAT(boost_serialization_guid_initializer_, __LINE__) However, this gives me redefinition errors in the following situaion: ClassA.h -------- (line 1:) BOOST_CLASS_EXPORT(ClassA); ClassB.h -------- (line 1: )BOOST_CLASS_EXPORT(ClassB); main.cpp #include <ClassA.h> #include <ClassB.h> (create an archive instance and attempt to serialize) ------------------------------- As you can see, two objects, both named boost_serialization_guid_initializer_1, will be created, and the compiler (MSVC80) will give me a redefinition error. I honestly have no idea what's going on. This is so obvious, it has to mean that I'm organizing my code in some weird fashion. Thanks! Dan

5 17

Re: [Boost-users] [boost] [gil] [announcement] New IO lib
by Christian Henning 14 Apr '08

14 Apr '08

This is my bad. Sorry. It's basically the same address without the 's' in https. Here it is again: http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension… Christian

1 0

[Boost.Test] reports incorrect memory leak
by mike 14 Apr '08

14 Apr '08

An extremely simple piece test, containing just one stack-created object, is causing boost.test to report a memory leak. I am using boost 1.34.1 compiled in windows using configure, bjam, & msvc90. I've copied my simple test case illustrating my problem below, and included the output it produces. As you can see, boost.test is being used, but the regex is part of microsoft's tr1. As a note, when I modify it to use boost's regex (with the commented-out changes seen in code), no such errors were reported. I'd like to say that obviously the SOLE problem lies in MS' beta tr1 implementation, but this code is so simple I don't get how that would be. Also, i believe the actual TR1 impl is from dinkumware and is supposed to be fully release ready (it is just the ms-CLI, etc, integration which leads to the beta designation)... Hopefully someone has more insight into this. Also, if someone has any tips on how to interpret the memory dump boost.test provides, I'd be interested in learning. Thanks in advance! //begin code// //file dumb_test.cpp //in a new, default solution w/ precompiled headers turned off, //all msvc files removed, and include_path += $(boost_root) //lib_path += $(boost_root)/stage/lib added #include <boost/test/unit_test.hpp> #include <regex> //#include <boost/tr1/tr1/regex> using boost::unit_test_framework::test_suite; using std::tr1::regex; //using boost::regex void dumb_test(){ regex rgx(""); //regex rgx("foo");//boost doesn't like empty rgx str } test_suite* init_unit_test_suite(int, char** const){ test_suite* suite = BOOST_TEST_SUITE("Core Tests"); suite->add(BOOST_TEST_CASE(&dumb_test)); return suite; } //end code// //begin output// Running 1 test case... *** No errors detected Detected memory leaks! //with boost::regex no mem leaks... Dumping objects -> {208} normal block at 0x00347DD8, 20 bytes long. Data: <p-J > 70 2D 4A 00 15 00 00 00 00 00 00 00 00 00 00 00 {207} normal block at 0x00347D90, 24 bytes long. Data: <|-J }4 > 7C 2D 4A 00 0E 00 00 00 00 00 00 00 D8 7D 34 00 {206} normal block at 0x00347D48, 24 bytes long. Data: < -J }4 > 88 2D 4A 00 0D 00 00 00 00 00 00 00 90 7D 34 00 {205} normal block at 0x00347CF8, 32 bytes long. Data: <p-J H}4 > 70 2D 4A 00 14 00 00 00 00 00 00 00 48 7D 34 00 Object dump complete. //end output//

4 3

bind with boost::filesystem::directory_iterator
by Brad 14 Apr '08

14 Apr '08

Hi guys and gals, I'm new to boost and this is my first attempt to use bind (big step LOL). I'm trying to do this: bfs::path p( "." ); bfs::directory_iterator dir_iter( p ); for_each( dir_iter.begin(), dir_iter.end(), boost::bind( &purgeOlder, _1 ) ) but I get: purgefiles.cpp:53: error: 'class boost::filesystem::directory_iterator' has no member named 'begin' purgefiles.cpp:53: error: 'class boost::filesystem::directory_iterator' has no member named 'end' It would appear directory_iterator does not have these members which are common on the other containers, am I missing something? Is there a way to do this using bind? Cheers, Brad

3 3

ptr_map trouble
by Pau Garcia i Quiles 14 Apr '08

14 Apr '08

Hello, I'm having trouble when adding elements to a ptr_map. If I use a ptr_vector instead, it works (code for ptr_map and ptr_vector follows). * With ptr_map: =============== #include <iostream> #include <string> #include <boost/function.hpp> #include <boost/any.hpp> #include <boost/ptr_container/ptr_map.hpp> class Base { }; class X : public Base { public: std::string text() { std::cout<< std::string("hello world!") << std::endl; return std::string("hello world!"); } }; class Y : public Base { public: int value() { return 5; } }; class Z : public Base { public: bool isEnabled() { return true; } }; // [...] // There will be hundreds of classes like X, Y and Z, only quite more complex class ProxyBase { public: virtual boost::any field() = 0; }; template<class T> class Proxy : public ProxyBase { typedef T result_type; public: Proxy(T& inst, boost::function<boost::any ( T )> f) : inst_(inst), f_(f) { ; }; boost::any field() { return boost::any( f_(inst_) ); } T& inst_; boost::function<boost::any ( T )> f_; }; int main() { boost::ptr_map<std::string, ProxyBase> m; X x; Proxy<X>* px = new Proxy<X>(x, boost::mem_fn(&X::text)); std::cout << "Calling a proxy object Proxy<X> outputs: " << boost::any_cast<std::string>( px->field() ) << std::endl; // m.insert(std::string("test"), px ); // FIXME Why does this 'insert' fail? // std::cout << "PTR_MAP Calling a proxy object Proxy<X> outputs: " << boost::any_cast<std::string>( m["test"].field() ) << std::endl; Y y; Proxy<Y>* py = new Proxy<Y>(y, boost::mem_fn(&Y::value)); std::cout << "Calling a proxy object Proxy<Y> outputs: " << boost::any_cast<int>( py->field() )<< std::endl; // m.insert(std::string("test2"), py); // FIXME Why does this 'insert' fail? // std::cout << "PTR_VECTOR Calling a proxy object Proxy<Y> outputs: " << boost::any_cast<int>( m["test2"].field() ) << std::endl; Z z; Proxy<Z>* pz = new Proxy<Z>(z, boost::mem_fn(&Z::isEnabled)); std::cout << "Calling a proxy object Proxy<Z> outputs: " << boost::any_cast<bool>( pz->field() )<< std::endl; // m.insert(std::string("test3"), pz); // FIXME Why does this 'insert' fail? // std::cout << "PTR_VECTOR Calling a proxy object Proxy<Z> outputs: " << boost::any_cast<bool>( m["test3"].field() ) << std::endl; return 0; } * With ptr_vector: ================== #include <iostream> #include <string> #include <boost/function.hpp> #include <boost/any.hpp> #include <boost/ptr_container/ptr_vector.hpp> class Base { }; class X : public Base { public: std::string text() { std::cout<< std::string("hello world!") << std::endl; return std::string("hello world!"); } }; class Y : public Base { public: int value() { return 5; } }; class Z : public Base { public: bool isEnabled() { return true; } }; // [...] // There will be hundreds of classes like X, Y and Z, only quite more complex class ProxyBase { public: virtual boost::any field( std::string name ) = 0; }; template<class T> class Proxy : public ProxyBase { typedef T result_type; public: Proxy(std::string name, T& inst, boost::function<boost::any ( T )> f) : name_(name), inst_(inst), f_(f) { ; }; boost::any field( std::string name ) { if( name == name_ ) { // Just a stub to simulate a container lookup return boost::any( f_(inst_) ); } } std::string name_; T& inst_; boost::function<boost::any ( T )> f_; }; int main() { boost::ptr_vector<ProxyBase> vec; X x; Proxy<X>* px = new Proxy<X>("test", x, boost::mem_fn(&X::text)); vec.push_back(px); std::cout << "Calling a proxy object Proxy<X> outputs: " << boost::any_cast<std::string>( px->field("test") ) << std::endl; std::cout << "PTR_VECTOR Calling a proxy object Proxy<X> outputs: " << boost::any_cast<std::string>( vec[0].field("test") ) << std::endl; Y y; Proxy<Y>* py = new Proxy<Y>("test2", y, boost::mem_fn(&Y::value)); vec.push_back(py); std::cout << "Calling a proxy object Proxy<Y> outputs: " << boost::any_cast<int>( py->field( "test2" ) )<< std::endl; std::cout << "PTR_VECTOR Calling a proxy object Proxy<Y> outputs: " << boost::any_cast<int>( vec[1].field("test2") ) << std::endl; Z z; Proxy<Z>* pz = new Proxy<Z>("test3", z, boost::mem_fn(&Z::isEnabled)); vec.push_back(pz); std::cout << "Calling a proxy object Proxy<Z> outputs: " << boost::any_cast<bool>( pz->field( "test3" ) )<< std::endl; std::cout << "PTR_VECTOR Calling a proxy object Proxy<Z> outputs: " << boost::any_cast<bool>( vec[2].field("test3") ) << std::endl; return 0; } -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

2 1

[BoostTest] 1.35.0: valgrind complains about uninitialized memory
by peter.klotz＠ith-icoserve.com 14 Apr '08

14 Apr '08

valgrind 3.3.0 complains about uninitialized memory in BoostTest 1.35.0: ==31740== Syscall param sigaltstack(ss) points to uninitialised byte(s) ==31740== at 0x413D811: sigaltstack (in /lib/tls/libc-2.3.2.so) ==31740== by 0x80863D8: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (in Application) ==31740== by 0x80864AB: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (in Application) ==31740== by 0x8084AD7: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (in Application) ==31740== by 0x8081492: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (in Application) ==31740== by 0x8076684: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (in Application) ==31740== by 0x8076658: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (in Application) ==31740== by 0x8080443: boost::unit_test::framework::run(unsigned long, bool) (in Application) ==31740== by 0x806E093: boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) (in Application) The attached patch fixes this error by initializing the structure passed to syscall sigaltstack(). Best regards, Peter.

2 1

[Graph] Bug in depth_first_search
by Fonzi Chat 14 Apr '08

14 Apr '08

Hello, I'm trying to pass a distance_map PropertyMap into a depth_first_search call. I've done so without any problems for BFS and Dijkstra's, however I just cannot get DFS to update the distance_map. This is what I have: typedef adjacency_list<listS, vecS, directedS, no_property, property<edge_weight_t, int> > Graph; std::vector<int> d(NUMVERTICES); depth_first_search(G, visitor(*(new DFSVisitor(s, t))).distance_map(&d[0])); Where I have defined a DFSVisitor class that derives from dfs_visitor appropriately. I'm really stumped on this, so any help is appreciated. _________________________________________________________________ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refres…

1 0

Egg review period extended until April 20th
by dan marsden 13 Apr '08

13 Apr '08

Hi All The Egg review has run for 2 weeks now with zero reviews, which is obviously disappointing. There has been some good and pretty thorough discussion, and a couple of promises of reviews. As such, I'm extending the review period by 1 week until 20th April 2008. Please do post a review if you have any interest in this library. In case anybody is unsure, in the case of zero votes being posted, the default result will be a rejection. Please lets make sure we don't have to fall through to this default case. Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm * Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda. * Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc... The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks Dan Marsden Review Manager ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

[Random] Differing values from minstd_rand in v1.35.0
by Greg Landrum 13 Apr '08

13 Apr '08

Dear all, After moving from boost 1.34.1 to 1.35.0 I have noticed that the sequence of values returned by the minstd_rand generator has changed. The following code snippet generates different values with 1.35.0 than it did with 1.34.x and 1.33.x: //------------------------- typedef boost::minstd_rand rng_type; typedef boost::uniform_int<> distrib_type; typedef boost::variate_generator<rng_type &,distrib_type> source_type; rng_type generator(42u); unsigned int seeds[] = {12,23,42}; distrib_type dist(0,INT_MAX); source_type randomSource(generator,dist); for(unsigned int i=0;i<3;++i){ generator.seed(seeds[i]); std::cerr << seeds[i]; for(unsigned int j=0;j<5;++j){ unsigned int bit = randomSource(); std::cerr<<" "<<bit%1024; } std::cerr<<std::endl; } //------------------------- Output with v1.35.0: 12 691 854 1010 690 696 23 444 337 394 1000 751 42 404 8 37 977 972 and with v1.34.1: 12 691 844 854 975 292 23 214 852 444 337 394 42 883 404 943 348 8 If I use the mt19937 generator instead of minstd_rand, the sequences are the same across versions. In the event it matters, I'm using g++ v4.1.3 on an Ubuntu Linux system. Is this user error, the result of a bug fix in Boost.Random, a new bug in Boost.Random, or is my expectation that the output of the RNG should not change across releases unreasonable? Thanks in advance for any help. Best Regards, -greg

1 0

boost.interprocess dynamic segment size?
by hgdhfdghsa＠Safe-mail.net 13 Apr '08

13 Apr '08

Hello, in my application I am forced to create a shared memory segment whose size can change at runtime. Is it possible to implement such a shared memory segment using the boost.interprocess library? I do not want to pre-allocate a big shared memory segment, as in most cases the segment is small (about 100bytes). Just in some very rare cases it gets very big (5MB or even more). Thank you

4 7