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

[interprocess] Severe bug in sp_counted_impl.hpp!
by Lars Hagström 04 Feb '09

04 Feb '09

Hi, I believe that there is a bug in sp_counted_impl_pd::destroy(). Currently the method looks like this: void destroy() // nothrow { //Self destruction, so get a copy of the allocator //(in the future we could move it) this_allocator a_copy(*this); BOOST_ASSERT(a_copy == *this); this_pointer this_ptr (this); //Do it now! scoped_ptr<this_type, scoped_ptr_dealloc_functor<this_allocator> > (this_ptr, a_copy); typedef typename this_allocator::value_type value_type; detail::get_pointer(this_ptr)->~value_type(); } What I think is wrong is on the deallocator functor line. I believe that it should read scoped_ptr<this_type, scoped_ptr_dealloc_functor<this_allocator> > DEALLOCATOR(this_ptr, a_copy); The missing thing is the name for the scoped_ptr instance (the one I called DEALLOCATOR, to make it stand out). And since the name is missing it will become an anonymous instance, which will be destroyed *before* the destructor is called on this_ptr. The upshot is that with the bug we deallocate the memory and then call the destructor, rather than the opposite. If you're unlucky some other thread/process has allocated that memory for some other use, and you will then be running the destructor on that instead... I'm writing a ticket on this as well, just so it doesn't get overlooked. (If I'm wrong about all this my face will be red for a while...) Cheers Lars

4 6

Interest in a library for building simulations of dynamical systems?
by Jay Graham 03 Feb '09

03 Feb '09

Is there interest in a library for building simulations of dynamical systems represented by time-based differential equations? The proposed library would implement ideas found in the C++ Model Developer (CMD) library developed by Ray Sells, but in a more generic way. For example, the proposed library would support the use of user defined data types when defining states and their derivatives. Other CMD features to be included in the proposed library are: 1. The ability to mix both continuous and discrete events. 2. Support for a simulation structure that makes it easy to go from a mathematical description of a system to code. 3. Support for time-varying system topologies (e.g., multi-stage missiles). 4. User extendable set of numerical integration algorithms. For more information on CMD see: http://www.dtic.mil/srch/doc?collection=t2&id=ADA433836 and http://rocket.itsc.uah.edu/u/education/files/R/IPT_Producer/AIAA/Sells/Sell… Code snippet: // Define states and their derivatives struct x_pos : state< double, // state type double // derivative type > {}; struct y_pos : state< double, double > {}; // Define a simulation object struct Ball: obj< rk4, // fourth-order Runge-Kutta numerical integration algorithm mpl::vector< x_pos, y_pos > // State vector > { Ball(double x, double y, double vx, double vy) { // Initial state s_<x_pos>().value = x; s_<y_pos>().value = y; this->vx = vx; this->vy = vy; // Integrators add_integrator<x_pos>(this->vx); add_integrator<y_pos>(this->vy); } template< typename S, typename C > inline void update(S &sim, C &clock) { // Update the derivatives vx = 0.8*vx; vy = 0.8*vy; // Use a discrete event to stop the simulation // after 10 seconds if (clock.event(10.0)) { sim.halt(); } } template< typename C > void report(C &clock) { // Report current state at 1 second intervals if (clock.sample(1.0)) { std::cout << "Ball" << clock.t << " " << s_<x_pos>().value << " " << s_<y_pos>().value << "\n"; } } double vx; double vy; }; // Define the integration time-step struct dts { typedef double time_type; static time_type value() { return 0.01; } }; // Define a simulation stage struct stage_1 : stage< dts, mpl::vector<Ball> > {}; main() { // Create a simulation object Ball ball(0.0, 0.0, 10.0, 5.0); // Create the simulation execution object sim< mpl::vector< stage_1 > > sim(); // Initialize the simulation stage sim.stage_<stage_1>().obj_<Ball>() = &ball; // Run the simulation run(sim); }

7 7

[LibrariesUnderConstruction] Thanks!
by Christophe Henry 02 Feb '09

02 Feb '09

Hi, I realized this morning that I didn't add Msm to the LibrariesUnderConstruction Wiki page. And what do I see? Already done! And with description and link to the Vault! I have no idea who did it, but I want to thank him! And offer him a bottle of Bordeaux wine (if I manage to pass it through the customs ;-) ) at the next occasion (Aspen?). Thanks a lot, Christophe

3 4

[accumulators] why not operator+=?
by Neal Becker 02 Feb '09

02 Feb '09

A nit perhaps, but why not overload += to process samples?

6 8

Boost::Graph --- why does this program not compile?
by Oliver Kullmann 02 Feb '09

02 Feb '09

Hello, in parallel to trying to get 1_34_1 compiling again, I'll also try to understand why the code won't compile with 1_37_0. Now I found the following program which actually compiles neither with 1_34_1 nor with 1_37_0, but it should: ------------------- #include <utility> #include <vector> #include <boost/graph/adjacency_list.hpp> template <class Graph> inline Graph orthogonality_relation() { typedef std::pair<unsigned int, unsigned int> edge_type; std::vector<edge_type> ev; Graph g(ev.begin(), ev.end(), 0, 0); return g; } typedef boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS> UndirectedGraph; int main () { orthogonality_relation<UndirectedGraph>(); } ------------------- The abbreviated error-message from gcc (version 4.1.2) is: Error.cpp:17: instantiated from here Boost/1_37_0+4.1.2/include/boost-1_37_0/boost/graph/detail/adjacency_list.hpp:2113: error: invalid type argument of ‘unary *’ where line 17 is the last line of the main-function. Oliver

3 7

Interest check: memoization
by James Porter 01 Feb '09

01 Feb '09

After hacking around with some simple dynamic programming, it occurred to me that it should be possible to write a simple class template to handle memoization of functions. With the changes in C++0x that help solve the forwarding problem, writing a generic memoizer should be fairly straightforward. (Or so I thought!) The interface is straightforward, so I'll let the following code snippet speak for itself: memoizer<int (int,int)> memo(my_func); int ret = memo(i,j); As you'd expect, this creates a memoizer that caches results of calls to my_func. Pretty simple, right? Well, not exactly. :) (If you'd rather not read about the implementation, you can skip ahead to the end, where there is a link to download the source.) There are a number of issues that make this a fairly complicated problem, even with the improved generic programming facilities in C++0x. Chief among these is copying. With the naive implementation of the memoizer, I found that calculating the result of an unmemoized value created 3 copies (one for creating a tuple to search a map for, and two to insert the tuple into the map), and returning a memoized value created 1 copy (to create a tuple to search the map). To make a long story short, I set about trying to reduce the number of copies to the expected amount: 1 copy for unmemoized values and 0 for memoized values. I'm happy to say that this was a success! The trick was creating a tuple that holds references to each argument and can be upgraded to hold the arguments by value. In this way, we can compare by reference and store by value. This is simple on the surface, but requires some care when dealing with rvalue references. There are also issues with passing convertible types to the memoizer (e.g. passing floats when the function expects ints). For complicated types, you certainly wouldn't want to copy them more than once, and you'd want to use move constructors where possible. This is resolved with some creative manipulation of template types (lines 52-58 of memoizer.hpp). There are still a number of things missing in this code, such as the ability to use function objects with the memoizer, or the ability to specify the map type, but I believe that the most important issues are resolved: * Minimizes copying of arguments * Supports move constructors wherever possible * Safely converts arguments to the appropriate types The full source code for this is available here (requires gcc 4.3 or a compiler that supports variadic templates and rvalue refs): http://www.teamboxel.com/misc/memoizer.tar.gz Comments and criticisms are welcome. If there's interest, I will - of course - work on a version that supports the current C++ standard. - Jim

5 21

Numeric constants
by John Maddock 01 Feb '09

01 Feb '09

Folks, someone's just filed a feature request asking for more numeric constants to be added to Boost.Math (these are currently an implementation detail, albeit a semi-documented one: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_to…) but we know what troubles we had agreeing on anything last time this came up for review! Even so it appears to be time to fearlessly open up this particular can of worms again ;-) So, it appears that there is still interest, but as you know last time we tried this there was no agreement on interface, some folks felt a template interface was essential: template <class T> T pi(); leading to: template <class T> T circumference(T r) { return 2 * boost::math::constants::pi<T>() * r; } While others were absolutely adament that they wouldn't use a syntax other than: template <class T> T circumference(T r) { return 2 * pi * r; } Various attempts were made to solve this conundrum via expression templates and/or overloaded operators, but all introduced their own new issues as well, and IMO none were wholly satisfactory (not least due to the complexity introduced, a complexity that becomes all too apparent to the user if they do get a compiler error due to an unsupported use case). So.... here's what I think Paul Bristow and I might be persuaded to submit: * A library based on the existing Boost.Math code, with pi<T>() as the main interface / use case. * Possibly add constants of specific precision in alternative namespaces, so we could have: double circumference(double r) { using namspace boost::math::double_constants; return 2 * pi * r; } And that's pretty much it: no overly complex stuff, just a really simple library with a few constants in it, that makes it really easy to add new constants when required. Thoughts? Regards, John.

11 27

[1.38.0] [Integer] Library in inconsistent state
by Beman Dawes 31 Jan '09

31 Jan '09

The Integer library is in an inconsistent state. Release regression tests are failing on all platforms. Trunk tests are failing on many platforms, too. I finally got a reply to a private query to Daryle Walker, and he is not going to be able to do any work on the library for the present. Thus we need someone to put the library into a consistent and stable state for the 1.38.0 release. That means either fix whatever ails it or, if that isn't possible, revert until a working state is reached. Volunteers needed! --Beman

3 4

[Release Managers] Merging Parameter to Release
by David Abrahams 31 Jan '09

31 Jan '09

Hi, http://www.boost.org/development/tests/trunk/developer/issues_release_.html… now shows that the changes we made are clean. The failures you're seeing there are due to tests we added newly; those tests are from "literate programming" examples that were automatically extracted from the documentation, and for some reason we had never checked them in so far. How would you like this handled? I suppose one option is that we could avoid merging the new tests. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

6 6

Proposal/InterestCheck: Boost.Geom
by Anis Benyelloul 31 Jan '09

31 Jan '09

Hi people, Boost.Geom purpose is to provide a unified, zero-cost and pretty interface around existing geometric primitive implementations (for now only points and rectangles in 2D and 3D). I have uploaded the code+doc+tests in geom-0.1.zip in the vault. * The rest of this mail gives an idea about the rational behind the library * If you still have time, the manual contains a chapter `Rational' (http://geom.000hosted.com/html/c55.html) that explains the library purpose in detail (please read that before answering) * If you want to test it, the library is header-only and doesn't not depend on anything else (not even other parts of boost), you only need to add an include directory (see the manual chapters `Installation' and `Kick Start') Rational (summary) -------- For illustrative purposes, say you are working with Qt (QPoint and QRect): geom::point<QPoint> pt; // A QPoint instance behind a geom::point interface geom::box<QRect> rc; // A QRect instance behind a geom::box interface Now you can write code that uses pt and rc without having to worry about QPoint and QRect. Further more, if later you port your code to, say, WxWidgets (WxPoint and wxRect), all you have to do is to change the above two lines to: geom::point<wxPoint> pt; // Now using wxPoint internally geom::box<wxRect> rc; // Now using wxRect internally And the rest of the code remains the same (since the interface presented by geom::point<> and geom::box<> remains the same). Key points * Using QPoint directly is NOT faster than using geom::point<QPoint>. * Using geom::point<QPoint> makes the rest of your code independent of QPoint (so that you can easily switch to another library later), * geom::point/geom::box provide a richer interface than most existing points and rectangles implementations. * The library provides it's own implementation types (that you can plug into geom::point and geom::box) so you can test it even if you don't use Qt, WxWidgets.. etc I'll be happy to hear your opinion, Links: (If you are reading this mail long after the date it was written (26 Jan 2009) these links might be broken, checkout the library archive in the vault instead) - Full manual http://geom.000hosted.com/html/index.html - Rational chapter http://geom.000hosted.com/html/c55.html - Library archive (code+doc+tests) (int the vault) http://www.boostpro.com/vault/index.php?action=downloadfile&filename=geom-0… Reguards, -- Anis

9 29