September 2012 - Boost - lists.preview.boost.org

Release branch closing for new features
by Marshall Clow 27 Sep '12

27 Sep '12

[ resending because it doesn't seem to have gone through ] So, we missed announcing this on Monday, so we're pushing back the deadline until Friday. On (tomorrow) Friday, Sep 29th, the release branch will close for new features, and be open only for bug fixes and doc fixes. On Tuesday, October 2nd, the release branch will close except by permission from the release managers. This is in preparation for the first 1.52.0 beta, scheduled for Monday, Oct 8th. -- The release managers

1 0

[reminder] [Review] ODEInt review ends tomorrow September 28
by Steven Watanabe 27 Sep '12

27 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library will end tomorrow. Only a few reviews have been submitted so far. If you plan to submit a review, please let me know. If anyone needs more time, we can see about extending the review period. -------------------------------------- About the library: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? In Christ, Steven Watanabe

1 0

heap corruption on windows due to windows_file_codecvt
by Pedro Larroy 27 Sep '12

27 Sep '12

Hi When using debug mode in windows with boost_filesystem there's "Debug Assertion Failed!" in _CtrIsValidHeapPointer When operator new is redefined it causes windows_file_codecvt not to be released with the matching release that it allocated it. We reported this to Microsoft as seems it's a bug in their STL. But so far, I tried with VS2012 and the bug seems not fixed... There's a workraround in boost that we are using for the moment: This has to be changed in path.cpp to fix it: - std::locale loc(global_loc, new windows_file_codecvt); + std::locale loc(global_loc, _NEW_CRT windows_file_codecvt); Should this fix be applied in boost until is fixed on Microsoft's side? This is a very nasty issue that will happen only with a redefined operator new. (For example we are using new with the sacalable allocator of tbb). Regards. Pedro.

1 0

[context] boost::ctx::?
by Dave Abrahams 27 Sep '12

27 Sep '12

ctx seems like a needlessly short abbreviation. Wouldn't it be better and more consistent with the rest of Boost to ask users to write using namespace ctx = boost::context; if they want something short? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 13

[shared_ptr][thread] spinlock initialization
by Yi Ding 27 Sep '12

27 Sep '12

I started using the spinlock in boost/smart_ptr/detail/spinlock.hpp and discovered that it needs to be manually initialized, even for the spinlock_sync version, which became a nasty bug when it manifested itself. This seems a bit out of sync with the rest of the mutexes in boost::thread. Now, I'm guessing that the fact that the spinlock is in boost::detail means that it's not really for outside consumption (newbie boost user here), but is there something in the works that will be? In the meantime, would it be possible to automatically initialize the spinlock (trivial in the case of spinlock_sync) or are there architectural issues with that? Otherwise, could we add a comment that says "in order to use these spinlocks you must initialize with BOOST_DETAIL_SPINLOCK_INIT" or "move along, these aren't the spinlocks you're looking for."

3 2

Problem using dijkstra_shortest_paths with Boost 1.51
by John Wiegley 27 Sep '12

27 Sep '12

Hello, I tried building my Ledger project today with Boost 1.51 and clang --std=c++11, and received the following error: --8<---------------cut here---------------start------------->8--- /usr/local/include/boost-1_51/boost/mpl/eval_if.hpp:38:26: error: no type named 'type' in 'boost::no_property' typedef typename f_::type type; ~~~~~~~~~~~~~^~~~ [...] /Users/johnw/Projects/ledger/src/history.cc:455:3: note: in instantiation of function template specialization 'boost::dijkstra_shortest_paths<boost::filtered_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::property<boost::graph_name_t, std::__1::basic_string<char>, boost::no_property>, boost::listS>, ledger::recent_edge_weight<boost::adj_list_edge_property_map<boost::undirected_tag, long, long &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_weight_t>, boost::adj_list_edge_property_map<boost::undirected_tag, ledger::price_point_t, ledger::price_point_t &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_point_t>, boost::adj_list_edge_property_map<boost::undirected_tag, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > > &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_ratio_t> >, boost::keep_all>, f_max<long>, boost::distance_combine_t, boost::bgl_named_params<boost::iterator_property_map<long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, long, long &>, boost::vertex_distance_t, boost::bgl_named_params<boost::iterator_property_map<unsigned long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, unsigned long, unsigned long &>, boost::vertex_predecessor_t, boost::no_property> > >' requested here dijkstra_shortest_paths(fg, /* start= */ vs, ^ --8<---------------cut here---------------end--------------->8--- My graph type is: typedef adjacency_list <vecS, // Store all edges in a vector vecS, // Store all vertices in a vector undirectedS, // Relations are both ways // All vertices are commodities property<vertex_name_t, const commodity_t *, property<vertex_index_t, std::size_t> >, // All edges are weights computed as the absolute difference between // the reference time of a search and a known price point. A // filtered_graph is used to select the recent price point to the // reference time before performing the search. property<edge_weight_t, long, property<edge_price_ratio_t, price_map_t, property<edge_price_point_t, price_point_t> > >, // Graph itself has a std::string name property<graph_name_t, std::string> > Graph; The full source is located here: https://github.com/jwiegley/ledger/blob/next/src/history.cc What has changed in Boost.Graph since 1.50? The same code builds fine with all the same compiler options using that version. Thanks, -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

[odeint] Documentation comments
by John Bytheway 27 Sep '12

27 Sep '12

This is not a review, just a few things I've caught while reading the odeint docs. Mostly cosmetic issues, but a couple of deeper questions. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "They also occur if partial differential equations (PDEs) are discretized in one coordinate."; wouldn't you have to discretize in all but one coordinate? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - I see no mention of any headers except the global one boost/numeric/odeint.hpp. Is it useful or possible to include only parts of the library? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "a simple function calculating f(x)'"; I think you mean either "f(x)" or "x'", not "f(x)'". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - There's one case here where you use "--" as an em dash. "on the example of explicit_error_rk54_ck -- a 5th order Runge-Kutta method". There are various other places throughout the docs which use just "-" for em dash. It would be best if you could use a proper em dash character, but in any case you should be consistent. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "which lead to the whole new subject of Chaos Theory"; s/lead/led/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the so called Rosenbrock method"; is "so called" necessary? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the first numerical experiment which has been implemented on a computer in 1953. It was studied at Los Alamos on one of the first computer (a MANIAC I) and it triggered a whole new tree of mathematical and physical science."; This is ambiguous (it could mean the first experiment amongst those in 1953). If you really mean it was the first computational numerics experiment then you should probably say something like "the first numerical experiment to be implemented on a computer. It was studied at Los Alamos in 1953 on one of the first computers (a MANIAC I) and triggered a whole new tree of mathematical and physical science." - "For example the unit test for Boost.Units take up to 4 GB of memory at compilation."; are you referring to the unit tests of Boost.Units, or a unit test of odeint that uses Boost.Units? Please clarify. - The matrix-as-state example has a bug: for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( 0 , x.size1() -1 ) = 0.0; should be for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( x.size1() -1, j ) = 0.0; This bug makes me think that you ought to provide a debug mode where every entry in dxdt is set to NaN before calling the system operator(), and then they are checked to be non-NaN afterwards. Of course, this would only work for types with a NaN value, but I think all your examples do have that (except maybe the multiprecision types). - "This is in principle all"; awkward phrasing, perhaps "In principle this is all" - I assume you know about the unfinished chunk of docs re PDEs and equations on networks. - "for full support the min( x , y ), max( x , y ), pow( y , y ) must be callable"; what are x and y? Is it significant that pow has both arguments equal but min and max don't? I hope the requirements on the numeric type are laid out more formally elsewhere; please link to that. - "We exemplary show this for a Hamiltonian system"; "exemplary" doesn't work here. You could use s/exemplary show/demonstrate/. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "simply to small"; s/to/too/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "Implicit solvers do only work"; s/do // - "They safe a part of their history" s/safe/save/ - In the section on controlled steppers, the formulae are getting sufficiently complex that it might be worth trying to use TeX-generated pngs rather than straight HTML (as is done in Boost.Math, e.g. <http://www.boost.org/doc/libs/1_51_0/libs/math/doc/sf_and_dist/html/math_to…>) - I can't figure out what the three lines after table 1.6 are about. - The long line "boost::numeric::odeint::result_of::make_dense_output< r..." in Dense output steppers is too long for my screen; can you break it? - The resizing policy names are a bit clumsy; I think always_resize, initially_resize, and never_resize might be better. - "Typical use cases for this kind of resizer are self expanding lattices like shown in the tutorial"; can you link to the relevant example in the tutorial? - "So it might be suitable that the system function itself is a pair of functions, one for computing the deterministic and one for the stochastic part. The first element of the pair simply computes the deterministic part while the second the stochastic one."; this is rather redundant; how about "So it might be suitable that the system function is a pair of functions. The first element of the pair computes the deterministic part and the second the stochastic one." * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - Personally I think the ranges are more useful than the iterators, so it would be nice if they were mentioned in the section title (e.g. "Iterators and Ranges") - "that is you write the above example in a shortified form"; "shortified" is not a word; perhaps "so you can write this example in a more succinct form". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - The note "odeint already includes all the code presented here, see gsl_wrapper.hpp, so gsl_vectors can be used straight out-of-box. The following description is just for educational purpose." is duplicated in the subsequent paragraph. - Using x/y for element-wise division in vector_space_algebra seems potentially contentious. Similarly for abs. Perhaps it would be better to provide a customization point in boost::numeric::odeint as you have done with vector_space_reduce, whose default implementations use / and abs as in the current scheme. That way people will not be required to implement potentially misleading operators for their types. - "vector_space_reduce_impl< state_type >::reduce( state , operator , init )"; you probably shouldn't use the keyword "operator" as an identifier here. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "the state_type of the stepper must not necessarily be used to call the do_step method"; I'm not sure what this means; should it be "the state_type of the stepper need not necessarily be used to call the do_step method" * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - Concepts are normally written without underscores, so SymplecticSystem rather than Symplectic_System. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - In various places you have ScaleSum/N/ with literal '/' characters, where I presume they were intended to be formatting to make 'N' italics. - Rather than having a dedicated array_algebra, could you not have range_algebra automatically switch to the more efficient implementation when it detects a suitable State type? I hope to get a chance to play with the library later and submit a proper review. For now, congratulations on an impressive library. John Bytheway

3 6

[test] Patches to improve test log detail for better thirdparty integration
by Jamie Allsop 26 Sep '12

26 Sep '12

In light of recent discussions regarding Boost.Test I've created 3 tickets in trac with patches against trunk that incrementally improve the ease with which Boost.Test can be integrated with thirdparty continuous integration tools, while at the same time improving the output offered. These are patches we've been using for some time locally, the recent discussions highlighted the importance of pushing patches like these to a wider audience. In summary the key changes are: * https://svn.boost.org/trac/boost/ticket/7410 * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on completion of all tests and so cannot be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html These patches address what I believe to be important missing features of Boost.Test. We have been using these patches in our systems with Boost 1.49 and enjoy very nice CI integration with Trac Bitten and our Scons build tools. I would therefore encourage those that use Boost.Test and who are interested in these patches in general to take a look. The Boot.Timer patch is important as it also addresses compile issues. See the recent thread here: http://thread.gmane.org/gmane.comp.lib.boost.devel/234411 Gennadiy - assuming you find these acceptable they could be committed to trunk. I don't have commit privileges to do it myself and besides they need reviewed first. Also I would prefer a closer look was taken at the impact they might have on Boost.Test's tests. Finally I should also note that one reason for providing the BOOST_TEST_USE_DEPRECATED_TIMER macro was to circumvent the issue of the new Boost.Timer depending on Boost.System. I don't recall if Boost.System can used header-only? I certainly remember a lot of discussion about it. Jamie

2 2

[test] Support use of test tools and report generation in non-test programs - facilitating test/validation modes
by Jamie Allsop 26 Sep '12

26 Sep '12

An important use case that we have is the ability to run test scenarios on a production binary by specifying a 'test' mode. In test mode we essentially run through a series of different scenarios, asserting various conditions, comparing expected results and so on. In order to minimise the custom code we needed for this we decided to make use of Boost.Test. All the test tools are there, report generation and so on. In addition we have all the report analysis tools in place to interpret the output. The problem however, is that Boost.Test essentially requires a custom main() function. Either one of the ones provided by Boost.Test or one performing Boost.Test specific initialisation. In our production systems we have, like many, a fairly standard main() that ensures uniform behaviour across binaries and we do not want to pollute that with Boost.Test specific code. Notably we also do not want to pollute our command line parameters or configuration with 'global' Boost.Test arguments to control the test report output. Finally we want to control exactly when the tests are executed. I've created ticket #7419 to cover this use case and have also attached a small patch that facilitates the capabilities required to support it. https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing. The patch attached is based on a patch against boost 1.49. The one attached to the ticket is for trunk. Again this is a small patch that is genuinely useful so I'd like to see it make its way into trunk. As far as I know there are no side-effects for adding these changes, tests all pass and so on. Jamie

1 0

Formal Review Request [stl_ext_adv]
by Vadim Stadnik 26 Sep '12

26 Sep '12

Hi all, I would like to request a formal review of the library “STL extensions based on advanced data structures” [stl_ext_adv]. Project location: https://github.com/vstadnik/stl_ext_adv_review Quick view of documentation: http://dl.dropbox.com/u/51041088/stl_ext_adv_review/doc/index.html The previous version of this library is based on dynamically allocated data structures. It was discussed by Boost community in this thread: http://boost.2283326.n4.nabble.com/stl-ext-adv-Interest-in-advanced-data-st… The new version has two major improvements. It offers more efficient array based data structures and extensions of move semantics functions of STL containers. I am looking for the review manager. I would really appreciate if someone interested in advanced data structures could take this role. Early comments are welcome! Regards, Vadim Stadnik SUMMARY The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. OVERVIEW Both sequences and associative containers support: - random access iterators; - logarithmic time insert and erase operations for a single element anywhere within a container; Sequences support: - the union of interfaces of the C++03 sequence containers: std::list, std::deque and std::vector; - complete set of move semantics functions splice() and split() that guarantee logarithmic complexity in the worst case; Associative containers support: - equally efficient access to elements by their keys and positions; - logarithmic time search operations using keys of the container elements; - logarithmic time split operations in the general case and logarithmic time merge operations in special cases. One basic container implements the efficient algorithm accumulate(), which sums up any consecutive elements of a container in logarithmic time. The algorithm is fundamental to many important applications, such as the numerical integration and statistics. The array based data structures improve locality of reference and offer more efficient algorithms against equivalent dynamically allocated data structures. The wide set of the efficient member functions provided by the new containers makes them useful to improve the performance of algorithms using the standard containers with at least one relatively inefficient operation or a bidirectional iterator.

1 0