- Boost - lists.boost.org

[contract] static if instead of assertion requirements
by Lorenzo Caminiti 03 Oct '12

03 Oct '12

Hello all, I was reading the proposal to add "static if" to C++1x and I will use such a syntax for assertion requirements: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf Current syntax for assertion requirements: postcondition( back() == value, requires boost::has_equal<T>::value ) Will be replaced with static if: postcondition( static if(boost::has_equal<T>::value) ( back() == value ) // optional else ( ... ) ) If there were interested, I could even provide a separate BOOST_STATIC_IF(const_condition, then_code, else_code)... however, such a macro could only be used at namespace and class scope, not a function scope :( --Lorenzo

2 2

Boost.Thread does not compile from trunk
by Jeremiah Willcock 02 Oct '12

02 Oct '12

It seems like <boost/thread/future.hpp> is missing an #include of <iostream> and produces errors about missing definitions of cout, etc. because of that. It looks like that is debugging code that may not have been intended to be committed. -- Jeremiah Willcock

2 1

Re: [boost] Fwd: ODEInt review
by Karsten Ahnert 02 Oct '12

02 Oct '12

Hi Greg On 10/02/2012 09:11 PM, Karsten Ahnert wrote: > Hi Freg, Sorry for misspelling!

1 0

Fwd: ODEInt review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: ODEInt review Date: Wed, 26 Sep 2012 11:48:18 -0400 From: Reese, Greg Dr. <greg.reese(a)miamioh.edu> To: watanabesj(a)gmail.com <watanabesj(a)gmail.com> CC: Reese, Greg Dr. <greg.reese(a)miamioh.edu> Please always state in your review, whether you think the library should be accepted as a Boost library! Absolutely! - What is your evaluation of the design? Good. Good use of policies Is it necessary to set an initial step size on the adaptive integrators? Shouldn't they be able to figure this out on their own? If the size is needed, maybe it could have a default value so the user doesn't have to pass the argument. - What is your evaluation of the implementation? Appears to be good but I didn't look at code in detail. - What is your evaluation of the documentation? Excellent! Probably the best documentation of any Boost library. Suggestions: 1) Add general explanation of "observers", e.g., what they do, sample uses. 2) In documentation of example programs, add plots of outputs. These help users decide if the program ran correctly and if they're interpreting the outputs correctly - What is your evaluation of the potential usefulness of the library? Extremely useful to C++ programmers who want to incorporate ODE solutions into their code - Did you try to use the library? With what compiler? Did you have any problems? Used Microsoft Visual C++ 2012. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2-3 hours. Read through documentation, ran a number of sample programs - Are you knowledgeable about the problem domain? Yes Suggestion for future (not current!) version - add capability for user routines to stop the Integration process. This is useful for breaking out of periodic solutions, for stopping the computations if the solution attains meaningless values, and for limiting the amount of running time. See, for example, "Event Location" at http://www.mathworks.com/help/matlab/math/ordinary-differential-equations.h… Perhaps this capability can be incorporated into the observers. Greg Reese

3 3

Fwd: [Review] ODEint review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: [Review] ODEint review Date: Fri, 28 Sep 2012 22:56:56 +0200 From: André Bergner <andre.bergner.0(a)gmail.com> To: boost(a)lists.boost.org CC: watanabesj(a)gmail.com === ODEINT REVIEW === I vote for 'YES'. The library ODEint should be accepted and integrated into boost. Boost features many scientific/numeric applications already. Differential equations are fundamental enough to be added to boost's math/numeric category and enhance the scientific use cases of boost. _____________________________________________ What is your evaluation of the design? ODEint features a modern C++ (concept based as opposed to of polymorphism) which improves performance and flexibility tremendously. It demonstrates very well the power of a functional programming style - algorithms and containers are separated strictly. In particular parallelization comes almost for free by 'just' changing the container type. This is one very nice feature I like a lot. The design allows inter-portability to a great extend. Pretty much everything can be exchanged and adapted to specific needs. _____________________________________________ What is your evaluation of the implementation? I did not dive into all the internals deeply. But from what I've seen ODEint is well implemented and its internal structure make sense. Here the well designed interface helps the internals to be structured clearly as well. _____________________________________________ What is your evaluation of the documentation? The documentation is pretty good. It is covering many use-cases in detail and demonstrates the high flexibility of ODEint (CUDE/thrust, etc.) with many examples (missing a lot in some other boost libs). It becomes clear how it is used and what can be done with it. Nevertheless, for somebody not familiar with the topic of differential equations the purpose of the library is unclear from a quick glance into the overview. I would extend the overview with a short introduction (one or two paragraphs, links to wikipedia) of the topic, especially with some demonstrative example in words (e.g. physics engine in computer games or something similar). Concerning a more technical detail of the lib, I would like to have one large html file instead of many linked small ones. This would improve reading and in particular searching a lot. Btw., this is also true for many other boost libraries. I miss some notes about ODEint and C++11 (e.g. some obvious such as lambda should be mentioned, what about literals as units). Further, from a mathematical point of view also some comments about the application to partial differential equations would be useful. For somebody with experience in the field this might be obvious but for a beginner this would be helpful. _____________________________________________ What is your evaluation of the potential usefulness of the library? ODEint has many applications in a huge amount of scientific and engineering fields. It has the potential to become the de-facto standard for solving ODEs and high performance computing. Further, some less obvious use-cases might be: particle systems (quite popular in entertainment apps these days), network layout algorithm, etc... Within its field of application this library is very feature complete and can compete with many standard libs (matlab, python, ...) with ease. I think that ODEint makes the best compromise between simplicity in use and computational performance while not giving up general flexibility. It also features many things (error correction, symplectic methods, ...) not present in many competing libraries. _____________________________________________ Did you try to use the library? With what compiler? Did you have any problems? I was using the library for quite some time with several compilers (gnu, clang, intel). _____________________________________________ How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I was using the library one year age intensively. However, within this year I was not using it due to a different working field of mine. But I was following its improvements. _____________________________________________ Are you knowledgeable about the problem domain? Yes, I used the library extensively. I was successfully combining it with boost::graph to integrate network of coupled differential equations. Best regards, --- André Bergner

1 0

[1.52.0] Release branch closed except by permission, beta next week
by Marshall Clow 02 Oct '12

02 Oct '12

Hello everyone, The release branch is now closed for all changes except by permission from one of the release managers. The beta release is planned for next Monday. Please can you write your entries for the release notes soon. As always you can edit them directly using subversion at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ Or you can email them to Daniel James <dnljms(a)gmail.com>. The release notes are linked from the main page soon after the beta is released, so it would be complete by then. Thanks, -- Marshall

1 2

[iterator] Minor comment typo in iterator_facade.hpp
by Team OSS 02 Oct '12

02 Oct '12

Hi! Patch attached for fixing it. It's our first contribution to the open-source community ;) Best regards, NINJA

2 1

Boost Range Joined Range
by Ali Nakipoglu 02 Oct '12

02 Oct '12

How can i create copy a joined_range type and it contents? Any alternatives to make this? For example typedef std::vector<int> VectorT; typedef joined_range< VectorT, VectorT> JoinedRangeT; VectorT vector0, vector1; JoinedRangeT joinedRange0( vector0, vector1 ) // I need this JoinedRangeT joinedRange1 = copyAnyRangeOrContainer( joinedRange0 ); Im planning to use your advices to design copyAnyRangeOrContainer function, so that it can create deep copies from given range or containers that are can be vector,map, joined_range<T1,T2> or even joined_range<joined_range<T1,T2>, joined_range<T1, T2> > Thank you! -- Ali Nakipoglu

3 2

[BGL] graph/properties.hpp (vertex_property) [PATCH]
by Shaun Jackman 01 Oct '12

01 Oct '12

Hi, vertex_property and edge_property should inherit publicly from vertex_property_type and edge_property_type. A patch follows. ./ContigGraph.h:55:39: error: 'type' is a private member of 'boost::mpl::eval_if<boost::detail::has_vertex_property_type<DirectedGraph<ContigProperties, Distance>, mpl_::bool_<false>>, boost::detail::get_vertex_property_type<DirectedGraph<ContigProperties, Distance>>, boost::no_property>' typedef typename vertex_property<G>::type vertex_property_type; ^ /usr/local/include/boost/graph/properties.hpp:251:49: note: constrained by implicitly private inheritance here template <class Graph> class vertex_property: vertex_property_type<Graph> {}; ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Cheers, Shaun --- graph/properties.hpp.orig 2012-09-27 11:37:48.000000000 -0700 +++ graph/properties.hpp 2012-10-01 10:43:34.000000000 -0700 @@ -248,8 +248,8 @@ >::type type; }; - template <class Graph> class vertex_property: vertex_property_type<Graph> {}; - template <class Graph> class edge_property: edge_property_type<Graph> {}; + template <class Graph> class vertex_property: public vertex_property_type<Graph> {}; + template <class Graph> class edge_property: public edge_property_type<Graph> {}; template <typename Graph> class degree_property_map

2 2

[coroutine review] late review + comments
by Jeffrey Lee Hellrung, Jr. 01 Oct '12

01 Oct '12

Apologies to Hartmut, Oliver, and the community for my late presence regarding the recently reviewed Coroutine library. I finally had a good block of time this afternoon/evening to look through the documentation [1], so I figured, even if Hartmut doesn't count this as a formal review, at least Oliver can use these comments to improve the documentation. First, if I were to vote on whether Coroutine should be accepted, it would be CONDITIONAL ACCEPTANCE just based on present documentation issues. At a minimum, the documentation needs some fixing up, but I also think Oliver should address the design and interface suggestions Vicente, Eugene, and others (I myself haven't yet gone through the entire discussion yet, though I've been meaning to) have had, which mostly seem to have merit, and then present an updated. Unfortunately, I can't come up with a specific list of said suggestions, but I trust Oliver can pick through the discussion as well as I can :/ Second, I would really like to see some form of this library in Boost :) One thing that benefits the documentation of a library with a seemingly nontrivial design space (like Coroutine) is a comparison with past and present solutions. A quick google search of "c++ coroutine" found 3 libraries that ostensibly implement coroutines or an approximation thereof [2-4]. I haven't gone through these quite yet, but I'd like to see why one should use the proposed Coroutine library over these alternatives (even a 1-line justification, like "Library X lacks critical feature Y, by design" or "Library X does not work on platform Z" would be sufficient.) I think some documented research to justify the existence of this library is warranted. My specific comments on the documentation follow (I just copy/pasted from a Google document, so I hope this doesn't format badly...). I'm pretty sure some of what's below repeats what someone else has said, but, for completeness, I just included everything that initially came to mind as I was reading the documentation. - Rename namespace boost::coro to (e.g.) boost::coroutine or something similarly spelled out and not (arguably cryptically) abbreviated. - "Executing a coroutine" - s/it can migrated/it can be migrated/ - The first example uses “coro_t c( boost::bind( f, _1 ) );”; I’m confused as f is a binary function, but the boost::bind expression only works for unary functions. - “The coroutine-function, as well as its arguments, if any, are copied into the coroutine's state.” Can you elaborate on what you mean by “its arguments...are copied into the coroutine’s state”? You must mean when you call the coroutine, i.e., the copying of the coroutine-function and the copying of the coroutine-function’s arguments occur at different times, right? - The example with output uses ctx when (I believe) you mean c. Also, it implies that coroutine<>::is_complete actually executes the coroutine-function, which seems non-intuitive to me; I would expect it to be non-modifying and only indicate whether the coroutine-function has completed or not. - s/preemtive/preemptive - “Calling coroutine<>::operator()() from inside the same coroutine results in undefined behaviour.” Can you give an example of how one could possibly mistakenly do this? - s/allways/always - “The arguments passed to coroutine<>::operator()(), in one coroutine, is returned by coroutine<>::self_t::yield() in the other coroutine or, if it is the first call to coroutine<>::operator()() ( coroutine was not started), the coroutine-function will be entered and the arguments are passed to coroutine-function on entry.” I think I know what you’re trying to say here, but talking about 2 coroutines when your examples only have one coroutine object is ripe for confusion. Either clarify your terminology, clarify this explanation of the signature, or both. - The fact that self_t::yield() must package its return value into a boost::tuple (when the coroutine-function has more than one argument beyond self) suggests to me that we should strive for more uniformity between how the coroutine-function is initially entered (now with explicitly separate arguments) and subsequently continued (now with a packaged set of arguments). A couple of suggestions: - Force all coroutine-functions to be nullary or unary (sans the self argument); one can manually address more than one argument via boost::tuple packaging, and maybe boost::coro::coroutine could automatically package >1 argument up into a boost::tuple to convenience. You may also want to provide a macro (named, e.g., BOOST_TUPLE_UNPACK) that can can unpack a tuple into variables, e.g., something that looks like BOOST_TUPLE_UNPACK( ( int x ) ( int y ), tuple ); - Use a coroutine-function signature that looks something like void f(coro_t::self_t & self) { BOOST_TUPLE_UNPACK( ( int x0 ) ( int y0 ), self.arguments() ); // … BOOST_TUPLE_UNPACK( ( int x1 ) ( int y1 ), self.yield() ); } Perhaps equivalently, one can always call self.arguments() to get the most recently passed set of arguments. - “coroutine-function with multiple arguments” - Isn’t the boost::bind in this example superfluous? - “Exit a coroutine-function” - yield_break or yield_return? You mention both. - There are 2 “Important” notes on forced_unwind exceptions that appear to say the same thing. - “Stack unwinding” - I’m starting to get really confused by your uses of boost::bind; “boost::bind( fn, _1 )” when fn is a nullary function??? I guess you forgot the self_t argument? If so, again, why is boost::bind even necessary? Did you check that these examples actually compile? - The default behavior of the destructor of always unwinding the stack seems entirely reasonable, but the preconditions you list seem entirely unreasonable and unsafe! Basically, I’m reading that { coro::coroutine< void ( ) > c; } results in undefined behavior, as the preconditions for the destructor are not met. This almost has to be a documentation error. Further: “After unwinding, a coroutine is complete.” I was under the impression that unwinding only occurs in the destructor of the coroutine, at which point the coroutine object does not exist anymore, so what coroutine are you referring to, and even if you’re referring to the recently destructed coroutine, in what way is it complete? - “Executing a generator” - s/The default StackAllocator concept/The default StackAllocator/ - Be consistent on when you use StackAllocator, stack-allocator, etc. I.e., what do you mean by each? - “The first argument of generator-function...”: You mean the *only* argument? - s/The generator-function executed/The generator-function is executed/ - Same notes as at the bottom of “Executing a coroutine”. - “Exit a generator-function” - Again, yield_break or yield_return? - “boost::bind( fn, _1, _2 )” ??? Huh? How is “a” bound within fn, then??? - s/self_yield/self.yield/ - It’s unclear to me why a separate generator class is provided in addition to the coroutine class. Can you explain what the differences are? E.g., I don’t see why coroutine can’t also have an operator unspecified-bool-type () rather than is_complete. - “Performance” - 10 doesn’t seem like a very convincing sample size. If you can’t nail down the CPU cycles and time exactly via theoretical analysis of the assembly code, then I don’t see what’s preventing you from using a sample size several orders of magnitude larger than 10! Okay, now time to go through the second half of the recent Coroutine discussion... - Jeff [1] http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html [2] http://code.mozy.com/projects/mordor/ [3] http://www.akira.ruc.dk/~keld/research/COROUTINE/ [4] http://dunkels.com/adam/pt/

2 1