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

Boost Serialization: undefined reference to `__assert'
by Kesseli Pascal 31 Jul '09

31 Jul '09

Hello everyone Today, I just happened to download the latest version of cygwin, including gcc 3.4.4. While a simple hello world works perfectly fine, trying to compile this code using a statically linked libserialization.a results in dozens of linker errors, all stating "undefined reference to `__assert'". #include <boost/assign/list_of.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/lambda/lambda.hpp> #include <boost/serialization/vector.hpp> #include <iostream> #include <fstream> using namespace boost::lambda; using namespace boost::assign; using namespace boost::archive; using namespace boost::serialization; using namespace std; int main() { { vector<string> v = list_of("123")("Boost")("Serialization"); ofstream ofs("test.xml"); xml_oarchive oxml(ofs); oxml << make_nvp("VectorTest", v); } { vector<string> v; ifstream ifs("test.xml"); xml_iarchive ixml(ifs); ixml >> make_nvp("VectorTest", v); for_each(v.begin(), v.end(), cout << _1 << "\n"); } return 0; } Is this a problem or known issue when using cygwin? I'm using eclipse in addition, by the way. The code works perfectly fine on other platforms, so I imagine it must be a problem when using the serialization library with cygwin. Thanks in advance for any help you can offer me here and best regards Pascal Kesseli

4 3

[Math Toolkit] Gamma Distribution
by Christian Henning 21 Jul '09

21 Jul '09

Hi there, the documention of the gamma distribution talks about two different forms. How can can generate the second one with shape=1 and scale=1? I know how to get the first form: boost::math::gamma_distribution<> dist( 1, 1 ); I don't see how to get the second one? Thanks, Christian

5 13

[Boost.Test] valgrind complains about invalid reads
by Peter Klotz 20 Jun '09

20 Jun '09

Boost 1.37.0, Linux, x86_64, gcc 4.1: Valgrind 3.3.1 complains when running this simple test: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE( test1 ) { BOOST_CHECK( 1 == 1 ); } The valgrind messages: ==1836== Memcheck, a memory error detector. ==1836== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==1836== Using LibVEX rev 1854, a library for dynamic binary translation. ==1836== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==1836== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==1836== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==1836== For more details, rerun with: -v ==1836== Running 1 test case... *** No errors detected ==1836== Invalid read of size 8 ==1836== at 0x41E41C: __tcf_1 (in RegressionTest) ==1836== by 0x3830632FA4: exit (in /lib64/libc-2.5.so) ==1836== by 0x383061D8BA: (below main) (in /lib64/libc-2.5.so) ==1836== Address 0x4c1ade0 is 40 bytes inside a block of size 48 free'd ==1836== at 0x4A0555C: operator delete(void*) (vg_replace_malloc.c:342) ==1836== by 0x42024C: std::_Rb_tree<unsigned long, std::pair<unsigned long const, boost::unit_test::test_unit*>, std::_Select1st<std::pair<unsigned long const, boost::unit_test::test_unit*> >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, boost::unit_test::test_unit*> > >::erase(unsigned long const&) (in RegressionTest) ==1836== by 0x417C11: boost::unit_test::test_unit::~test_unit() (in RegressionTest) ==1836== by 0x41E41B: __tcf_1 (in RegressionTest) ==1836== by 0x3830632FA4: exit (in /lib64/libc-2.5.so) ==1836== by 0x383061D8BA: (below main) (in /lib64/libc-2.5.so) ==1836== ==1836== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1) ==1836== malloc/free: in use at exit: 0 bytes in 0 blocks. ==1836== malloc/free: 89 allocs, 89 frees, 38,935 bytes allocated. ==1836== For counts of detected errors, rerun with: -v ==1836== All heap blocks were freed -- no leaks are possible. I was not able to figure out what valgrind is really complaining about. The internal map of test units holds two entries. One corresponds to my BOOST_AUTO_TEST_CASE call (id=1), the other one seems to be used internally (id=65536). Both are properly erased in deregister_test_unit() which is called by ~test_unit(). Maybe someone with a little bit more insight into Boost.Test is willing to look at this. Regards, Peter.

5 11

Design for boost::serialization of STL iterators.
by Carlo Wood 23 May '09

23 May '09

On Sat, Mar 11, 2006 at 11:45:36PM +0200, Peter Dimov wrote: > Carlo Wood wrote: > > > 1) WHY does boost::serialization not support serialization > > of iterators? > > It's very hard, if not impossible, in general. It is either impossible or possible. When it is possible, it can't be hard :p I think that at the moment of serialization, the actual container needs to be known. So, only concentrating on the syntax of the code that serializes an iterator, the following cannot work: ar & iter; However, the container will be known at that point (or at least, we might as well assume that). Therefore, I could imagine a syntax like: ar & foobar(container, iter); where 'foobar' is some template function (that will be part of boost::serialization in the future). Lets start with the last one (have to start somewhere). In order to deserialize the iterator (and taken into account that we already have the container) -- which makes me think that it might be better to pass a functor to operator& above. In other words, (at least for writing), use: template<class Container> struct Foobar { Foobar(Container const&, typename Container::const_iterator& iter) : M_container(container), M_iter(iter); private: Container const& M_container; Container::const_iterator& M_iter; }; and then assign to M_iter, whatever we find in M_container. > If you have access to the container to which the iterator i refers: > > a) if the container is a map, you can serialize i->first, then on > deserialization look up the key in the map using .find(); > > b) if the container is a sequence, and it has the same contents on > deserialization as it does on serialization, you can serialize the index of > the element - distance( c.begin(), i ). I don't think that it is a requirement that the whole container has to be read: either it's a map or set, in which case later insertions will not invalidate the container, or it is a vector, in which case we use an index, from which we can construct the end iterators before the whole container is reconstructed. Therefore, the following syntax can work imho: ar & FooBar(container, iter); Would you agree? There are a zillion questions and implementation details open - but I'd like to get anyones feedback about this type of interface for iterators before continuing. Current questions: What is a good name for Foobar? Am I right when I think that Foobar needs to be declared in boost::serialization? Now the hard part (for me) is that part that involves the internals of the boost library. At the moment one tries to serialize an iterator, it is possible (though not necessarily) that the object that the iterator points to is already serialized. In the case that we are dealing with an associative container (map or set etc), we don't want to store the contents of the object (or key part, in the case of a map) again: I'd like to just store that once, and store a reference in the archive at the other place. How can I make the library store an object only the first time and the store a reference the second time? This would be for an object of arbitrary type thus. I think that it is only feasible to do this when it's actually the same object (same memory address), which is the case; but while storing the object element of the container, the address of it isn't stored as well, is it? Is there a way to make: std::set<SomeData> s; [...] ar << s; Store the address of s (&s) along with the contents of s? And would that then automatically cause the library to not store that same object again when I do: std::set<SomeData>::iterator iter = s.find(...); [...] ar << *iter; Because then, &*iter would again be the same memory address as what was stored before. -- Carlo Wood <carlo(a)alinoe.com>

3 2

[BGL] citing the Boost Graph Library
by Alejandro Marcos Aragón 06 May '09

06 May '09

Can anyone point me how to cite the Boost Graph Library in a paper? Is there any information in the boost website? Thank you all, Alejandro Aragón

4 3

compile-time check that a member function exists
by John Pretz 25 Mar '09

25 Mar '09

Hi, I'm pretty new to boost. I want to write some code with a compile-time check whether a member function exists or not. The code below shows kinda what I need except I'd obviously like to avoid a specialized template for each class that I use. Can anybody point me in the right direction? Thanks, John **************************************** #include <iostream> using namespace std; struct WithMemberGo { void Go() const {cout<<__PRETTY_FUNCTION__<<" going...."<<endl;} }; struct WithoutGo { }; template <class T> void CallGoIfItExists(const T& t){ t.Go(); } // I want to avoid having to specialize this function for every class without the // right member function. template <> void CallGoIfItExists<WithoutGo>(const WithoutGo&){ cout<<"not going anywhere...."<<endl; } int main(){ WithMemberGo with; CallGoIfItExists(with); WithoutGo without; CallGoIfItExists(without); } -- John Pretz -- P-23, MS H803 Los Alamos National Lab Los Alamos, NM 87545 Phone: (505)665-5847 Fax: (505)665-4121

5 10

Boost.Graph set of edges
by James Sutherland 17 Mar '09

17 Mar '09

Can you do something like typedef boost::graph_traits<Graph>::edge_descriptor Edge; Edge e; .... std::set<Edge> edges; edgeSet.insert( e ); I am getting compiler errors that imply that the edge_descriptor does not implement the < operator. Thanks, James

5 12

C++03 unique_ptr emulation
by Howard Hinnant 11 Mar '09

11 Mar '09

I've put up a new version of an C++03 emulated unique_ptr here: http://home.roadrunner.com/~hinnant/unique_ptr03.html This is a "boost-ized" emulation (uses boost tools and is in boost namespace), though I have reason to believe it may not work well on VC+ +05 unless the /Za option is used (I've tested only on gcc 4.0). I'm aware of Ion's interprocess version (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_sma… ), and thank Ion for his support over the years. This new version is not meant to replace Ion's version. It is simply my current best shot at emulating the unique_ptr behavior as specified in the C++0X CD1 draft. Booster's are welcome to take parts of this implementation and use them in places like interprocess/unique_ptr. Or to just use this unique_ptr directly. It consists of only one header: unique_ptr.hpp, and requires only boost headers, not boost cpp files. Basic documentation is included at the link. -Howard

5 8

serial programs
by Steven Woody 02 Mar '09

02 Mar '09

Hi, I want to write a portable program which need to read/write serial ports. How can boost help this? Thank you. ( I got know basic serial programming in Linux but I have no idea how that it done in Windows ) -- woody then sun rose thinly from the sea and the old man could see the other boats, low on the water and well in toward the shore, spread out across the current.

7 9

Re: [Boost-users] metafunction invocation performance
by Hicham Mouline 26 Feb '09

26 Feb '09

The solution to this one is provided by Joaquin, in his reply below: I tried compiling your code with MSVC++ 8.0 and it is indeed incredibly slow. After playing a little with the code I realized that MPL views are the culprit here: for some reason it is much faster to fold on a vector-based computation rather than a view: template<typename Sequence1,typename Sequence2> struct sequence_product : boost::mpl::fold< Sequence1, boost::mpl::vector0<>, boost::mpl::copy< boost::mpl::transform< Sequence2, pair_with<boost::mpl::_2> >, boost::mpl::back_inserter<boost::mpl::_1> > > {}; This transformation on sequence_product and seq_seqpair_product alone improved the performance tremendously. Additionally I've tried a small optimization: in seq_seqpair_product it is preumable better to fold on Sequence rather than SequencePair, since on average the first is expected to be shorter. Truth be said, I haven't detected any improvement with this, anyway. > Shouldn't there be a dot-product or cross-product of mpl sequences as > a general algorithm? and not just 2 sequences but N. I guess it is the O(n^2) behavior that deterred the author from including the algorithm (much as STL usually does not contain quadratic algorithms). It might be a worthy addition, nonetheless Joaquin --------- Interesting why a joint_view slower than the alternative. This result confirmed then on MSVC8 , gcc4.1, Intel10... regards, /Hicham

2 1