- Boost - lists.boost.org

[range] Missing include in boost/range/algorithm/for_each.hpp
by Sergiu Dotenco 30 Aug '12

30 Aug '12

There is an issue with boost/range/algorithm/for_each.hpp which is missing an include. The problem seems to have been fixed in trunk two months ago (https://svn.boost.org/trac/boost/changeset/79180) but the changeset hasn't been applied to the release branch yet. Could this be done for the 1.52 release?

2 1

[fusion] undocumented sequence requirement: convert
by Eric Niebler 30 Aug '12

30 Aug '12

Say I have a valid fusion sequence. I want to use an mpl algorithm on it. I include boost/fusion/mpl.hpp and put a nested tag type in my sequence that is an alias for fusion::fusion_sequence_tag. So far, so good. Then I try to call mpl::pop_back on this sequence, and I find that, despite fulfilling all the documented requirements for Fusion ForwardSequence, the code fails to compile. That's because of this in boost/fusion/mpl/pop_back.hpp: template <> struct pop_back_impl<fusion::fusion_sequence_tag> { template <typename Sequence> struct apply { typedef typename fusion::result_of::pop_back<Sequence>::type result; typedef typename fusion::result_of::convert< typename fusion::detail::tag_of<Sequence>::type, result>::type type; }; }; My code doesn't compile because I haven't implemented the fusion::convert customization point. Where is that documented and what does it do? -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 12

[type_erasure]bug in computed_bases?
by Larry Evans 29 Aug '12

29 Aug '12

Based on the output of the test code(compute_bases.cpp) in the 1st attachment, the compute_bases metafunction defined in any.hpp is producing something like: concept_interface < concepts , concept_interface < mpl::at_c<concepts,1>::type , concept_interface < mpl::at_c<concepts,2>::type , ID , Enable > , ID , Enable > , ID , Enable > where concepts is the Concept argument to any. When the test code is run with: //#define OVERLOAD_SIMPLE the output is what should be expected with a_any.simple(); calling the simple<.>::apply static method. The output for this case is shown in the compute_bases.not_overload_simple.out. OTOH, when the test code is run with: #define OVERLOAD_SIMPLE the code in the concept_interface<typename requirements<C>::type,...>::simple is run. The output for this case is shown in the compute_bases.yes_overload_simple.out. This output shows that the concept_interface<C,...> CTOR is called where C == mpl::vector<...>. Is this the intended behaviour? If so, where is this spelled out in the documentation? The documentation here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… certainly doesn't suggest anything of that sort, and the doc here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… says: 1. typename Concept The concept that we're specializing concept_interface for. which uses the singular Concept instead of the plural Concepts, suggesting the Concept is not an mpl::vector<> of any sort. -regards, Larry

2 4

Review Request: odeint
by Mario Mulansky 29 Aug '12

29 Aug '12

Hi, after getting some good amount of positive feedback on our talk at boostcon we are now asking for a formal review process of the odeint library, currently hosted on github: https://github.com/headmyshoulder/odeint-v2 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 The code is hosted on github: https://github.com/headmyshoulder/odeint-v2 Documentation/Tutorial: http://headmyshoulder.github.com/odeint-v2/doc/index.html We are, of course, looking for a review manager as well. Thanks! Karsten and Mario

4 3

[type_erasure][docs]conceptdef.html terms
by Larry Evans 29 Aug '12

29 Aug '12

The doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… states: When a concept is instantiated with a specific set of type bindings, each placeholder is bound to a cv-unqualified non-reference type. After replacing each placeholder in the template argument list with the type that it binds to, the following must hold. * The number of arguments of apply in the bound concept must be the same as the number of arguments in the unbound concept. * The arguments and return type of apply in the bound concept can be derived from the corresponding arguments and the return type in the unbound concept as follows: If the argument in the unbound concept is a placeholder with optional cv and reference qualifiers, then the argument in the bound concept can be found by replacing the placeholder. Otherwise, the argument in the unbound concept must be the same as the argument in the bound concept. However, there is no apply in the builtin concept's: same_type (in same_type.hpp) null_construct (in constructible.hpp) destructible (in builtin.hpp) so, shouldn't the paragraph qualify the word concept with the word primitive, to make clear it's talking about item 3 in the list: There are three kinds of concepts. 1. The library defines a number of predefined concepts. 2. Any MPL Forward Sequence whose elements are concepts is also a concept. 3. Users can define their own primitive concepts. from the 2nd paragraph of conceptdef.html? IOW, rephrase the 1st sentence to: When a *primitive* concept is instantiated with a specific set of type bindings, I guess one could infer from the sentence 2 paragraphs up: Each primitive concept defines a single operation. that the word concept in subsequent paragraphs means primitive concept, but not every reader (in particular, this reader) would make that inference unless he'd actually looked at the definition of some of the predefined concepts. BTW, the same_type doc uses the term 'built in concept'; however, the conceptdef.html doc uses the term 'predefined concept'. It would be helpful if the same term were used everywhere. HTH. -regards, Larry

1 0

Re: [boost] a (useful?) crtp trick
by Gottlob Frege 29 Aug '12

29 Aug '12

declaration is crystal clean (read: self documenting), no need to use enable_if, etc. -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out Crystal clear, not crystal clean. Tony

1 0

[type_erasure]tests fail_any_cast_pointer_to_val fails compile
by Larry Evans 29 Aug '12

29 Aug '12

When running bjam, I get: compilation; default-directory: "~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure/libs/type_erasure/test/" -*- Compilation started at Tue Aug 28 21:33:51 bjam sh: icpc: not found ...patience... ...patience... ...found 2363 targets... ...updating 171 targets... gcc.compile.c++ bin/test_binding.test/gcc-4.8n/debug/test_binding.o gcc.link bin/test_binding.test/gcc-4.8n/debug/test_binding . . . gcc.compile.c++ bin/test_null.test/gcc-4.8n/debug/test_null.o gcc.link bin/test_null.test/gcc-4.8n/debug/test_null testing.capture-output bin/test_null.test/gcc-4.8n/debug/test_null.run **passed** bin/test_null.test/gcc-4.8n/debug/test_null.test gcc.compile.c++ bin/fail_default_construct.test/gcc-4.8n/debug/fail_default_construct.o In file included from fail_default_construct.cpp:11:0: ../../../boost/type_erasure/any.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any() [with Concept = boost::type_erasure::copy_constructible<>; T = boost::type_erasure::_self]': fail_default_construct.cpp:18:32: required from here ../../../boost/type_erasure/any.hpp:157:9: error: no matching function for call to 'assertion_failed(mpl_::failed************ boost::type_erasure::is_relaxed<boost::type_erasure::copy_constructible<> >::************)' BOOST_MPL_ASSERT((::boost::type_erasure::is_relaxed<Concept>)); ^ ../../../boost/type_erasure/any.hpp:157:9: note: candidate is: BOOST_MPL_ASSERT((::boost::type_erasure::is_relaxed<Concept>)); ^ svn update shows: ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ svn update At revision 80297. svn diff shows: ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ svn diff|filterdiff --exclude=\*bjam.normal\* Index: boost/type_erasure/detail/normalize.hpp =================================================================== --- boost/type_erasure/detail/normalize.hpp (revision 80297) +++ boost/type_erasure/detail/normalize.hpp (working copy) @@ -353,7 +353,14 @@ struct collect_concepts ::boost::type_erasure::detail::substitution_map<Map> >::type transformed; typedef typename ::boost::mpl::eval_if< + #if 0 + ::boost::mpl::or_ + < ::boost::is_same<transformed, void> + , ::boost::mpl::is_sequence<Concept> + >, + #else ::boost::is_same<transformed, void>, + #endif ::boost::mpl::identity<Out>, ::boost::mpl::insert< Out, Index: libs/type_erasure/test/bjam.normalize_no_is_seq.out =================================================================== ~/prog_dev/boost-svn/ro/boost_1_49_0/sandbox/ro/type_erasure/type_erasure $ Anyone else seeing this? -regards, Larry

2 1

[thread] Memory usage of threads on 64bit linux
by Conrad Mercer 29 Aug '12

29 Aug '12

Hey, I have been using boost threads on 32bit linux for some time and am very happy with their performance so far. Recently the project was moved to a 64bit platform and we saw a huge increase in memory usage (from about 2.5gb to 16-17gb). I have done profiling and found that the boost threads are the source of the huge allocation. Each thread is allocating about 10x what it was doing on 32bit. I profiled using valgrind's massif and have confirmed the issue using only boost threads in a separate test application. I also tried using std::threads instead and these do not exhibit the large memory allocation issue. I am wondering if anyone else has seen this behaviour and knows what the problem is? Thanks --

4 4

[system] Viral C++11 change would break dependent libraries:-(
by Beman Dawes 28 Aug '12

28 Aug '12

Ticket #7278 asks that Boost.System add C++11 noexcept support. A reasonable request, and I implemented it this morning by adding BOOST_NOEXCEPT at the appropriate places specified in the standard. But there is a problem. noexcept is viral, so any classes that inherit from a class that uses noexcept must be changed to also use no except. An example: Boost.Filesystem has this class: class codecvt_error_cat : public boost::system::error_category { public: codecvt_error_cat(){} const char* name() const {return "codecvt";} std::string message(int ev) const; }; Compiling with GCC 4.7 -std=c++0x results in this error: ..\..\../boost/system/error_code.hpp:187:32: error: overriding 'virtual const char* boost::system::error_category::name() const noexcept (true)' To fix it, the filesystem class has to be changed: class codecvt_error_cat : public boost::system::error_category { public: codecvt_error_cat(){} const char* name() const BOOST_NOEXCEPT {return "codecvt";} std::string message(int ev) const; }; I've held off committing the Boost.System changes to trunk until we've had a chance to discuss how to approach this potential break to an unknown number of Boost and user libraries. Ideas? --Beman

5 7

[contract] Broken postconditions on throw
by Andrzej Krzemienski 28 Aug '12

28 Aug '12

Hi Lorenzo, I am now now playing with Contract library and trying to break it. I checked that the framework checks the class invariant even when member function exits via an exception. This is an expected behavior and the framework is working fine. However, I note that the precondition of a (non-member) function is not checked when the function exits via throwing an exception. See the following program: # include <contract.hpp> double get_random_weight() { return -1.0; // erroneous implementation } CONTRACT_FUNCTION ( void (set_weight)( (double&) w ) postcondition(w >= 0.0) ) { w = get_random_weight(); if (w < 0.0) throw 1; // (*) } int main() try { double w = 0.0; set_weight(w); } catch (...) { std::cerr << "CAUGHT EXCEPTION" << std::endl; } Function set_weight() is intended to assign its (output) argument with a value representing weight (in the physical sense). We guarantee that the value we set is always non-negative. The function clumsily attempts to verify the condition itself (the line with *). It signals the failure with an exception, but unfortunately fails to satisfy the postcondition. I expect that this situation should be reported as a postcondition violation. But no violation is reported, and the program successfully outputs "CAUGHT EXCEPTION". Regards, &rzej

4 11