November 2008 - Boost-users

[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

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

[signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by Stjepan Rajko 22 Feb '09

22 Feb '09

Hello all, The review for the Signals2 library (formerly known as thread_safe_signals) submitted by Frank Mori Hess begins today (Nov 1st) and is scheduled to end on Nov 10th. I would like to thank Franz Alt, Terry Golubiewski, Doug Gregor, Ravikiran Rajagopal and Andrew Webber for making this review possible by committing to reviewing the library. How to submit a review: -------- As usual, EVERYONE is welcome to participate in the review discussions and to submit a review. I strongly encourage participation from reviewers that would examine the library from a purely user standpoint (commenting on the interface and / or the documentation), as well as reviewers that would be willing to look into the details of the implementation (i.e., you don't have to focus on both). Here are some questions you might want to answer in your review (feel free to skip those that don't apply to your analysis): * 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? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please submit your review either to the list or privately to me by the end of the review period. If you send me a review privately I will forward it to the list so the review can be discussed. If you would prefer me to forward your review anonymously (with your name removed) please indicate that in your e-mail. If you are a first time reviewer, here is some more information to get you started: * http://www.boost.org/community/reviews.html has more information on the review process * the review officially takes place on both the boost dev and boost-user lists, but typically more of the discussion happens on the boost dev list * if you want to get a feel for past reviews, you can find them in the archives (see http://www.boost.org/community/groups.html) - the past review dates are on the review schedule (http://www.boost.org/community/review_schedule.html) Typically, there is a period of discussion between the reviewers and the author, with official reviews coming in towards the tail end of the review period. About the library: -------- * The library can be downloaded from: http://www.boostpro.com/vault/index.php?&directory=thread_safe_signals (latest version is signals2-2008-10-08.zip) * Documentation is also available online: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/index.html * A synopsis: The Boost.Signals2 library (formerly known as thread_safe_signals) is an implementation of a managed signals and slots system. Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted." Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) can track connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved. When signals are connected to multiple slots, there is a question regarding the relationship between the return values of the slots and the return value of the signals. Boost.Signals2 allows the user to specify the manner in which multiple return values are combined. * Relationship to Boost.Signals: This is a thread-safe variant of the original Boost.Signals library. There have been some changes to the interface to support thread-safety, mostly with respect to automatic connection management. The following thread offers some more details on the differences between the two implementations, as well as a plan of a phased replacement of Boost.Signals should Signals2 be accepted: http://tinyurl.com/4sqau3 [nabble] The Signals2 FAQ also covers some differences: http://tinyurl.com/576gl6 Kind regards, Stjepan (review manager)

8 21

[date_time] posix_time::time_duration::operator<< fails for hours>23
by Soren Dreijer 04 Feb '09

04 Feb '09

I'm creating a posix_time::time_duration object based on the minutes() helper function. If I specify a large value, such as 2000, I get a time_duration of 33:20:00. Take a look at the following piece of code, though: time_duration td = minutes(2000); cout << to_simple_string(td); // OK cout << td; // Fails with an assertion in VS2008 The latter call fails with the following assertion in strftime.c on line 658: _VALIDATE_RETURN( ( ( timeptr->tm_hour >=0 ) && ( timeptr->tm_hour <= 23 ) ), EINVAL, FALSE) Apparently, operator<< expands to _expandtime(), which doesn't allow values for the hour to be greater than 23. Is this intended behavior, or should I just always use to_simple_string() rather than the convenient operator<< ?

2 1