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

Re: [boost] Coverity Static Code Analysis
by Michael Fawcett 03 Feb '09

03 Feb '09

On Tue, Feb 3, 2009 at 3:10 PM, Marshall Clow <marshall(a)idio.com> wrote: > > fixed, but I think that someone with a bit of legal training needs to look > at the license that Coverity wants people to agree to before using the scan > results. [ It looks pretty harmless to me, but IANAL ] > > <http://scan.coverity.com/policy.html#license> I agree. Doesn't Boost have access to just that sort of support? --Michael Fawcett

1 0

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

[parallel_sort] Proposal
by Edouard A. 03 Feb '09

03 Feb '09

Howdy, I just finished the first working version of parallel_sort. It seems there is a lot of interest for this function in the C++ community, and in the boost community specifically, which is the motivation for this post. ;) My implementation is somewhat very different in nature from the one present in Intel's TBB. It's designed to take advantages of a multi-core user machine, it's not designed to run on a grid for massive sorting operation. It only uses the STL and the boost library. It doesn't have any fancy prerequisites, except having several cores to unleash its power! Current benchmarks on my Q6600 vs2008-64-bit default allocator: 2 threads : 160 % faster 4 threads : 260 % faster Keep in mind the Q6600 is not a real equivalent to a quad-cpu machine and that the default memory allocator is not multithreading friendly. It can be heavily customized. I already offer the possibility to choose between quick sorting and merge sorting, and for quick sorting I offer two pivot algorithms : fast or secure. Then you can of course specify a predicate and a fallback sorting algorithm for when you run out of threads. If you don't care to customize, no problem! Just write: parallel_sort<2>(v.begin(), v.end()); // sort with 2 threads There is still some work to be done, especially in the documentation area. Nevertheless, I think it's time to open up the code and start getting feedback. J As an added bonus I also offer to add my implementation of the smoothsort algorithm (with some hints from Steven). This algorithm is faster on sorted input but slower on random input. Cheers -- EA

6 20

SCons script for building Boost
by Sergey Popov 03 Feb '09

03 Feb '09

I've searched the ML archive and found out that scons wasn't considered for adoption because nobody offered to reimplement boost build instructions in terms of SCons. I'd like to work on this. Is there a chance I'll be given commit access so I could make a boost-SCons branch? ;) I've attached my early WIP build script to this posting.

4 4

Re: [boost] Review process question
by Christophe Henry 03 Feb '09

03 Feb '09

"John Maddock" schrieb im Newsbeitrag news:<343DA106BE604F22B7EF1BFF0A8515B8@acerlaptop>... > >> It is enough to specify which revision that is to be reviewed. > > > > Is it possible to change it after the submission request? It would allow > > me > > to make some bugfixes (if necessary) while being in the queue. > > I think bugfixes at that stage are fine: as long as there is a stable > version available somewhere, and as long as all the reviewers are refering > to the same version during the review - in other words try and keep things > stable during the review itself. > > HTH, John. > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > I think I got it now. Thanks! Christophe

1 0

[typeof] BOOST_AUTO and move semantic emulation
by vicente.botet 03 Feb '09

03 Feb '09

Hi, given T&& f(); which is the type of v in auto v = f(); Is there any plan to adapt Boost.Typeof with move semantics, so the following works? BOOST_TYPEOF_REGISTER_TEMPLATE(boost::detail::thread_move_t, 1) BOOST_TYPEOF_REGISTER(T) boost::detail::thread_move_t<T> f(); BOOST_AUTO(v, f()); Thanks, Vicente

1 0

[1.38][flyweight] permission to merge to release
by JOAQUIN M. LOPEZ MUÑOZ 02 Feb '09

02 Feb '09

Hi, I've just commited the following trivial fix to the trunk: https://svn.boost.org/trac/boost/changeset/50974 which only adds a missing std:: to a call to strcpy. The fix hasn't still cycled trough the trunk regression testers, but I've tested it locally with MSVC++ 8.0 and GCC 3.4.4 and everything's fine. Can I merge to release now? Do I wait for a trunk test cycle? No permission at all? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[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

What happens when a Boost library is unmaintained?
by Peter Simons 02 Feb '09

02 Feb '09

Hi, suppose that an accepted and officially distributed Boost library has become unmaintained, meaning that a) the code is not developed any further, b) reported bugs are not fixed, confirmed, or otherwise responded to, and c) questions on the mailing list aren't answered, then what is the procedure to deal with that situation? Take care, Peter

4 3

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

Re: [boost] Review process question
by Christophe Henry 02 Feb '09

02 Feb '09

> It is enough to specify which revision that is to be reviewed. Is it possible to change it after the submission request? It would allow me to make some bugfixes (if necessary) while being in the queue.

2 1

Review process question
by Christophe Henry 02 Feb '09

02 Feb '09

Hi, I just read the submission process page and being a bit new to this, I have some questions. The page states that all the files making up a library should be compressed into a zip file and posted in the Vault upon submission. - Wouldn't it be better to use the Sandbox for this? After all, this seems to be quite the goal of SVN. It would also allow bugfixes who might appear between submission and review. This leads us to the next question. - Does it mean that while the library is in the review queue, it cannot be changed? I understand this is a long process and it would be nice to correct problems which might appear during this time. It would be also sad to stop development too early. Sorry if I ask stuff which is already broadly known. Christophe

3 2

Re: [boost] [LibrariesUnderConstruction] Thanks!
by Christophe Henry 01 Feb '09

01 Feb '09

Hi Vicente, Then you are the winner of a bottle of wine. And no I will definitely not forget :) Thank you again, it was very nice from you to even look into the Msm documentation to add a description! BTW, this wiki page is very useful, great idea! Christophe

1 0

Forwarded Message: tokenizer feature request
by Kasra 01 Feb '09

01 Feb '09

Hi, what sort of hash function are you requesting? -- Kasra

1 0

test--please ignore
by Sean Farrow 01 Feb '09

01 Feb '09

1 0

tokenizer feature request
by Sean Farrow 01 Feb '09

01 Feb '09

Hi: I would like to request a hash function for tokenizer be implemented. I'm not sure how doable this is, but need to use this for a project I'm involved in. Cheers Sean.

1 0

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