- Boost - lists.preview.boost.org

mpi compile bug
by 陈立红 03 Sep '12

03 Sep '12

Hi guys, I have installed the OpenMPI_v1.6.1 and want to make use of boost mpi. But I cannot compile it with msvc10.0 successfully. The error message is like below. I found similar bug Ticket #5465 (new Bugs), but there's no one comment on it. Please help. E:\soft\boost_1_49_0>bjam stage --toolset=msvc-9.0 --with-mpi --stagedir="E:\sof t\boost_1_49_0\Debug\lib10" link=static runtime-link=shared runtime-link=static ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� ָ��줿�ѥ��Ҋ�Ĥ��ޤ�� MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - chrono : not building - date_time : not building - exception : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - math : not building - mpi : building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...found 1 target... Regards, Lihong Chen

1 0

[trac] Library components: ATTENTION LIBRARY AUTHORS
by Rene Rivera 03 Sep '12

03 Sep '12

If you are the author of an accepted library please remember to ask to add the library to the trac bug system. It's important that others have a component to assign to bugs. In order to add the library component we need to know the trac *account* name you are using. Please check in trac to see if your library has a component (with this report <https://svn.boost.org/trac/boost/report/15>). If not, or if there are errors, please reply here with the new, or corrected, information. And if you don't happen to have a trac account please ask for one (<https://svn.boost.org/trac/boost/wiki#GettingaTracSVNUserid>). Thank you. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[lockfree] Faulty (?) static assert
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey, The lockfree::queue constructors raise a static assert if no capacity is specified. This contradicts the member initialization code close to the assert, for instance: queue(void): head_(tagged_node_handle(0, 0)), tail_(tagged_node_handle(0, 0)), pool(node_allocator(), has_capacity ? capacity : 0) { BOOST_STATIC_ASSERT(has_capacity); initialize(); } which implies that 'has_capacity' is allowed to be false. From what I can see 'has_capacity' could be false, indeed, in particular if the queue is not bounded in size. Would changing this to queue(void): head_(tagged_node_handle(0, 0)), tail_(tagged_node_handle(0, 0)), pool(node_allocator(), has_capacity ? capacity : 0) { BOOST_STATIC_ASSERT(has_capacity || capacity); initialize(); } reflect the actual intention? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 8

[lockfree] Type conversion warnings
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey all, The attached patch fixes a couple of warnings about possible loss of precision caused by integral type conversions for MSVC. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 1

[lockfree] freelist_stack::allocate and freelist_stack::deallocate should not be private
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hey all, Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct). Would it be possible to make the mentioned functions 'protected' instead? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3

Please create a category for atomic, context, and lockfree in trac
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Please create a category for atomic, context, and lockfree in trac. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

3 4

[Review:Contract] Some questions
by Vicente J. Botet Escriba 02 Sep '12

02 Sep '12

Hi, First of all, thanks Lorenzo for your work on pre-processor programming. With this library, you have showed to me how far the pre-processing can go in terms of expressiveness. I have some questions before doing a complete the review: = C++11 compatibility = * Does the library use c++11 features when available? I was thinking e.g. on the emulated virtual specifiers. BTW, I think the "new" virtual specifier was removed from the standard, but maybe I'm wrong. * I think the library don't allow to declare C++11 specific classes/function. E.g * variadic templates * noexcept functions * constexpr functions * class/function attributes BTW, I have not see any example using exception specifications using 'throws'. Does the library support them? Could you confirm? and if not, could you tell us if you have a plan to support them? = Postconditions result = "Postconditions can access the function return value by declaring a variable of type |auto| and assigning it to the |return| keyword (the variable name is arbitrary but |result| is often used)." What prevent the library to the use of return instead of an auto variable postcondition( // Postconditions. auto old_value = CONTRACT_OLDOF value, // Old value(s). value == old_value + 1, // Assertion(s)... return == old_value ) instead of postcondition( // Postconditions. auto result = return, // Result value. auto old_value = CONTRACT_OLDOF value, // Old value(s). value == old_value + 1, // Assertion(s)... result == old_value ) =Constant assertions = I would expect that the old are always const so the following postcondition( auto old_even = CONTRACT_OLDOF even, auto old_odd = CONTRACT_OLDOF odd, // `[old_]even` and `[old_]odd` all `const&` within assertions. const( even, old_even ) even == old_even + 2, const( odd, old_odd ) odd == old_odd + 2 ) should be rewritten without loss of semantics as postcondition( auto old_even = CONTRACT_OLDOF even, auto old_odd = CONTRACT_OLDOF odd, // `[old_]even` and `[old_]odd` all `const&` within assertions. const( even ) even == old_even + 2, const( odd ) odd == old_odd + 2 ) = Oldof = As the old of value must be declared using a variable, using a specif oldof keyword that will replace auto old_size = CONTRACT_OLDOF size(), by oldofold_size = size(), could simplify the syntax. What do you think? Some minor points: * Why do you use( void ) instead of () in the functions without parameters? e.g. public: bool empty ( void ) const { return vector_.empty(); } Some suggestions: * Use 2 spaces indentation instead of 4 could reduce the width of the page, in particular when you use several columns. * The use of'int const' as return type is verbose and could be replaced by just int. Best, Vicente

2 21

[context] Recent changes (rev. 80363) break compilation
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The latest commit to trunk (rev. 80363) breaks compilation of Boost.Context on Windows. I'm attaching a patch fixing the issue. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[Review:Contract] Base class preconditions not checked
by Steven Watanabe 02 Sep '12

02 Sep '12

AMDG Test case attached. The problem is that the precondition test is executed when initializing a virtual base. Virtual bases are always initialized by the most derived class, so the preconditions of base class constructors are never checked. In Christ, Steven Watanabe

2 1

[lockfree] Inconsistent typedef tag_t in tagged_ptr
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The embedded typedef <...> tag_t has inconsistent visibility in the two implementations of tagged_ptr. In tagged_ptr.hpp this typedef is 'public', while in the file tagged_ptr_ptrcompression.hpp this typedef is 'private'. Would it be possible to make it public in both cases (patch attached)? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[context] Windows ctx::maximum_stacksize() runtime asserts
by Hartmut Kaiser 02 Sep '12

02 Sep '12

Hey all, The Windows implementation of boost::ctx::maximum_stacksize() does always assert: std::size_t maximum_stacksize() { BOOST_ASSERT( ! is_stack_unbound() ); static std::size_t stacksize = 8 * 1024 * 1024; return stacksize; } That is because is_stack_unbound() will unconditionally return true. Patch is attached - ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

MPI maintainer?
by Ralf Grosse-Kunstleve 02 Sep '12

02 Sep '12

Who is currently maintaining Boost MPI? We have two trac items I'd like to assign to the MPI maintainer. The first one has been sitting there for a long time already. https://svn.boost.org/trac/boost/ticket/6123 https://svn.boost.org/trac/boost/ticket/7316 Ralf

1 0

[test] Boost.Test unreleased since November 2009 ?
by Mathieu Champlon 02 Sep '12

02 Sep '12

Hi, I've noticed that no merge has been made from trunk to the release branch for Boost.Test since November 2009, meaning that a lot of bug fixes and features have remained unreleased. Is it on purpose ? Thanks, MAT.

2 1

[test] Where should I put replacement functions for WinCE?
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, Windows CE don't have time and clock functions, getenv function and errno.h (though they seem to have _errno function). I needed to define these things to get Boost.Test to build for WinCE. Now it would be nice to have this work by default. I can provide the definitions (they are quite simple), but I am not sure where would be correct place for them. Should I add them to config/platform/win32.hpp, create config/platform/wince.hpp or put them just in test? Thanks, Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] sigaltstack does not work on older Android
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, Android NDK contains several "platforms", depending on which release one desires to be compatible with. Boost test compiles fine with android-8 and newer, but the older versions have incomplete definition of sigaltstack (they define the structure, but not the function), causing compilation error in boost/test/detail/impl/execution_monitor.ipp. I have fixed it locally by adjusting the condition for defining BOOST_TEST_USE_ALT_STACK, but I am not sure which level of fix would be best suited for integrating in boost. I see 3 options: 1. Leaving it as is and simply saying android is only supported from API level 8 (that's 2.2; we are still compiling for 2.1 (which has no changes in native since 2.0)) 2. Simply disabling BOOST_TEST_USE_ALT_STACK in Android; it's not necessary after all. 3. Being really precise and reading the API version, but that requires including extra header. It would be nice, but I am not sure what is the correct place to include it. Here is a simple patch that just disables sigaltstack for Android: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -173,7 +173,7 @@ namespace { void _set_se_translator( void* ) {} } # endif # endif -# if !defined(__CYGWIN__) && !defined(__QNXNTO__) +# if !defined(__CYGWIN__) && !defined(__QNXNTO__) && !defined(__ANDROID__) # define BOOST_TEST_USE_ALT_STACK # endif And here is a more complex patch that on android (the __ANDROID__ macro is predefined by the compiler in Android NDK) reads the api-level and uses it to decide: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -173,7 +173,11 @@ namespace { void _set_se_translator( void* ) {} } # endif # endif -# if !defined(__CYGWIN__) && !defined(__QNXNTO__) +# if defined(__ANDROID__) +# include <android/api-level.h> +# endif + +# if !defined(__CYGWIN__) && !defined(__QNXNTO__) && (!defined(__ANDROID__) || __ANDROID_API__ >= 8) # define BOOST_TEST_USE_ALT_STACK # endif -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] Fix WinCE workaround
by Jan Hudec 02 Sep '12

02 Sep '12

Hello Folks, boost/test/impl/execution_monitor.ipp has workaround for older MSVC++ and assumes WinCE version need it too. However the WinCE compiler caught up in next version. Here is a proposed patch: --- a/boost/test/impl/execution_monitor.ipp +++ b/boost/test/impl/execution_monitor.ipp @@ -84,7 +84,7 @@ using std::va_list; typedef unsigned uintptr_t; # endif -# if BOOST_WORKAROUND(_MSC_VER, < 1300 ) || defined(UNDER_CE) +# if BOOST_WORKAROUND(_MSC_VER, < 1300 ) || (defined(UNDER_CE) && BOOST_WORKAROUND(_MSC_VER, < 1500 )) typedef void* uintptr_t; # endif -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[test] Interest in gtest-like output?
by Jared Grubb 02 Sep '12

02 Sep '12

I really like the Boost.Test framework, however, I cant help but have a bit of envy over how great the output from googletest looks. I've been playing around with writing a formatter/outputter that emulates the output style of googletest, and I am willing to spend some time to pretty it up and generate a patch if there's interest. Does anyone think this would be a worthy submission to boost? For an example of what the output looks like, this site has some great examples: http://www.ibm.com/developerworks/aix/library/au-googletestingframework.html (just to clarify: I'm not suggesting changing any BOOST_TEST syntax, just adding a new optional way to format the test progress and results to stdout) Jared

3 2

Re: [boost] [lockfree] Faulty (?) static assert
by Hartmut Kaiser 01 Sep '12

01 Sep '12

> The lockfree::queue constructors raise a static assert if no capacity is > specified. This contradicts the member initialization code close to the > assert, for instance: > > queue(void): > head_(tagged_node_handle(0, 0)), > tail_(tagged_node_handle(0, 0)), > pool(node_allocator(), has_capacity ? capacity : 0) > { > BOOST_STATIC_ASSERT(has_capacity); > initialize(); > } > > which implies that 'has_capacity' is allowed to be false. From what I can > see 'has_capacity' could be false, indeed, in particular if the queue is > not bounded in size. > > Would changing this to > > queue(void): > head_(tagged_node_handle(0, 0)), > tail_(tagged_node_handle(0, 0)), > pool(node_allocator(), has_capacity ? capacity : 0) > { > BOOST_STATIC_ASSERT(has_capacity || capacity); > initialize(); > } > > reflect the actual intention? Sorry, I meant: > BOOST_STATIC_ASSERT(has_capacity || !capacity); Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > > Regards Hartmut > --------------- > http://boost-spirit.com > http://stellar.cct.lsu.edu > >

1 0

[atomic] Windows autolinking and longlong patches
by Hartmut Kaiser 01 Sep '12

01 Sep '12

Hey, Please find attached two patches for Boost.Atomic (trunk, rev. 80334) adding auto-linking for MSVC, fixing symbol visibility, and fixing a long long problem. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[type_eraseure]Why not make default concept_interface a metafunction returning Base?
by Larry Evans 31 Aug '12

31 Aug '12

Since the unspecialized concept_iterface definition: template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base {}; does nothing, and it's used to compose the any base class heirarchy in: template<class Derived, class Concept, class T> struct compute_bases { typedef typename ::boost::mpl::fold< typename ::boost::type_erasure::detail::collect_concepts< Concept >::type, ::boost::type_erasure::any_base<Derived>, ::boost::type_erasure::concept_interface< ::boost::mpl::_2, ::boost::mpl::_1, T > >::type type; }; why not eliminate the empty concept_interfaces by redefining the unspecialized concept_interface to: template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base { //The following enables mpl::fold, when using //this as the binary operator, to skip this //empty interface. typedef Base type; }; I believe that would work since mpl::fold uses the nested type if it's available, IIUC. Although it would not change the behaviour of any code, it would make the intent of the code clearer. Also, while trying to understand what the code is doing by using a type name demangler, I found all those empty concept_interfaces are just noise. -regards, Larry

1 0

[Review:Contract] Contract Broken Handlers , BOOST_NO_EXCEPT and noexcept
by Vicente J. Botet Escriba 31 Aug '12

31 Aug '12

Hi, I would like to know if Boost.Contract could work when BOOST_NO_EXCEPT is defined. I suspect that it can not at present, as the user needs to re-throw the exception to know the broken nature. Maybe the handler could have the an exception/error object as parameter instead. In order to be able to use contracts in C++11 functions declared noexcept I would need that the contract handler are declared noexcept also, in particular when the contract is broken from a destructor, which is often declared noexcept in C++11. Maybe the library can provide some specific set handlers that expect a noexcept handler for the destructor context. BTW, could the ALL CAPITAL |FROM_CONSTRUCTOR, ... enumeration literal|s be renamed to lower case from_constructor, ...? Best, Vicente

2 3

Question about release branches
by Pedro Larroy 30 Aug '12

30 Aug '12

Hi I'm not able to find some fixes such as (78513) in tags/release/Boost_1_51_0/ nor tags/release/Boost_1_50_0/ Why some fixes that are in trunk didn't made it to the release branches? Thanks. Pedro.

2 1

[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

[1.52.0] Open for merging
by Marshall Clow 28 Aug '12

28 Aug '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

3 2

[contract] a possible future extension
by Andrzej Krzemienski 28 Aug '12

28 Aug '12

Hi Lorenzo, This is definitely outside the scope of the review, but I was wondering whether it would be feasible for the macros in Boost.Contract to handle base class aliases, as described in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html The positive "side effect" of your framework is that it has the potential to add various missing language features. I am wondering if these aliases proposed in N2881 are worth the effort. Regards, &rzej

2 1

a (useful?) crtp trick
by pavel 28 Aug '12

28 Aug '12

hi all i post this in the hope someone finds this technique useful to make long story short, here is a snippet: template<typename t> //tag deducing util struct base_tag { typedef decltype(get_tag((t*)42)) type; }; template<typename type, typename tag = typename base_tag<type>::type> struct Base //crtp base class { friend tag get_tag(type*); //helper declaration, never defined }; template<typename type> //no mention of tag void f(const Base<type>&) //tag is deduced automatically {} struct Foo : Base<Foo, void> //derived type {}; int main() { Foo foo; f(foo); } the idea is that if we have an associated type (or types) along with the "real" type in the crtp pattern we can make that associated type deduced automatically and even pretend there is no such tag leaving it e.g. for advanced usage more on this here: http://programmizm.sourceforge.net/blog/2012/because-we-can -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

3 7

release manager for 1.52?
by Oliver Kowalke 28 Aug '12

28 Aug '12

Who is the release manager for 1.52?

2 1

[atomic] lockfree failure on msvc 64-bit
by Christoph Macheiner 27 Aug '12

27 Aug '12

As indicated by http://www.boost.org/development/tests/trunk/developer/output/cm_x64-boost-…. In boost/atomic/detail/interlocked.hpp, BOOST_ATOMIC_LLONG_LOCK_FREE must be defined to 2 if _WIN64 is defined (cas64strong.hpp is included afterwards). Because the library has not yet been released, I didn't bother to create a ticket and because the change is so trivial I didn't create a patch as well (if either or both is required or wanted, please let me know). Question: If I recall correctly, long long can be made lockfree also in 32-bit. If I am right, is there a reason why it hasn't been done? Thanks. --Christoph.

1 0

memory corruption in async_read_until using asio::ssl
by Jim Page 27 Aug '12

27 Aug '12

Afternoon All I am seeing an occasional memory corruption bug, using valgrind, in our web server application that is using boost::asio::ssl, and it seems to be related to calls to async_read_until, where several chunks of data are required before the terminating regex is found. What appears to be happening is that engine::perform() causes a write (via ssl3_read_bytes()) on a deleted memory region, the buffer into which decrypted data is written. This region was delete'd via invocation of the detail::io_op::handler, and in turn via read_until_delim_op::operator(), due to prepare() being called on the streambuf, and a std::vector<char> is delete'd in order to create a larger one. It seems like one of the chain of handlers is using a pointer which is becomes invalid when the streambuff is expanded after failing to find the regex terminator after one or more reads, and prepare() is called before the next async_read_some() on the underlying stream. I have included the valgrind output at the end - sorry for the large size. I am pretty certain that I have ruled out the obvious (multiple simultaneous attempts to read using the same streambuf), and I am only using one thread for the io_service. This seems a pretty common potential failure mode, so perhaps I am barking up the wrong tree - I'd appreciate anyone's opinion before I start a potentially tricky debug effort requiring modification to the boost libraries on our production servers. I'm using boost 1.49. There's a lot of optimization on the application which is why some calls are optimized out of the valgrind dump. The machines are running Centos 5.8, x86_64. Compiler is gcc 4.4.6. Thanks for looking Jim Page ==29870== Thread 22: ==29870== Invalid write of size 1 ==29870== at 0x4A088F8: memcpy (mc_replace_strmem.c:587) ==29870== by 0x3400821EDE: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) ==29870== by 0x340081E750: ??? (in /lib64/libssl.so.0.9.8e) ==29870== by 0x66A75B: boost::asio::ssl::detail::engine::perform(int (boost::asio::ssl::detail::engine::*)(void*, unsigned long), void*, unsigned long, boost::system::error_code&, unsigned long*) (engine.ipp:219) ==29870== by 0x7E3326: boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::rea d_until_expr_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<bo ost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > >::operator()(boost::system::error_code, unsigned long, int) (engine.ipp:151) ==29870== by 0x7E45C2: boost::asio::detail::wait_handler<boost::asio::ssl::detail::io_op<boost::asi o::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (bind_handler.hpp:46) ==29870== by 0x619783: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service_operation.hpp:37) ==29870== by 0x79F4FE: BayeuxServer::run() (io_service.ipp:59) ==29870== by 0x364800DB8E: ??? (in /usr/lib64/libboost_thread.so.1.49.0) ==29870== by 0x3AE300677C: start_thread (in /lib64/libpthread-2.5.so) ==29870== by 0x3AE20D325C: clone (in /lib64/libc-2.5.so) ==29870== Address 0x1b508610 is 0 bytes inside a block of size 1,024 free'd ==29870== at 0x4A05A33: operator delete(void*) (vg_replace_malloc.c:346) ==29870== by 0x658E54: std::vector<char, std::allocator<char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned long, char const&) (new_allocator.h:95) ==29870== by 0x68B805: boost::asio::basic_streambuf<std::allocator<char> >::reserve(unsigned long) (stl_vector.h:851) ==29870== by 0x7E2EF2: boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > >::operator()(boost::system::error_code const&, unsigned long, int) (basic_streambuf.hpp:207) ==29870== by 0x7E32DE: boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > >::operator()(boost::system::error_code, unsigned long, int) (read_op.hpp:59) ==29870== by 0x7E493C: boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (bind_handler.hpp:118) ==29870== by 0x613778: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asi o::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37) ==29870== by 0x619783: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service_operation.hpp:37) ==29870== by 0x79F4FE: BayeuxServer::run() (io_service.ipp:59) ==29870== by 0x364800DB8E: ??? (in /usr/lib64/libboost_thread.so.1.49.0) ==29870== by 0x3AE300677C: start_thread (in /lib64/libpthread-2.5.so) ==29870== by 0x3AE20D325C: clone (in /lib64/libc-2.5.so)

1 0

Boost.Process 0.5 released
by Boris Schaeling 27 Aug '12

27 Aug '12

Boost.Process 0.5 has been released! Documentation and library can be found at: <http://www.highscore.de/boost/process0.5/> Why version 0.5? We have no official process management library in Boost yet. But we had countless drafts since 2006. In order not to get completely lost between all those drafts I gave them version numbers. For example, 0.1 was the very first draft in 2006. 0.31 is the draft documented at <http://www.highscore.de/cpp/process/>. And 0.4 was the draft which was rejected in a formal review in spring 2011. Version 0.5 is the latest attempt to create a process management library. What's new? Version 0.5 has a very different design than all other drafts before. The design was proposed by Jeff Flinn who introduced it briefly at BoostCon 2011 when we gave a presentation on Boost.Process. The goals of this new version are: * A lightweight implementation (no overly complicated code anymore). * A fully extensible library (no need for arbitrary "extension points"). * Support for system-level cross-platform concepts only (no Java-like constructs). Other goals like making the library easy to use were of course also targeted. But these were goals before. The goals above are important as those things have been criticized in earlier drafts and were as far as I see the main reasons why version 0.4 had been rejected. What now? Please have a look at the documentation and think about whether this library could fit into Boost. If you have more time, please download and play around with the new version. Concentrate on the bigger picture: Does the design make sense? Is it easy to understand? Can you do what you want to do? Does it look and feel like modern C++? This is not a formal review. But it would help to get some feedback to see a tendency. After six years, two Google Summer of Code projects, countless drafts and still a lot of interest from many people in a process management library in Boost, we might be able to get somewhere this time. (If you are on Windows: There is a bug in Boost.Iostreams which has been fixed in the release candidate 1 of Boost 1.51.0. See the documentation if you run into a problem when closing pipes.) Anything missing? We had a closed beta test in the previous two weeks with about ten people who had contacted me because of their interest in Boost.Process. I got already some good feedback and have to change a few details. These are only details though and shouldn't stop anyone from using this new version now. If everyone is happy with the overall design and architecture and it's only details we have to discuss, it's already a huge step forward. Last but not least: Boost.Process 0.5 wouldn't exist without the help of Intra2net AG (<http://www.intra2net.com/>). Intra2net AG sponsored a project to support the development of Boost.Process. It was this sponsorship which made it possible to create this new version. Thanks to them! Boris

9 46

[rational] Over/underflow checked update ready for comments
by Dan Searles 26 Aug '12

26 Aug '12

>> Quick overview of the update: the original usage and >> code of the template class remains mostly as before, ie >> boost::rational<int> RationalVar; should work as >> in the original version. Adding 'true' as a second >> template parameter, however, allows an exception to >> be raised if an operation with a class variable results >> in a value that can't accurately be represented >I haven't looked at anything else, but I dislike using true/false as the template argument. I'd prefer meaningful names. _____ >Rob Stewart robert.stewart(a)sig.com >Software Engineer using std::disclaimer; >Dev Tools & Components >Susquehanna International Group, LLP http://www.sig.com Replaced the bool template parameter with an enum: enum RationalChecktype {RationalNoChecking, RationalCheckforOverflow};

1 0

[contract] "Duplicated globals" problem
by Andrzej Krzemienski 26 Aug '12

26 Aug '12

Hi Lorenzo, I think that installing broken contract handlers will not work correctly when a program is linking with DLLs on Windows. I do not know how dynamic linking works on Linux. Here is a sketch of a sample program that fails to work as expected. The program consists of two projects: one builds a DLL, the other builds an executable that links with the DLL: DLL: ==================================== # include <contract.hpp> # include "testdll.h" CONTRACT_FUNCTION ( int (give1) () postcondition(auto result = return, result == 1) ) { return 2; // obviously wrong } DLL_MODE void test_contracts() { int i = give1(); } ==================================== EXE: ==================================== # include <contract.hpp> # include "../testdll/testdll.h" void PostconditionHandler( contract::from const& context ) { std::cerr << "ERROR!!!" << std::endl; } int main() { contract::set_postcondition_broken(&PostconditionHandler); test_contracts(); } ==================================== I expect that the program would use the broken postcondition handler I installed, but it still uses the default one. The cause is that Contract is using some global object to store the installed handler, but when a program is linked with a DLL both the program and the DLL store their own copy of the global. The global is duplicated. THe one in the EXE registers my callback, but the global in the DLL still keeps the default handler. The only way to solve this issue is to -- at least in the cases when users' programs link with DLLs -- ship Contract with a small DLL that stores the unique copy of the globals. This is how Boost.Log handles this problem. Quoting the documentation ( http://boost-log.sourceforge.net/libs/log/doc/html/log/installation.html) *"If your application consists of more than one module (e.g. an exe and one or several dll's) that use Boost.Log, the library must be built as a shared object. If you have a single executable, you may build the library as a static library." * Regards, &rzej* *

2 1

complex acos and atanh
by Stephen Montgomery-Smith 26 Aug '12

26 Aug '12

Hey people, I was trying out your complex arc-trig functions, to compare them with some that I have written: http://people.freebsd.org/~stephen/catrig.c. I am finding that your acos function is getting some of them wrong. For example, your program evaluates acos(1.00000002785941 + I*5.72464869028403e-200) as 0 - I*0.000236048349018331 whereas it should be 2.42520172707401e-196 - I*0.000236048349018331. Also your complex atanh function does quite badly in some edge cases. I presume it is because Hull, Fairgrieve and Tang did not write a paper on that function. If you email Fairgrieve, he may give you a copy of the paper that was never published. He sent me a copy, but doesn't want it widely distributed. I devised my own algorithm at http://people.freebsd.org/~stephen/catrig.c, which actually turns out to be very similar to the unpublished algorithm of Hull, Fairgrieve and Tang. Anyway, I would be happy to work with whomever is currently working on these algorithms. I think someone must be, because I see that someone fixed a bug in asin since 1.48.0. Best regards, Stephen

2 2

[locale] Custom Gettext paths.
by Jookia 26 Aug '12

26 Aug '12

Hello! I'm extremely happy about Boost.Locale, but I've found a few things lacking. So at first I wrote a some wrappers to get around a few flaws with my usage of Boost.Locale. One of these flaws was how it's hardcoded to use the Gettext directory hierarchy. I'd rather store my stuff in 'lang/en_US.mo' rather than 'lang/en_US/LC_MESSAGES/my_app.mo'. The patch adds a 'path format' feature, which allows you to format the directory structure when finding Gettext catalogs, to achieve the effect above. All you really have to do is run: gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy. to achieve the result that I prefer, or gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy. to achieve the result that Boost.Locale uses right now. Ripped straight from Doxygen comments: {1} A path to search for catalogs in. {2} The locale's name. {3} The locale's category. {4} The Gettext domain. I'm new to submitting patches and things, and I'm not sure how I could make this feature better or even acceptable if it isn't already, but I'm sure it'd help others out there. There are a few drawbacks I've found with my code: - To be backwards compatible I've had to add some hackery to add the Gettext format if the path formats vector is empty. - Without consulting documentation, the format is unreadable. - I haven't tested it on the Win32 backend. I'm 90% sure the code would work, it's only 4 lines of code added and it's identical to the code added in the other backends, but it's still untested code. - It's not tested properly. By properly, I mean the tests past with adding a format, and falling back to the default format, but I haven't tried having a 'compact' format. I'm not sure if this would indicate a fault in the formatting code though, as that'd be the only difference code-wise, unless there's more code that has the Gettext hierarchy hardcoded, that didn't fail when I didn't fix the tests. The patch itself is based off of SVN r80097, and despite the diff being for r80104 I haven't tested it in that.. I did the work internally in Git but I made the patch using SVN, in case that matters. I've attached the patch, but I'm not sure how well that's going to go over considering I'm new to mailing lists, and I'm using.. Thunderbird.. Yeah. In case the attachment fails, it's available at http://sprunge.us/VSiX . I'd also like to know if it's appropriate to put '[patch]' in the title for any future patches, and if it should go after '[locale]' or at the end of the title. Thanks, Jookia.

2 13

boost::filesystem -- using non-POSIX locale crashes on Solaris
by JonathonS 26 Aug '12

26 Aug '12

Hi, I am currently using boost::filesystem::path on Solaris, and I noticed that if I set the locale to anything except "C" or "POSIX" such as "en_US.UTF-8", that it crashes i.e. a run-time error gets thrown. I found a link describing the issue here: https://svn.boost.org/trac/boost/ticket/5928 My question is though, whether it is possible to use boost::filesystem without locales? Meaning, if I know my string is a UTF-8 string, is it possible to avoid the locale processing within the boost filesystem? Thanks, J

3 2

[Review] Boost.Contract Review Starts Today(*)
by Dave Abrahams 26 Aug '12

26 Aug '12

The review period for Lorenzo Caminiti's Boost.Contract library runs from today through August 31st. I'm pleased to serve as review manager. ,----[ Important Notes ] | - Please begin your review's subject line with "[Review:Algorithms]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * 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? (*) Well, OK, the review period officially started yesterday. Sorry for the delayed announcement -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

[iterator] transform_iterator and move-only types
by Nathan Ridge 25 Aug '12

25 Aug '12

Hi, The following code fails to compile for me: #include <memory> #include <boost/iterator/transform_iterator.hpp> std::unique_ptr<int> foo(int i) { return std::unique_ptr<int>(new int(i)); } int main() { int a[5] = {1, 2, 3, 4, 5}; auto it = boost::make_transform_iterator(a, foo); } The error message I get with GCC 4.8 is pasted below. I think this should work because returning a move-only type from a function by value is a perfectly valid thing to do. Do you agree? Should I file a bug? Thanks, Nate In file included from boost/iterator/iterator_categories.hpp:20:0, from boost/iterator/iterator_adaptor.hpp:14, from boost/iterator/transform_iterator.hpp:12, from test.cpp:2: boost/type_traits/is_convertible.hpp: In instantiation of 'const bool boost::detail::is_convertible_basic_impl<std::unique_ptr<int>&, std::unique_ptr<int> >::value': boost/type_traits/is_convertible.hpp:296:5: required from 'const bool boost::detail::is_convertible_impl<std::unique_ptr<int>, std::unique_ptr<int> >::value' boost/type_traits/is_convertible.hpp:419:1: required from 'struct boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >' boost/mpl/aux_/nested_type_wknd.hpp:26:31: required from 'struct boost::mpl::aux::nested_type_wknd<boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> > >' boost/mpl/aux_/preprocessed/gcc/and.hpp:23:8: required from 'struct boost::mpl::aux::and_impl<true, boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >' boost/mpl/aux_/preprocessed/gcc/and.hpp:48:8: required from 'struct boost::mpl::and_<boost::is_convertible<boost::random_access_traversal_tag, boost::single_pass_traversal_tag>, boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >' boost/mpl/if.hpp:67:11: [ skipping 6 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] boost/iterator/detail/facade_iterator_category.hpp:187:8: required from 'struct boost::detail::facade_iterator_category<boost::random_access_traversal_tag, std::unique_ptr<int>, std::unique_ptr<int> >' boost/iterator/iterator_facade.hpp:104:17: required from 'struct boost::detail::iterator_facade_types<std::unique_ptr<int>, boost::random_access_traversal_tag, std::unique_ptr<int>, long int>' boost/iterator/iterator_facade.hpp:621:9: required from 'class boost::iterator_facade<boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>, std::unique_ptr<int>, boost::random_access_traversal_tag, std::unique_ptr<int>, long int>' boost/iterator/iterator_adaptor.hpp:261:9: required from 'class boost::iterator_adaptor<boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>, int*, std::unique_ptr<int>, boost::use_default, std::unique_ptr<int>, boost::use_default>' boost/iterator/transform_iterator.hpp:74:9: required from 'class boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>' test.cpp:12:52: required from here boost/type_traits/is_convertible.hpp:136:23: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = int; _Dp = std::default_delete<int>]' static bool const value = sizeof( boost::detail::checker<To>::_m_check(_m_from, 0) ) ^ In file included from c++/4.8.0/memory:81:0, from test.cpp:1: c++/4.8.0/bits/unique_ptr.h:259:7: error: declared here unique_ptr(const unique_ptr&) = delete; ^ In file included from boost/iterator/iterator_categories.hpp:20:0, from boost/iterator/iterator_adaptor.hpp:14, from boost/iterator/transform_iterator.hpp:12, from test.cpp:2: boost/type_traits/is_convertible.hpp:129:41: error: initializing argument 1 of 'static boost::type_traits::yes_type boost::detail::checker<T>::_m_check(T, int) [with T = std::unique_ptr<int>; boost::type_traits::yes_type = char]' static boost::type_traits::yes_type _m_check(T, int); ^

2 2

[tools/regression + filesystem] compiler error
by Jeffrey Lee Hellrung, Jr. 25 Aug '12

25 Aug '12

I was trying to build the boost tools (v1.51.0) and ran into the error pasted below. Should this be concerning? - Jeff Performing configuration checks - has_icu builds : no ...patience... ...patience... ...found 2720 targets... ...updating 3 targets... compile-c-c++ ..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj library_status.cpp regression\src\library_status.cpp(633) : error C2440: 'initializing' : cannot convert from 'const boost::filesystem::path::string_type' to 'std::basic_string<_Elem,_Traits,_Ax>' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] No constructor could take the source type, or constructor overload resolution was ambiguous regression\src\library_status.cpp(761) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::append(const std::basic_string<_Elem,_Traits,_Ax> &)' : cannot convert parameter 1 from 'const boost::filesystem::path::string_type' to 'const std::basic_string<_Elem,_Traits,_Ax> &' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Reason: cannot convert from 'const boost::filesystem::path::string_type' to 'const std::basic_string<_Elem,_Traits,_Ax>' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called ..\boost/test/impl/execution_monitor.ipp(948) : warning C4535: calling _set_se_translator() requires /EHa regression\src\library_status.cpp(899) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const boost::filesystem::path::string_type' (or there is no acceptable conversion) c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(914): could be 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(const std::basic_string<_Elem,_Traits,_Ax> &)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(919): or 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(const _Elem *)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(924): or 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(_Elem)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] while trying to match the argument list '(std::string, const boost::filesystem::path::string_type)' call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj.rsp" ...failed compile-c-c++ ..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj... ...skipped <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.exe for lack of <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.obj... ...skipped <p..\dist\bin>library_status.exe for lack of <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.exe... ...failed updating 1 target... ...skipped 2 targets...

1 0

[phoenix] Help needed with a custom terminal
by Andrey Semashev 25 Aug '12

25 Aug '12

Hi, I'm trying to define a custom terminal that acts as a replacement of operator<< in expressions when the right argument of the operator is of my special type. The terminal aggregates its left subexpression which results in reference to a stream, and result type of the terminal is the same reference. In short, it looks like this: namespace my { struct argument { std::string m_value; explicit argument(std::string const& value); }; template< typename LeftT > class output_terminal { public: typedef void _is_my_terminal; //! Self type typedef output_terminal this_type; //! Result type definition template< typename > struct result; template< typename ContextT > struct result< this_type(ContextT) > { typedef typename remove_cv< typename remove_reference< ContextT >::type >::type context_type; typedef typename phoenix::evaluator::impl< typename LeftT::proto_base_expr&, context_type, phoenix::unused >::result_type type; }; template< typename ContextT > struct result< const this_type(ContextT) > { typedef typename remove_cv< typename remove_reference< ContextT >::type >::type context_type; typedef typename phoenix::evaluator::impl< typename LeftT::proto_base_expr const&, context_type, phoenix::unused >::result_type type; }; private: //! Left argument actor LeftT m_left; //! Right argument std::string m_right; public: //! Initializing constructor output_terminal(LeftT const& left, std::string const& right); //! Invokation operator template< typename ContextT > typename result< const this_type(ContextT) >::type operator() (ContextT const& ctx) const { typedef typename result< const this_type(ContextT) >::type result_type; result_type strm = phoenix::eval(m_left, ctx); strm << m_right; return strm; } }; template< typename LeftExprT > inline phoenix::actor< output_terminal< phoenix::actor< LeftExprT > > > operator<< (phoenix::actor< LeftExprT > const& left, argument const& right) { phoenix::actor< output_terminal< phoenix::actor< LeftExprT > > > res = { output_terminal< phoenix::actor< LeftExprT > >(left, right.m_value) }; return res; } typedef phoenix::expression::argument< 1 >::type stream_type; const stream_type stream = {}; } // namespace my int main(int, char*[]) { function< void (std::ostream&) > func; func = my::operator<< (my::stream, my::argument("Hello, world!")); func(std::cout); return 0; } I also have specialized phoenix::result_of::is_nullary, phoenix::is_custom_terminal and phoenix::custom_terminal based on the _is_my_terminal tag. The problem is that the code doesn't compile. The compiler output is quite lengthy and it ends in this: ./boost/fusion/adapted/struct/detail/at_impl.hpp:24:16: error: invalid use of incomplete type ‘struct boost::fusion::extension::access::struct_member<boost::phoenix::vector1<const boost::phoenix::actor<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<my::output_terminal<boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1> >, 0l> > > >, 0l> >*>, 1>’ It is not clear where the problem is but I think for some reason Boost.Phoenix thinks that output_terminal is a nullary terminal, despite the fact that I specialized is_nullary to return false. Is there something wrong with my code or is it a problem with Boost.Phoenix? I have posted the complete code here: http://pastebin.com/Vniq1b5Y and here is the compiler output: http://pastebin.com/8Beg4LiY I'm using release SVN branch and GCC 4.6. Thanks in advance.

1 1

[rational] Over/underflow checked update ready for comments
by Dan Searles 25 Aug '12

25 Aug '12

For those interested in rational, there is an updated version in https://svn.boost.org/svn/boost/sandbox/rational ready for comments. Quick overview of the update: the original usage and code of the template class remains mostly as before, ie boost::rational<int> RationalVar; should work as in the original version. Adding 'true' as a second template parameter, however, allows an exception to be raised if an operation with a class variable results in a value that can't accurately be represented, ie boost::rational<int,true> RationalVarChecked. Checking is only needed on limited precision integer types, and it has been tested with signed char, short, int and long long. Thank you for your constructive comments. Dan Searles

2 1

attempting sandbox svg_plot templates
by Roger Martin 25 Aug '12

25 Aug '12

Hi, Thought svg_plot (https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/) is an interesting approach. Trying to stand it up and test it's implementation status. Using gcc 4.7 on Windows 7, Ubuntu 12.04 and CentOS 5. all 64 bit. Run into many template and friend issues. Anybody getting this lib to work? Much coming from https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/boost/svg_pl…. First two: .............. In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:11: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<false>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<false>, boost::svg::unc<false> >&)’ does not match any template declaration .............. for the code: .............. friend std::ostream& operator<< <> (std::ostream& os, const unc<correlated>& u); /*! Output a pair of (X and Y) values with (if defined) uncertainty and degrees of freedom. \details For example: "1.23 +/- 0.01 (13), 3.45 +/- 0.06 (78)". */ friend std::ostream& operator<< <> (std::ostream& os, const std::pair<unc, unc>& u); ............... Seems to be where std::ostream is being extended or derived from. But I'm not discerning the template error or good at interpreting them. How to learn? Been looking for examples and where the gcc version makes a difference but get too many hits with google. Headers in unit test leading up to the svg_plot headers are: ------------------------ #include <cmath> #include <map> #include <stdio.h> #include <stdlib.h> #include <vector> #include <iostream> #include <ostream> #include "CUnit/Basic.h" #include "boost/array.hpp" #include "boost/svg_plot/svg.hpp" #include "boost/svg_plot/svg_2d_plot.hpp" #include "boost/svg_plot/show_2d_settings.hpp" .............................. -------------- All the errors and warnings: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘class boost::svg::unc<false>’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:11: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<false>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<false>, boost::svg::unc<false> >&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘class boost::svg::unc<true>’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:293:28: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<true>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<true>, boost::svg::unc<true> >&)’ does not match any template declaration In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: error: ‘result_type’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash/detail/hash_float.hpp:16:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash/hash.hpp:15, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash.hpp:6, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/unordered/unordered_map.hpp:21, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/unordered_map.hpp:16, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_unordered_map.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_container.hpp:25, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/svg_tag.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg.hpp:184, from tests/plotting_tests.cpp:20: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/integer/static_log2.hpp:45:45: note: ‘boost::detail::static_log2_impl::result_type’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:40: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:18: warning: ‘typedef’ was ignored in this declaration [enabled by default] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp: In member function ‘std::pair<boost::svg::unc<correlated>, boost::svg::unc<correlated> > boost::svg::detail::pair_unc_2d_convert<correlated>::operator()(T)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:26: error: ‘un’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:39: error: wrong number of template arguments (1, should be 2) In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: error: provided for ‘template<class _T1, class _T2> struct std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:40: error: expected ‘;’ before ‘c’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:40: error: ‘c’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:59: error: expected primary-expression before ‘>’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp: At global scope: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:30:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:112:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:106:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:187:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:207:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:219:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘void boost::svg::scale_axis(const T&, double*, double*, double*, int*, double*, double*, double*, int*, bool, double, bool, double, int, int, bool, double, int, int)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:350:51: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:350:51: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:359:5: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:359:23: error: expected ‘;’ before ‘pos’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:360:9: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:364:25: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:395:5: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:395:23: error: expected ‘;’ before ‘pos’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:396:11: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:401:9: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:7: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:7: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:186: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:186: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘size_t boost::svg::show(const T&)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:666:3: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:666:3: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:8: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:26: error: expected ‘;’ before ‘it’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:50: error: ‘it’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:671:11: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:671:11: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘size_t boost::svg::show(iter, iter)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:684:5: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:684:5: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:687:3: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:687:3: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:688:11: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:688:11: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘std::pair<double, double> boost::svg::range(const T&)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:708:49: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:708:49: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘std::pair<double, double> boost::svg::range_all(const T&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:37: error: ‘numeric_limits’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:37: note: suggested alternatives: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/limits.hpp:19:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/iterator/iterator_concepts.hpp:26, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/concepts.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/algorithm/equal.hpp:14, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/iterator_range_core.hpp:29, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/iterator_range.hpp:13, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_map_adapter.hpp:23, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_map.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_container.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/svg_tag.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg.hpp:184, from tests/plotting_tests.cpp:20: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:52: error: expected primary-expression before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:52: error: expected ‘)’ before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:8: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:26: error: expected ‘;’ before ‘it’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:51: error: ‘it’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:5: error: ‘pair’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:5: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/iter_fold_if.hpp:23:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/find_if.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/find.hpp:17, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/aux_/contains_impl.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/contains.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/policies/policy.hpp:10, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/special_functions/math_fwd.hpp:28, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/special_functions/fpclassify.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/numeric_limits_handling.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/axis_plot_frame.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:34, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/pair.hpp:28:8: note: ‘boost::mpl::pair’ In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:10: error: expected primary-expression before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:10: error: expected ‘;’ before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:724:31: error: ‘mm’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: At global scope: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:73:12: warning: class ‘boost::svg::svg_2d_plot_series’ is implicitly friends with itself [enabled by default] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:45: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:45: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:33: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:33: error: template argument 4 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In constructor ‘boost::svg::svg_2d_plot_series::svg_2d_plot_series(T, T, std::string)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:41: error: ‘temp’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:49: error: an assignment cannot appear in a constant-expression ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:49: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:29: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:163:9: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘int boost::svg::svg_2d_plot_series::values_count()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:319:12: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: At global scope: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2266:95: error: ‘pair_double_2d_convert’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2266:95: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:52:7: note: ‘boost::svg::detail::pair_double_2d_convert’ In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2270:105: error: ‘pair_double_2d_convert’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2270:105: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:52:7: note: ‘boost::svg::detail::pair_double_2d_convert’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_straight_lines(const boost::svg::svg_2d_plot_series&)’: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1621:19: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:48: error: ‘::const_iterator’ has not been declared ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:90: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:37: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:37: error: template argument 4 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1629:34: error: ‘j’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1655:29: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_bezier_lines(const boost::svg::svg_2d_plot_series&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1700:19: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1702:80: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1723:32: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_plot_points()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1788:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1789:31: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_bars()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1929:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1930:31: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_histogram()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2020:86: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2028:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot& boost::svg::svg_2d_plot::y_autoscale(const T&, const T&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2709:9: error: expected ‘)’ before ‘y_include_zero_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const string&, U)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3183:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const T&, const string&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3199:25: error: expected primary-expression before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3200:67: error: missing template arguments before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3201:65: error: missing template arguments before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3204:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const T&, const string&, U)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3215:38: error: ‘container’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3219:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp: In function ‘void boost::svg::outFmtFlags(std::ios_base::fmtflags, std::ostream&, const char*)’: In file included from tests/plotting_tests.cpp:22:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:71:15: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:94:17: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ios:43:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:40, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:564:5: error: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp: In function ‘void boost::svg::show_2d_plot_settings(boost::svg::svg_2d_plot&)’: In file included from tests/plotting_tests.cpp:22:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:195:51: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:61:6: error: initializing argument 1 of ‘void boost::svg::outFmtFlags(std::ios_base::fmtflags, std::ostream&, const char*)’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:307:20: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ios:43:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:40, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:564:5: error: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ [-fpermissive] tests/plotting_tests.cpp: In function ‘void test1()’: tests/plotting_tests.cpp:168:16: error: ‘data1’ was not declared in this scope tests/plotting_tests.cpp:169:16: error: ‘data2’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<correlated>&) [with bool correlated = false; std::ostream = std::basic_ostream<char>]’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:267:73: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:123:10: error: ‘double boost::svg::unc<false>::value_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:237:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:124:9: error: ‘float boost::svg::unc<false>::uncertainty_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:238:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:124:9: error: ‘float boost::svg::unc<false>::uncertainty_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:5: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:127:18: error: ‘short unsigned int boost::svg::unc<false>::deg_free_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:254:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:127:18: error: ‘short unsigned int boost::svg::unc<false>::deg_free_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:256:5: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:135:18: error: ‘short unsigned int boost::svg::unc<false>::types_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:259:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:135:18: error: ‘short unsigned int boost::svg::unc<false>::types_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:261:5: error: within this context gmake[1]: *** [build/Release/GNU-4.7-Linux-x86/tests/tests/plotting_tests.o] Error 1 gmake[1]: Leaving directory `/home/roger/NetBeansProjects/JPRoothaan' gmake: *** [.build-tests-impl] Error 2

4 4

Re: [boost] What to do with platform defining 'null' as preprocessor symbol?
by Stewart, Robert 24 Aug '12

24 Aug '12

Jan Hudec wrote: > > At work we develop, among others, for Bada. The system > library provided is unfortunately somewhat flaky. A tell-tale > sign is, that it's native API headers define lowercase 'null' > as preprocessor symbol expanding to 0. Another one, huh? Did they learn that trick from Microsoft? > Unfortunately boost uses identifier 'null'. [snip] > Would it make sense to rename those identifiers and avoid > that name like boost avoids 'min' and 'max'? Boost doesn't avoid "min" and "max" but encloses them in parentheses to prevent preprocessor expansion. "null" could be treated similarly, though some may prefer to choose a different identifier. (At least there isn't an algorithm named "null"!) You'll need to find all the places where "null" occurs and file Trac tickets to get things fixed. If you supply patches against trunk, they are more likely to be applied. If you can apply the patches and run the tests yourself against several compilers on different platforms, you could send a summary reply to this thread with the Trac issues and the results of your testing. Then, someone might even submit all of your patches in one go. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

11 17

Announce: Boost 1.51 installer for 32/64-bit Windows now available
by John Wiegley 24 Aug '12

24 Aug '12

BoostPro is happy to announce that we now have free 32-bit and 64-bit installers for Windows available for download: http://www.boostpro.com/download This version libraries and/or DLLs for the following compilers: Visual C++ 7.1 (Visual Studio 2003) [32-bit only] Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

Sequence Printer (usually part or all of a container) using type_erasure
by Paul A. Bristow 24 Aug '12

24 Aug '12

With the recent acceptance of type erasure as a Boost library, I have continued experiments with the sequence printer provided as an example by Steven Watanbe. This seems to me to have very general usefulness, providing a way of safely, neatly and painlessly printing the contents of a container of any type. To give a flavour of what can be done, given some items in a container, one can print the whole container: double da[] = {1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12. }; decor_printer line_printer; // Using all decor_printer defaults. line_printer.print(da, std::cout); // "1 2 3 4 5 6 7 8 9 10 11 12" // Prints all on one line, space separator and newline at the end. Instead of providing several printer types (as Steven did), I have concentrated just one printer class decor_printer derived from his abstract printer. But I have added to it several constructor parameters to control the number of columns, the width of the columns, and string to prefix, separate, suffix and final terminator. // Construct a printer for 3 ragged columns, and comma as separator. decor_printer plain_printer(3, 0, "\n", ", ", "\n", "\n"); plain_printer.print(da, std::cout); which outputs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 We can also apply this to std::vector (and all the other STL container types) and a more complex type like quantity<length, measurement<double> > (where there is a measurement value and estimate of its uncertainty (+/-). // Array of Boost.Units quantity with an uncertain type. quantity<length, measurement<double> > q[] = { measurement<double>(45210.0, 1234.0) * meters, measurement<double>(765.3, 2.5) * meters, measurement<double>(12.34, 12.5) * meters, measurement<double>(5.67, 2.5) * meters, measurement<double>(0.789, 2.7e-2) * meters, measurement<double>(7890, 2.5e-2) * meters, measurement<double>(5.78e-4, 2.5e-4) * meters, measurement<double>(765.3, 2.5) * meters, measurement<double>(0.0789, 2.7e-4) * meters, measurement<double>(7890, 2.5e-1) * meters, measurement<double>(5.78e-7, 2.5e-8) * meters, measurement<double>(76.3, 2.5) * meters, measurement<double>(53.8e6, 2.34e5) * meters }; To list this neatly we may need a column width of 25. decor_ printer fancy_printer(4, 25, "\n", ", ", "\n"); // 4 columns, 25 char wide fancy_printer.print(q, std::cout); which outputs: 45.21(+/-1.234) km, 765.3(+/-2.5) m, 12.34(+/-12.5) m, 5.67(+/-2.5) m, 789(+/-27) mm, 7.89(+/-2.5e-005) km, 578(+/-250) um, 765.3(+/-2.5) m, 78.9(+/-0.27) mm, 7.89(+/-0.00025) km, 578(+/-25) nm, 76.3(+/-2.5) m, 53.8(+/-0.234) Mm (Unless the email destroys the layout L ) Note the cool autoprefixing of quantities so the units change from m to km, mm, Mm as appropriate. Finally, the parameter to the printer is a *range*, so *part* of any container can nearly as easily be printed. Does anyone share my enthusiasm for this? Paul PS I have also re-ordered the abstract_printer parameters in the hope of providing std::cout as default, so one can write just line_printer.print(da); // "1 2 3 4 5 6" But so far I can't get it to find the charT and traits parameters, despite providing defaults. Two files attached (and need the sandbox version of type erase library. Can anyone more expert get this to work? --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

[config] NO_USER_DEFINED_LITERALS ?
by Matus Chochlik 24 Aug '12

24 Aug '12

Hello, does Boost.Config provide some macro for the detection of (un)availability of user-defined literals (N2765) ? I could not find any in the docs for 1.51.0 nor by grepping in the boost/config/* files. If not, would there be a big problem adding it (called for example BOOST_NO_USER_DEFINED_LITERALS), please ? Thanks in advance, Best regards, Matus

2 2

Equivalent of "bootstrap.sh --without-libraries" for Modularized and CMake-ified boost
by Julien Woillez 24 Aug '12

24 Aug '12

Dear boost(a)lists.boost.org, I'm trying to use CMake to build boost, using its Modularized and CMake-ified version at: https://github.com/ryppl/boost-zero I need to do the equivalent of --without-libraries=mpi with bootstrap.sh. Any idea if this is possible, and if so how to do it? Regards, -Julien

2 1

[type_erasure]bug:any(, binding<Concept>) can store wrong type
by Larry Evans 23 Aug '12

23 Aug '12

The attached runs OK without any compile or runtime errors. It seems to create a type_uns<1> from a type_uns<0> although there's no type_uns<1> CTOR for that. This sounds like another instance of the bug reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/233101 Is it? -regards, Larry

2 6

[exception] is static only?
by Neal Becker 23 Aug '12

23 Aug '12

Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.

3 5

Boost 1.51.0 released!
by Marshall Clow 22 Aug '12

22 Aug '12

Release 1.51.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Boost.Context, by Oliver Kowalke) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_51_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.51.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

8 18

[1.51] PDF documentation build available
by John Maddock 22 Aug '12

22 Aug '12

The PDF build of the docs for 1.51 is now available from: https://sourceforge.net/projects/boost/files/boost-docs/1.51.0/ John.

1 0

[type_erasure] Review report -- ACCEPTED
by Lorenzo Caminiti 21 Aug '12

21 Aug '12

Hello all, Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost. SUMMARY The library was reviewed from July 18 to August 3, 2012. There were 11 votes to accept the library and 2 votes to accept the library under the condition of some modifications (at the end, these 2 votes were essentially considered as "no" because there was no agreement on implementing all the required modifications). It was noted how the library offers non-intrusive and powerful programming techniques that can be used in place of usual Object Oriented (pure) virtual function interfaces (and with support for some from of virtual "template" functions). The library can also be seen as a generalization of existing Boost libraries like Any, Function, and AnyIterator. The library is accepted "as is", however most reviewers suggested to: 1) Dramatically ease the learning curve of the documentation by providing a motivation section, step-by-step tutorial(s) to introduce the basic features of the library, advanced topics section(s) to introduced the additional features, an example section with non-trivial use cases for the library, and additional examples to the reference section. 2) Support down-casting. While these changes are not a condition for the library acceptance, it would be best if they were made part of the very first release of the library. A few reviewers found the name Type Erasure confusing, however others did not. Alternative name were: Staged Typing, Deferred Typing, Type Interface, Interface, Static Interface, Value Interface, Structural Typing, Duck Typing, and Run-Time Concepts. There was some discussion on the meaning of Type Erasure in Java and on its definition on wiki (these should probably be both referenced in the documentation). The current library name is considered acceptable and the final decision on the library name is left entirely up to Steven. DETAILS "Yes" reviews: [1] http://lists.boost.org/Archives/boost/2012/07/195288.php [2] http://lists.boost.org/Archives/boost/2012/07/195297.php [3] http://lists.boost.org/Archives/boost/2012/07/195299.php [4] http://lists.boost.org/Archives/boost/2012/07/195308.php [5] http://lists.boost.org/Archives/boost/2012/07/195323.php [6] http://www.mentby.com/hossein-haeri/boost-typeerasure-review-ends-today-jul… [7] http://lists.boost.org/Archives/boost/2012/07/195327.php [8] http://lists.boost.org/Archives/boost/2012/07/195329.php [9] http://lists.boost.org/Archives/boost/2012/07/195334.php [10] http://lists.boost.org/Archives/boost/2012/07/195364.php [11] http://lists.boost.org/Archives/boost/2012/08/195420.php "Conditional-yes" reviews (essentially considered as "no"): [12] http://lists.boost.org/Archives/boost/2012/08/195455.php [13] http://lists.boost.org/Archives/boost/2012/08/195561.php Notable comments and discussions (not reviews): (1) http://lists.boost.org/Archives/boost/2012/07/195162.php (2) http://lists.boost.org/Archives/boost/2012/07/195130.php (3) http://lists.boost.org/Archives/boost/2012/07/195149.php (4) http://lists.boost.org/Archives/boost/2012/07/195167.php (5) http://lists.boost.org/Archives/boost/2012/07/195199.php (6) http://lists.boost.org/Archives/boost/2012/07/195200.php (7) http://lists.boost.org/Archives/boost/2012/07/195232.php (8) http://lists.boost.org/Archives/boost/2012/07/195234.php (9) http://lists.boost.org/Archives/boost/2012/07/195408.php (10) http://permalink.gmane.org/gmane.comp.lib.boost.user/75081 (11) http://lists.boost.org/Archives/boost/2012/08/195590.php (12) http://lists.boost.org/Archives/boost/2012/08/195663.php (13) http://lists.boost.org/Archives/boost/2012/07/195342.php (14) http://lists.boost.org/Archives/boost/2012/08/195543.php Note that Steven might have already implemented some of the changes listed below. Features: * Support down-casting. See [1], [10], and (4). * Add macros for defining concepts. These macros could be added in later revisions (they just provide a different syntax, no additional functionality). ** From [10]: BOOST_CREATE_CONCEPT(container_concept, typename T, (void (push_back, T), void (size)) ) ** From Steven: BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...) template<class V, class T = _self> struct container_concept : mpl::vector< has_push_back<void(const V&), T>, has_size<std::size_t(), const T>, ...> {}; * Add empty() to check if any holds a value or not. See [3] and [11]. * Add a built-in concept for unary plus +x (just pick a name for it). See (11). Implementation: * Can assertion enforce that same bindings are required for the placeholders? See [13] and (3). * Add assertion to check that in functions with multiple arguments the underlining any types must match. See (7). * Add in-code comments to the implementation (at least to normalize.hpp). See [8] and [13]. * Can static assertions be used to improve error messages (see [8])? Concept mismatch spew errors with internal implementation details, see [10]. * Fix bugs: ** http://lists.boost.org/Archives/boost/2012/07/195367.php ** http://lists.boost.org/Archives/boost/2012/07/195396.php ** http://lists.boost.org/Archives/boost/2012/08/195662.php Documentation: * A few typos listed in [9]. * A draft on a proposed way to restructure the docs was offered in [8]. * Sean Parent's BoostCon 2012 "Value Semantics" could be used to write a motivation section. See [9]. * Offer a comparison with usual OO (pure) virtual function interfaces. See [1], [7], [8], and [9]. * Make sure all important elements document in the reference section are also documented in a tutorial section (e.g., how the any constructor binds placeholders, conversions, BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and [1]. * Clarify that references can be assigned but they cannot be rebound to a different object. See (2). * Clarify the rationale for using _a, _b, ... instead of _1, _2, ... as soon as _a, _b, ... are first used (most users miss the "named vs. positional parameter" rationale from the design decision section and _1, _2, ... are such common constructs that many users will naturally question the _a, _b, ... choice). See (5). * Add an example section with non-trivial use cases of the library. Consider to add the following examples: ** How to implement visitation, see (8). ** Model view controller, see [1]. ** Run-time expression system (adding Concept = void specialization), see [3]. ** Multi-function, see [4]. ** Printing, see (11) (note that Steven needed to answer too many questions for Paul to be able to program this, ideally the docs would have been clear enough for Paul to program this example without Steven's help). ** Reference related work Adobe::Poly, see (13). * Document all built-in concepts (possibly with a usage example for each) and indicate which ones can be specialized. See [5], and [9]. * Add an example at the bottom of each reference page. See [11]. * Document that any(any<Concpet2, T2>, binding<Concept>) allows to convert the vtable once and re-use it for all anys reducing run-time cost. See [12]. * Consider a number of docs improvements as suggested in [13]. * Document the undefined behaviour pointed out in (12). * Document limitations that some algorithms might encounter if they need to access references and provide rationale of why references cannot be handled differently (i.e., constructor flag and/or overhead of managing vtable in dispatcher layer). See [12], and (14). Many thanks to everyone that participated in the review!! I believe Boost users will find this library useful. The review manager, --Lorenzo On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for > my decision on the library. > > Thank you very much to Steven, everyone that submitted a review, and > everyone that participated in the discussions. > > The review manager, > --Lorenzo > > On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >> Hello all, >> >> *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are >> planning to submit a review, please do so by the end of today. *** >> >> Thank you to all that have participated to the review so far. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> After consulting the review wizards and Steven, I am extending >>> Boost.TypeErasure review of one week, until August 3, 2012. >>> >>> Thank you to all that have submitted a review already and I am looking >>> forward to receiving additional submissions. >>> >>> The review manager, >>> --Lorenzo >>> >>> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>>> >>>> Hello all, >>>> >>>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>>> wrote: >>>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>>> > <lorcaminiti(a)gmail.com> wrote: >>>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>>> > >>>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>>> > :D *** >>>> >>>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>>> planning to submit a review, please do so as soon as possible. *** >>>> >>>> Thank you to everyone who has commented on the library and submitted a >>>> review so far! >>>> >>>> The review manager, >>>> --Lorenzo >>>> P.S. I am considering extending the review until end of day Sunday >>>> July 29, 2012... I will keep you posted. >>>> >>>> > There have been interesting discussions on the library on the ML but I >>>> > have not received any official review yet :( Especially if you are a >>>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>>> > take a look at Type Erasure as it generalizes solutions provided by >>>> > those other libraries. >>>> > >>>> > Thank you. >>>> > >>>> > The review manager. >>>> > --Lorenzo >>>> > >>>> >> THE LIBRARY >>>> >> >>>> >> C++ provides runtime polymorphism through virtual functions. They are >>>> >> a very useful feature, but they do have some limitations. >>>> >> * They are intrusive. In generic programming, we can design an >>>> >> interface which allows third-party types to be adapted to it. >>>> >> * They require dynamic memory management. Of course, most of the >>>> >> problems can be avoided by using an appropriate smart pointer type. >>>> >> Even so, it still acts like a pointer rather than a value. >>>> >> * Virtual functions' ability to apply multiple independent concepts to >>>> >> a single object is limited. >>>> >> The Boost.TypeErasure library solves these problems allowing us to >>>> >> mirror static generic programming at runtime. >>>> >> >>>> >> Library source: >>>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>>> >> >>>> >> Pre-built documentation: >>>> >> >>>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>>> >> >>>> >> You can also download archives with pre-built documentation from: >>>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>>> >> >>>> >> YOUR REVIEW >>>> >> >>>> >> Please submit a review to the mailing-list by replying to this email >>>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>>> >> >>>> >> Please state clearly whether you think this library should be accepted >>>> >> as a Boost library. >>>> >> >>>> >> Other questions you may want to consider: >>>> >> 1. What is your evaluation of the design? >>>> >> 2. What is your evaluation of the implementation? >>>> >> 3. What is your evaluation of the documentation? >>>> >> 4. What is your evaluation of the potential usefulness of the library? >>>> >> 5. Did you try to use the library? With what compiler? Did you have >>>> >> any problems? >>>> >> 6. How much effort did you put into your evaluation? A glance? A >>>> >> quick reading? In-depth study? >>>> >> 7. Are you knowledgeable about the problem domain? >>>> >> >>>> >> Thanks in advance to all who participate in the review discussion -- >>>> >> I'm looking forward to it!

3 2

[fusion] move-enabled containers?
by Gabriel Redner 21 Aug '12

21 Aug '12

Hi folks, I have been starting to ease into C++11, and am currently looking to add move-awareness to some classes which have members of boost::fusion container types. However, it seems that fusion containers are not move-aware. For a minimal example, take the code below: ========== #include <boost/fusion/include/vector.hpp> #include <iostream> class noisy { public: noisy() { std::cout << "noisy()\n"; } noisy(const noisy&) { std::cout << "noisy(const noisy&)\n"; } noisy(noisy&&) { std::cout << "noisy(noisy&&)\n"; } }; int main() { typedef boost::fusion::vector<noisy, noisy> noisyVector; noisyVector n; std::cout << '\n'; noisyVector n2(n); std::cout << '\n'; noisyVector n3(std::move(n)); } ========== I was hoping that the output would be: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(noisy&&) noisy(noisy&&) ========== But instead I get: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) ========== It is a simple matter to add move-awareness to fusion containers, or is there some technical reason why it cannot been done? Or (perhaps more likely), am I misunderstanding something about the situation? Thanks, -Gabe

4 5

Some library dependency and auto liker issues
by Vicente J. Botet Escriba 20 Aug '12

20 Aug '12

Hi, there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix. The problem is related to library dependencies and auto-linker. * 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command bjam toolset=msvc-11.0 --build-type=complete --with-thread doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed). What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command: bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time * 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered? Any suggestions are welcome, Vicente

2 5

Re: [boost] [type_erasure] Review started (July 18-27, 2012)
by Steven Watanabe 20 Aug '12

20 Aug '12

AMDG On 08/02/2012 12:29 PM, Larry Evans wrote: > On 07/18/12 00:13, Lorenzo Caminiti wrote: >> Hello all, >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** > [snip] > Should type_erasure be accepted into Boost? > > Answer: > No, not yet. > Why(in order of importance): > > 1) any<C,T>::any(U&, static_binding<Map>&) bug > > The bug reported here: > http://article.gmane.org/gmane.comp.lib.boost.devel/233101 > should be resolved. > > The bug is just too dangerous for the resolution to be delayed. > I added a static assert. > <snip> > > My review: > > 1. What is your evaluation of the design? > > Good, except for: > > [need variadic static_binding ctor]: > > The any CTOR: > > template<class U, class Map> > any(U & arg, const static_binding< Map > & binding); > > documented here: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > allows only a single argument to the constructor to the > underlying type. I'd suggest adding another CTOR with > interface: > > template<class Map, class... U> > explicit any(const static_binding< Map > & binding, U &&... arg); > > which is similar to: > > explicit any(const binding< Concept > & binding, U &&... arg); > > Then any constructor of the underlying could be used. > I think something like this is reasonable. I have to consider whether this is best approach, though. I don't consider this high priority, however, since the copy constructor should work most of the time. The STL got by just fine for years without emplace. > [too many any ctors]: > > According to `grep -e ' any('`, there are more than 45 any > constructors. That many makes it hard for the novice to know > which one to use. The Design notes: > The solution is simple. Don't use the source. Use the documentation page for any, which only shows 9 distinct constructors. > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > are some help, but those notes also mention ambiguities and > user rules, which sound like indications of usability problems > to me. > > Why wouldn't the following ctors be sufficent to do all the > current any constructors do (except for maybe requiring more > typing and maybe more constructor calls)? > > template > < class... U > > > any > ( static_binding<Map>const& > , U&&... > );//kind=binding constructor > > template > < class... U > > > any > ( binding<Concept>const& > , U&&... > );//kind=dispatching constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& > , static_binding<Map>const& > );//kind=converting constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& u > , binding<Concept2>const&b=binding_of(u) > );//kind=converting constructor > > Providing just these 4 constructors would improve the usabilty. Why? > Of course, I'm probably missing something, and if so, > explaining why the above would not work in the Design notes > would be helpful. > I think it should be obvious what's missing: a) any(const any&); The copy constructor is not a template. b) template<class U> any(const U&); This is the most commonly used constructor besides the copy constructor. It would be very inconvenient if it didn't exist. c) any(); The default constructor creates an empty any. d) A default argument can't refer to a prior argument. Your fourth constructor has to be two separate constructors. > 2. What is your evaluation of the implementation? > > [in-source comments]: > Very few in-source comments, as for example, the in the code: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/boost/type_erasur… > > there are no in-source comments. This lack of in-source comments > made it very hard to understand the implementation. There is also > no tests in the directory: > > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > which contain any string with 'normalize' in it; hence, I assume > there are no unit tests for any class or function with normalize > as part of its name. Such unit tests, hopefully, would have > provided more information of the purpose of the code in > */detail/normalize.hpp; hence, I'd recommend providing such tests > in addition to more in-source comments. > The tests only cover the public interface. I'm not going to add specific tests of the implementation details. > > 3. What is your evaluation of the documentation? > > Mostly good, but some documentation needs improvement. > For example: > > [vague:rebinding_any.html]: > > This doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > Claims rebind_any<Any,T>::type: > > returns any type corresponding to a placeholder. > > However, it doesn't say what the Any in rebind_any<Any,T> may be, > and if one assumes Any is a type_erasure::any<C,S> for some > concept, C, and placeholder, S, then that description makes no > sense because C does not contain any information about which > actual type is matched to which placeholder. Huh? As the documentation you quoted says, rebind_any returns a specialization of /any/. rebind_any<any<C, S>, T>::type is any<C, T>. > <snip> > > from Steven, in the reply: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233067 > > did I finally conclude: > > The placeholders in concepts do *not* stand for the bound types > but instead for the any's containing those bound types. > That depends on the context. boost::type_erasure::call "unwraps" these any's. > Which is similar to the conclusion which I posted here: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233078 > > Since the 233078 post got no replies, I assume that conclusion is > right. If so, then that should be made clear in the > documentation (including tutorials). In addition, the following > example code (and especially the comments), should reduce future > confusion on this topic: > > /* {***any_ctor_kinds.cpp*** */ > <snip> > I find this code almost completely unreadable. > If that conclusion is wrong, then the docs need to be modified > (I've no idea how) to clearly define "matching" as used in the > any.html#id2445089-bb reference. > > [incomplete:tuple.html]: > > The doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > makes no mention of how the binding produced by this call are > generated. > Already fixed. In Christ, Steven Watanabe

10 24

[multiprecision] Some rvalue reference experiments (performance inhancements #1)
by John Maddock 20 Aug '12

20 Aug '12

Folks, I've started to work through some of the points that came up in the multiprecision review, starting with further rvalue reference support. The idea (due to Marc Glisse) was to add operator overloads that look something like: Number&& operator+(Number&&a, const Number& b) { return static_cast<Number&&>(a += b); } Using my Polynomial Horner evaluation scheme as an example the number of temporaries dropped as follows: Type # temporaries No expression templates, no rvalue refs 24 No expression templates, rvalue refs 1 Expression template 0 Which is pretty impressive, but not necessarily typical usage, so by way of "real world" tests, I compared the times taken to evaluate Boost.Math's Bessel function test cases to 50 decimal places: Library Time/s # Allocations MPFR/mpreal (no ET's or rvalue refs) 9.4 13226029 MPFR/mpfr_class (ET's) 6.3 3948316 MPFR/mp_number(ET's) 6.0 2683646 GMP/mp_number(no ET's) 5.2 4186977 GMP/mp_number(ET's) 5.0 2594441 As you can see the number of allocations required when using mp_number with ET's turned off is almost double that without, I guess this is because many statements are similar to: a = b op c; Where a temporary is still required when relying on rvalue refs, but not for expression templates. Having said that the times are getting much closer now.... John.

8 25

Is there any interest in getting pseudo random number generation using preprocessor at compile time into the Preprocessor library?
by Alexander Stoyan 20 Aug '12

20 Aug '12

The complete code, approach and efficiency proofs I described in my blog: http://alexander-stoyan.blogspot.com/2012/07/getting-pseudo-random-numbers-a t.html Need your opinion regarding the relevance and the approach correctness of the feature. Thank you in advance.

4 7

[1.51.0] release candidates available
by Marshall Clow 19 Aug '12

19 Aug '12

Release candidate files for 1.51.0 are available at http://boost.cowic.de/rc/ At this point, the release branch is closed for changes without explicit permission from the release managers. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 6a1f32d902203ac70fbec78af95b3cf8 *boost_1_51_0_rc1.tar.gz 4b6bd483b692fd138aef84ed2c8eb679 *boost_1_51_0_rc1.tar.bz2 ee8112e48088b05c248d68329cd5d908 *boost_1_51_0_rc1.zip e87d3747966ab7e0c9487884326d7d17 *boost_1_51_0_rc1.7z Thanks, --The release managers

5 6

Modularized Boost: How the files in libs/libXX must be included?
by Vicente J. Botet Escriba 19 Aug '12

19 Aug '12

Hi, the following ticket https://svn.boost.org/trac/boost/ticket/7200 report an issue while building Boost.Thread using the modularized cmake. What is the correct way to include the files in lib/libXXX? Best, Vicente

2 1

[type_traits][parameter] Inconsistent boost::is_convertible between gcc and clang
by John Bytheway 19 Aug '12

19 Aug '12

I have been tracking down an issue with some of my code which compiles fine with gcc but not clang. It manifested as a failure in Boost.Parameter but I eventually pinned it down to an inconsistency in the behaviour of boost::is_convertible. The following program demonstrates the issue: ============== #include <boost/type_traits/is_convertible.hpp> #include <boost/static_assert.hpp> class A {}; int main() { BOOST_STATIC_ASSERT((boost::is_convertible<A, A&>::value)); } ============== This compiles fine under g++ (4.7.1), but the assertion fires under clang++ (r160940). This is not too surprising because is_convertible is implemented in completely different ways on the two compilers: - on clang it is in terms of the __is_convertible intrinsic, which behaves like std::is_convertible and fails because rvalue references don't convert to lvalue references. - on gcc it has a complex custom implementation which at some point performs add_reference<> on the first argument and thus determines that the conversion is OK. Reading the docs for boost::is_convertible I think the clang interpretation is closer to the intention, in which case the gcc implementation is wrong, and so is Boost.Parameter (which relies on this behaviour). On the other hand, I suspect there's probably other code out there that depends on this in a similar way to Boost.Parameter, so perhaps it would be safer to tweak the clang implementation instead, and deviate from std::is_convertible. Any thoughts? John Bytheway

5 13

[odeint] Iterator semantics
by Karsten Ahnert 19 Aug '12

19 Aug '12

Hi, we have posted a review request for odeint (a library for solving ordinary differential equations) on this list some days ago. An ODE is dx/dt = f(x(t)) and one is looking for the solution x(t) which is a function of t. Solving ODEs is usually an iterative task, so one starts with x(0) and iteratively applies a solver to obtain a discretized (and approximated) representation of the solution: x(0) -> x(dt) -> x(2*dt) -> x(3*dt) -> ... I played around with an iterator which is doing exactly this iterative procedure. For example, it can be used via odeint::runge_kutta4< state_type > stepper; // ode solver std::array< double , 3 > x = {{ 10.0 , 10.0 , 10.0 }}; // initial state double res = std::accumulate( // parameters : solver , ode , state , time , time_step make_const_step_iterator_begin(stepper, lorenz(), x, 0.0, 0.01) , make_const_step_iterator_end( stepper, lorenz(), x, 1.0, 0.01) , 0.0 , []( double sum, const state_type &x) { return sum + x[0]; } ); The first iterator increments the time until the time of the second iterator is rearched t=0.0 -> t=0.01 -> t=0.02 -> .. t=1.0 and the first component of the solution is accumulated. In principle, this approach works quite well, but there are some problems at least semantically. Maybe someone here has some comments or ideas on this: The defintion of this iterator is: template< class Stepper , class System , class StepperTag > class const_step_iterator : public boost::iterator_facade < const_step_iterator< Stepper , System , StepperTag > , typename Stepper::state_type const , boost::single_pass_traversal_tag > { ... }; It is a single pass iterator, so it can only check for equality of two iterators. This is problematic since equality here means that the time (t) of the begin iterator is smaller then the time of the end iterator. To ensure commutativity of the != or == operation I needed to flag the begin and end iterator explicitly. This is the reason for the two factory functions make_const_step_iterator_begin and make_const_step_iterator_end, which are doing this flagging. The second semantically problem is that the end iterator in principle does not need to know the stepper as well as the system (lorenz() in the above example). But all algorithms from the standard library and Boost.Range assume that the begin and end iterator are of same type. Therefore you have to put the stepper and the system into the end iterator too. Of course, there are techniques like type erasure which might solve this problem, but they introduce some run-time overhead which we want to avoid here. Any ideas or comments about this? P.S. The code can be found in the iterator branch in odeint: boost/numeric/odeint/iterator/const_step_iterator.hpp and some examples libs/numeric/odeint/examples/const_step_iterator.cpp git clone -b iterator git@github.com:headmyshoulder/odeint-v2.git

5 19

Request for a typedef for the larger integer type that supports atomic loads and stores.
by Vicente J. Botet Escriba 18 Aug '12

18 Aug '12

Hi, I'm locking for a portable integer type that is the larger integer type that supports atomic loads and stores. The sig_atomic_t type defined in <csignal> supports atomic loads and stores but I'm not sure is the larger one. Does boost define such a typedef? If not, could such typedef be included in boost and where? Best, Vicente

2 1

What to do with platform defining 'null' as preprocessor symbol?
by Jan Hudec 17 Aug '12

17 Aug '12

Hello Folks, At work we develop, among others, for Bada. The system library provided is unfortunately somewhat flaky. A tell-tale sign is, that it's native API headers define lowercase 'null' as preprocessor symbol expanding to 0. Unfortunately boost uses identifier 'null'. So far we only hit the two cases in boost/test/utils/basic_cstring/basic_cstring.hpp, where I fixed it by renaming the symbols in our local copy of that header, but I noticed there are many more instances in other modules. Would it make sense to rename those identifiers and avoid that name like boost avoids 'min' and 'max'? Or perhaps I could try simply undefining it in config/platform somewhere and see whether Bada headers would break? Unfortunately I don't think gcc has ability to redefine macros temporarily to reinstate the original definition at the end of boost. Generally speaking, Bada provides it's own native API, which is different from anything else. It's object-oriented and looks nice at first sight, but sometimes is inflexible in surprising places. It looks like they wrote whatever they needed to implement applications that ship with the phones and stopped there. The platform also provides ANSI C library and some parts of POSIX, but many functions don't really work. Fortunately the platform is going to be merged with Titzen, so it should at least get working POSIX kernel (Linux) and standard libraries. That makes supporting this obscure platform even less worth big trouble. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

[general] Endianity detection for ARM
by Jan Hudec 17 Aug '12

17 Aug '12

Hello All, Something in Boost.Test started using detail/endian.hpp internally between 1.43 and 1.50. Since at work I build Boost.Test-based tests for several mobile platforms, all of which use ARM, I needed to fix it. It is easy for all platforms built with either gcc or clang (Android, iOS and Bada). Gcc defines __ARMEB__ for big-endian ARM and __ARMEL__ for little-endian ARM. Windows CE is however another issue. Microsoft usually defines rather characteristic _M_<arch> macros, but _M_ARM is *not* defined in Windows CE, though it appears to be defined for Windows 8 ARM (I don't work with those yet). The WinCE projects define ARM and _ARM_, but those may appear on big-endian ARM platforms too. However since there are no big-endian Win32 platforms and they are unlikely to be created, I suggest just hardcoding little endian for anything that defines _WIN32 (the _M_* macros could then possibly be removed, but they don't cause any problems there). I therefore propose this patch: --- a/boost/detail/endian.hpp +++ b/boost/detail/endian.hpp @@ -57,7 +57,7 @@ || defined(_POWER) || defined(__powerpc__) \ || defined(__ppc__) || defined(__hpux) || defined(__hppa) \ || defined(_MIPSEB) || defined(_POWER) \ - || defined(__s390__) + || defined(__s390__) || defined(__ARMEB__) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(__i386__) || defined(__alpha__) \ @@ -66,7 +66,9 @@ || defined(_M_ALPHA) || defined(__amd64) \ || defined(__amd64__) || defined(_M_AMD64) \ || defined(__x86_64) || defined(__x86_64__) \ - || defined(_M_X64) || defined(__bfin__) + || defined(_M_X64) || defined(__bfin__) \ + || defined(__ARMEL__) \ + || defined(_WIN32) // ARM Windows CE don't define __ARMEL__ nor _M_ARM, but there are no big-endian Windows versions # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234 -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

Boost.Units does not honor setw width?
by Paul A. Bristow 17 Aug '12

17 Aug '12

> -----Original Message----- > From: Paul A. Bristow [mailto:pbristow@hetp.u-net.com] > Sent: Thursday, August 09, 2012 4:44 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] [type_erasure] Review started (July 18-27, 2012) Flushed with success using Steven Watanabe's type_erase for printing columns, I have enjoyed extending it to use a fixed column width. But I have stumbled on a feature of Boost.Units output where Boost.Units does not honor the iostream width fully. This can be seen in this minimal example: std::cout << std::setw(20) << 'm' << std::endl; outputs 19 spaces and 'm', total 20 as expected. quantity<length> ql = 2345.6 * meters; std::cout << std::setw(20) << ql << std::endl; outputs 2345.6 m but the m does not line up with the previous 'm'. There are 14 leading spaces and 5 digits, 1 period and a space and letter m for the unit, a total of 22. The reason is that the first item value() is output using the ios width setting, but the second unit() 'm' (and separating space) is not, as in this line in io.hpp . os << q.value() << ' ' << Unit() I have 'cured' this 'bug' (I suspect it is a feature really) thus in boost/units/io.hpp template<class Char, class Traits, class Unit, class T> inline std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& os, const quantity<Unit, T>& q) { if (units::get_autoprefix(os) == autoprefix_none) { std::streamsize w = os.width(); if (w > 0) { // Need to build a single string with the width specified // (or outputting severally would not honour the width). std::ostringstream oss; oss << q.value() << ' ' << Unit(); os << oss.str(); } else { // No os.width set (so save the time needed to construct an ostringstream?) os << q.value() << ' ' << Unit(); } } This works for no_prefix, giving the expected number of leading spaces. But not for autoprefix - when a similar trick looks to get much more complicated (and when I start to get that 'angels fear to tread' feeling ;-) Of course the jaggedness of the layout becomes clearer both as the units get longer and get auto-prefixes (eg engineering). And there is a similar problem using a User defined Type like the measurement.hpp example in std::ostream& operator<< os << val.value() << "(+/-" << val.uncertainty() << ")"; where the second item is additional to the width, not included in it. 1 But I am not sure if this is wise. Is this a 'feature'? 2 Is this the best way of solving it? 3 Can/how should this be applied to autoprefix? 4 Should submit a ticket for this? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

Review Wizard Status Report for August 2012
by Ronald Garcia 16 Aug '12

16 Aug '12

============================================== Review Wizard Status Report for August 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Type Erasure Reviewed 3. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Contract * Nowide (M) * ODEint * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Steven Watanabe :Download: https://github.com/headmyshoulder/odeint-v2 :Description: 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. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 2

dramatically improved template error messages (was: C++11 decltype/SFINAE puzzler)
by Eric Niebler 16 Aug '12

16 Aug '12

(Andrew, a specific question for you below...) (Moderators: can you see why this msg from Andrew never reached the list (which he cc'ed))? On 8/14/2012 8:39 AM, Andrew Sutton wrote: >> GCC-4.7 gives a similarly terse error message. This, I think, is what >> I've been looking for. > > That's neat. Bravo! I've refined this idea. It now avoids cascading errors by detecting when a sfinae_error is passed as an argument to another function. (For the Haskell-ers out there, that makes it like the Either monad.) You can also get the full backtrace by uncommenting one line of code. IMO, this is now approaching something of real value. My personal experience using this with Proto-11 is that it dramatically improves error messages. I can also easily imagine how this can be used to implement a very nice concept-checking library for C++11 that approximates auto-concepts. Andrew, any thoughts on this? You've done far more work in this space than I have. I'd also like to know *why* this works, and indeed if it's guaranteed to. In particular, is it guaranteed that the virtual what() member of the sfinae_error class is instantiated at the outermost call site and not elsewhere (thereby eliminating the deep template back-trace)? I really just stumbled on this technique by accident, and I don't know how thin the ice is here. Both clang-trunk and gcc-4.7 think it's ok. (I'd also like to apologize to Paul Fultz for spelling his name wrong in an earlier message.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 8

boost::asio and resolve_async
by david.hagood＠gmail.com 16 Aug '12

16 Aug '12

I was looking at needing to do a large number of reverse DNS lookups for a log analysis program I am writing, and wanted to use some form of async lookup to speed the program up (vs. doing each look up in series, at a couple of seconds per lookup). boost::asio and the async_resolve functions looked to be just what I wanted, BUT: I can find no good examples of a simple lookup. By "simple" I mean "given an address, give me the host name(s) associated with that address". All the examples were for a lookup by host name/transport type/port, e.g. host name/tcp/80. In my case I neither need a port # nor even have one - I just want the RDNS for the address. It seems to me the documentation in the boost::asio is a bit light on the various types for resolver queries, endpoint types, and such - and seems to be more focused on TCP and UDP than generic IP. Are there any better examples out there of RDNS using boost::asio?

2 1

[Interest] Value Dispatch
by *smgreened＠obbligato.org 16 Aug '12

16 Aug '12

Hi all, This might be old hat to verteran boosters but I found it nifty. Maybe it could make a small addition to Boost. Inspired by Sean Parent's C++Now! talk and the various articles on cpp-next, I've been playing around with value semantics and C++11. I found an interesting use of pack expansion at stackoverflow and expanded on it in a local project to convert from a traditional inheritance/virtual function model to a more value-centered approach. It turns out that with pack expansion one can implement "virtual functions" without needing inheritance or pointer/reference semantics. One can consider a vrtual function as "just" a compiler-generated switch statement. With that in mind, here's an example: ----------- #include <iostream> /// This is a collection of node kinds. We use it to categorize /// various kinds of objects and dispatch to the correct routine. template<typename T, typename T::kind ...I> class kind_tuple {}; /// This is the "virtual function" dispatch mechanism. It /// statically generates a lookup table of routines, one for each /// kind. template<typename R, typename D, typename T> class dispatcher {}; /// This is the actual dispatch implementation. template<typename R, typename D, typename O, typename O::kind ...I> class dispatcher<R, D, kind_tuple<O, I...>> { private: // Call the "virtual function override" via the provided class-level // dispatcher. template<typename P, typename O::kind K, typename ...Args> static R dispatch_handler(P payload, Args ...args) { return D::template dispatch<K>(payload, args...); } public: // dispatcher is an object that knows which routine in N to call. template<typename P, typename ...Args> static R dispatch(P payload, typename O::kind kind, Args ...args) { using F = R(P, Args...); F *table[] = { dispatch_handler<P, I, Args...> ... }; return table[kind](payload, args...); } }; class vehicle { public: enum kind { Car, Bus, Boat, Train, Airplane }; typedef kind_tuple<vehicle, kind::Car, kind::Bus, kind::Boat, kind::Train, kind::Airplane> kinds; private: class drive_dispatcher { public: template<kind K> static void dispatch(vehicle v) { v.drive_impl<K>(); } }; class turn_dispatcher { public: template<kind K> static bool dispatch(vehicle v, std::string direction) { return v.turn_impl<K>(direction); } }; template<kind K> void drive_impl(void) {} template<kind K> bool turn_impl(std::string direction) { return false; } kind the_kind; public: vehicle(kind k) : the_kind(k) {} void drive(void) { dispatcher<void, drive_dispatcher, kinds>::dispatch(*this, this->the_kind); } // Return whether the turn was successfully completed. bool turn(std::string direction) { return dispatcher<bool, turn_dispatcher, kinds>:: dispatch(*this, this->the_kind, direction); } }; template<> void vehicle::drive_impl<vehicle::Car>(void) { std::cout << "Driving a car!\n"; } template<> void vehicle::drive_impl<vehicle::Bus>(void) { std::cout << "Driving a bus!\n"; } template<> void vehicle::drive_impl<vehicle::Boat>(void) { std::cout << "Driving a boat!\n"; } template<> void vehicle::drive_impl<vehicle::Train>(void) { std::cout << "Driving a train!\n"; } template<> void vehicle::drive_impl<vehicle::Airplane>(void) { std::cout << "Flying an airplane!\n"; } template<> bool vehicle::turn_impl<vehicle::Car>(std::string direction) { std::cout << "Turning a car " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Bus>(std::string direction) { std::cout << "Turning a bus " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Boat>(std::string direction) { std::cout << "Turning a boat " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Train>(std::string direction) { std::cout << "Turning a train " << direction << "?!?\n"; return false; } template<> bool vehicle::turn_impl<vehicle::Airplane>(std::string direction) { std::cout << "Turning an airplane " << direction << "!\n"; return true; } template<typename Iterator> void drive(Iterator start, Iterator end) { for (auto i = start; i != end; ++i) i->drive(); } template<typename Iterator> void turn(Iterator start, Iterator end, std::string direction) { for (auto i = start; i != end; ++i) if (i->turn(direction)) { std::cout << "Successfully turned " << direction << "\n"; } else { std::cout << "Could not turn " << direction << "\n"; } } int main(void) { vehicle rides[] = { vehicle(vehicle::kind::Car), vehicle(vehicle::kind::Bus), vehicle(vehicle::kind::Boat), vehicle(vehicle::kind::Train), vehicle(vehicle::kind::Airplane) }; drive(rides, rides + 5); std::cout << "\n"; turn(rides, rides + 5, "left"); return 0; } ----------- The central idea is the creating of a "virtual function table" via pack expansion. Not only can we keep value semantics and avoid coupling via inheritance, we also get virtual function-like behavior for template functions. Expanding the idea allows us to implement a completely generic GoF visitor without using inheritance at all: ----------- #include <iostream> #include <tuple> /// This is a collection of node kinds. We use it to categorize /// various kinds of objects and dispatch to the correct routine. template<typename T, typename T::kind ...I> class kind_tuple {}; /// This is the "virtual function" dispatch mechanism. It /// statically generates a lookup table of routines, one for each /// kind. template<typename R, typename D, typename T> class dispatcher {}; /// This is the actual dispatch implementation. template<typename R, typename D, typename O, typename O::kind ...I> class dispatcher<R, D, kind_tuple<O, I...>> { private: // Call the "virtual function override" via the provided class-level // dispatcher. template<typename P, typename O::kind K, typename ...Args> static R dispatch_handler(P payload, Args ...args) { return D::template dispatch<K>(payload, args...); } public: // dispatcher is an object that knows which routine in N to call. template<typename P, typename ...Args> static R dispatch(P payload, typename O::kind kind, Args ...args) { using F = R(P, Args...); F *table[] = { dispatch_handler<P, I, Args...> ... }; return table[kind](payload, args...); } }; class vehicle { public: enum kind { Car, Bus, Boat, Train, Airplane }; typedef kind_tuple<vehicle, kind::Car, kind::Bus, kind::Boat, kind::Train, kind::Airplane> kinds; private: kind the_kind; public: vehicle(kind k) : the_kind(k) {} kind get_kind(void) const { return the_kind; } }; // U is to distinguish among different kinds of visitors for the same // object type. template<typename O, typename U, typename R, typename ...Args> class visitor { private: typedef visitor<O, U, R, Args...> This; // This dispatcher expects a single object so wrap the visitor and // the visited object together. typedef std::tuple<This *, O> payload; class visit_dispatcher { public: template<typename O::kind K> static R dispatch(payload object, Args ...args) { return std::get<0>(object)-> template visit_impl<K>(std::get<1>(object), args...); } }; template<typename O::kind K> R visit_impl(O object, Args ...args) {} public: R visit(O object, Args ...args) { return dispatcher<R, visit_dispatcher, typename O::kinds>:: dispatch(std::make_tuple(this, object), object.get_kind(), args...); } }; // Visitor types class Driving {}; class Turning {}; template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Car>(vehicle v) { std::cout << "Driving a car!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Bus>(vehicle v) { std::cout << "Driving a bus!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Boat>(vehicle v) { std::cout << "Driving a boat!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Train>(vehicle v) { std::cout << "Driving a train!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Airplane>(vehicle v) { std::cout << "Flying an airplane!\n"; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Car>(vehicle v, std::string direction) { std::cout << "Turning a car " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Bus>(vehicle v, std::string direction) { std::cout << "Turning a bus " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Boat>(vehicle v, std::string direction) { std::cout << "Turning a boat " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Train>(vehicle v, std::string direction) { std::cout << "Turning a train " << direction << "?!?\n"; return false; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Airplane>(vehicle v, std::string direction) { std::cout << "Turning an airplane " << direction << "!\n"; return true; } template<typename Iterator> void drive(Iterator start, Iterator end) { visitor<vehicle, Driving, void> driver; for (auto i = start; i != end; ++i) driver.visit(*i); } template<typename Iterator> void turn(Iterator start, Iterator end, std::string direction) { visitor<vehicle, Turning, bool, std::string> turer; for (auto i = start; i != end; ++i) if (turer.visit(*i, direction)) { std::cout << "Successfully turned " << direction << "\n"; } else { std::cout << "Could not turn " << direction << "\n"; } } int main(void) { vehicle rides[] = { vehicle(vehicle::kind::Car), vehicle(vehicle::kind::Bus), vehicle(vehicle::kind::Boat), vehicle(vehicle::kind::Train), vehicle(vehicle::kind::Airplane) }; drive(rides, rides + 5); std::cout << "\n"; turn(rides, rides + 5, "left"); return 0; } ----------- Not only is inheritance not required, we only need single dispatch to implement the visitor. Because we don't use inheritance at all for these "virtual functions" and the above visitor we can maintain value semantics throughout any code that uses the above techniques. Of course the code above can be cleaned up and beautified. It's just a quick proof-of-concept. I'm sure someone has already posted about this technique somewhere. Is there any interest in expanding it into a Boost library? -Dave

4 6

[1.51, heap] permission to merge r80039
by Tim Blechmann 16 Aug '12

16 Aug '12

request for release manager: i'd like to merge r80039 to release, as it fixes bug #7233. ok or too late? thanks, tim

4 6

[1.51][hash] Permission to merge.
by Daniel James 15 Aug '12

15 Aug '12

Hello release managers, Please can I merge changeset 80038: https://svn.boost.org/trac/boost/changeset/80038/ The tests have cycled for most major compilers and libraries. I think the only missing one is Visual Age C++ which isn't affected since it doesn't have support for C++11 headers. This fixes a bug when compiled with Intel on windows. thanks, Daniel

3 3

[interprocess, 1.51] basic_managed_shared_memory::flush removed?
by Tim Blechmann 15 Aug '12

15 Aug '12

testing 1.51 beta, i figured out, that basic_managed_shared_memory::flush has been removed. this currently breaks compilation of some of my code. wouldn't it be cleaner to deprecate it for some time and maybe post a warning? also a comment in the release notes, how to port code to 1.51 would be very nice. thanks, tim

2 2

[date_time] warning removal
by Vicente J. Botet Escriba 15 Aug '12

15 Aug '12

Hi, Attached a patch to remove most of the warnings below. Could I commit it? There are 4 warnings I want to check ../../../boost/date_time/period_formatter.hpp:117:47: warning: unused parameter 'separator' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:118:47: warning: unused parameter 'start_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:119:47: warning: unused parameter 'open_end_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:120:47: warning: unused parameter 'closed_end_delim' [-Wunused-parameter] where void delimiter_strings(const string_type& separator, const string_type& start_delim, const string_type& open_end_delim, const string_type& closed_end_delim) { m_period_separator; m_period_start_delimeter; m_open_range_end_delimeter; m_closed_range_end_delimeter; } and private: range_display_options m_range_option; string_type m_period_separator; string_type m_period_start_delimeter; string_type m_open_range_end_delimeter; string_type m_closed_range_end_delimeter; }; Is an assignment missing or it was a typo while trying to avoid the warning? Best, Vicente ../../../boost/date_time/date.hpp:194:55: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date.hpp:195:67: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_duration.hpp:128:57: warning: extra ';' inside a struct [-pedantic] ../../../boost/date_time/date_duration.hpp:138:69: warning: extra ';' inside a struct [-pedantic] ../../../boost/date_time/date_duration.hpp:35:73: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_generators.hpp:37:30: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_generators.hpp:38:39: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:43:32: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:56:45: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:57:48: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_names_put.hpp:233:8: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_names_put.hpp:45:26: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/dst_transition_generators.hpp:21:38: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/custom_time_zone.hpp:46:7: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/custom_time_zone.hpp:47:40: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/local_date_time.hpp:211:31: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/posix_time_zone.hpp:118:39: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/period_formatter.hpp:117:47: warning: unused parameter 'separator' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:118:47: warning: unused parameter 'start_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:119:47: warning: unused parameter 'open_end_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:120:47: warning: unused parameter 'closed_end_delim' [-Wunused-parameter] ../../../boost/date_time/time_duration.hpp:254:57: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:22:77: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:33:45: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:34:48: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:35:64: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:36:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:37:66: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:38:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:39:64: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:40:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_zone_base.hpp:42:24: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_zone_base.hpp:43:33: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/wrapping_int.hpp:37:42: warning: extra ';' inside a class [-pedantic]

2 3

Trac ticket spam.
by Vicente J. Botet Escriba 15 Aug '12

15 Aug '12

Hi, could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/7108? Best, Vicente

1 0

Announce: Boost 1.50 installer for 64-bit Windows now available
by John Wiegley 15 Aug '12

15 Aug '12

BoostPro is happy to announce that we now have a free 64-bit installer for Windows available for download: http://www.boostpro.com/download This version (which is only for 1.50 and onward) installs 64-bit libraries and/or DLLs for the following compilers: Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) There will be no support for Visual C++ 7.1 for 64-bit, at any time. It continues to be supported for the 32-bit installer, however. Enjoy! -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[asio] C++11 conformance problem: tie(this)
by Howard Hinnant 14 Aug '12

14 Aug '12

In three places asio/basic_socket_iostream.hpp does this: tie(this); In C++11 tie(this) has become undefined behavior, due to 27.5.5.3 [basic.ios.members]/p2: basic_ostream<charT,traits>* tie(basic_ostream<charT,traits>* tiestr); Requires: If tiestr is not null, tiestr must not be reachable by traversing the linked list of tied stream objects starting from tiestr->tie(). In libc++ it causes an infinite recursion as the ostream::sentry constructor calls flush on the tied buffer, and flush subsequently constructs a local ostream::sentry object (this is all C++11 required behavior). I could detect tie(this) in libc++ and ignore it (as a conforming extension). However I can not detect cyclic ties in general. My gut feeling is that a noisy error is better than ignoring it because whatever tie(this) is supposed to be accomplishing in asio, it isn't, at least not with C++11-conforming std::libs (ignore or crash seem to be std::lib's two obvious options). I believe the best course of action is to remove the three instances of tie(this) from asio. I do not know if this same issue occurs in other parts of boost. I scanned but didn't catch anything. Howard

1 0

[type_erasure][docs]uniform term for underlying
by Larry Evans 14 Aug '12

14 Aug '12

The doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… uses 3 terms: underlying actual contained to designate, essentially, the same thing, the actual type stored in the any. The docs would be clearer if a uniform term were used, with possibly a link to some glossary where the term was defined. -regards, Larry

1 0

[icl] HTML doc consumes more than 50 MB
by Michel Morin 14 Aug '12

14 Aug '12

The HTML doc in `libs/icl/doc/html/boost/icl` consumes more than 50 MB on my system. This directory contains about 2000 docs and there are many duplicate docs. Joachim, could you improve the situation? Thanks, Michel

3 4

C++11 decltype/SFINAE puzzler
by Eric Niebler 13 Aug '12

13 Aug '12

I'm running into a usability problem with the extended SFINAE rules that could effect best practice for all new C++ libraries. I'm hoping some clever person in the Boost community can help me. I find that in highly generic code, using decltype to define the return type of functions is very handy. Dave A. suggested a RETURNS macro to simplify this idiom: <https://groups.google.com/d/msg/boost-devel-archive/OzJ5Ft3pSnU/b_Ter9bgNqAJ> It's used like this: template<typename T> auto foo( T && t ) RETURNS( some-expression-using-t ); This is great and I use it a lot. Now, imagine you have a library of such functions calling other such functions: function A calls B calls ... calls Y, calls Z, all of which use decltype to declare their return types. Now, the user calls A passing a variable t for which the expression in Z's return type calculation makes no sense. Extended SFINAE kicks in, and Z simply disappears. Since Z has disappeared, the expression in Y's return type makes no sense, so Y disappears, too. And so on up the chain. The end result is that the user is presented with an error like: "no viable function A, template substitution failed." The user is given no information about which function in the chain failed to compile, or why. This is a serious usability problem! So, my question is: what can be done about this? Can we get the benefit of automatic type deduction in return types without causing SFINAE to drop functions from the overload set? Is there another trick we can use to report errors meaningfully when APIs are misused? The only solution I can think of is turn all the free functions in the chain into function objects and then using std::result_of to compute return types for them instead of using decltype directly. That means Dave's (very convenient!) RETURNS macro shouldn't be used, which is a bummer. (I think it also means that we need a noexcept_of template that computes the noexcept of an expression without causing the expression to appear in the function declaration, but that depends on how <http://llvm.org/bugs/show_bug.cgi?id=13286> gets resolved.) All suggestions welcome, -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 19

[hash] test failure with current Intel compiler
by Beman Dawes 13 Aug '12

13 Aug '12

Release branch, using the current Intel compiler on Windows, a couple of filesystem tests are failing on my machine with the message: ..\..\..\boost/functional/hash/detail/container_fwd_0x.hpp(49): error: class template "std::tr1::shared_ptr" may not be redeclared in the current scope template <class> class shared_ptr; These tests are passing for GCC and VC++, but the Intel compiler uses the well regarded EDG front end. --Beman

2 1

[graph] interest in resumable dijkstra?
by Alex Hagen-Zanker 13 Aug '12

13 Aug '12

Dear boost-list, I placed the BGL algorithm of the dijkstra_shortest_path in a class, with the creation and initialization part separate from the main algorithm. This allows interrupting, resetting and resuming the algorithm. Would this be of interest to anybody? The following function call: dijkstra_shortest_path(graph, orig, parameter_pack); is separated into: auto dijkstra = make_dijkstra(graph, parameter_pack); dijkstra.init_from_origin(orig /*, optional_visitor*/); dijkstra.expand(/*optional_visitor*/); The make_dijkstra() function reads all parameters from the parameter_pack including color_map and priority_queue Visitors interrupt the calculation using a do_intterrupt() callback instead of throwing an exception. The function expand() can be called repeatedly, each time with another visitor. The implementation requires C++11, because of auto and lambda's, it also relies on the following patch: https://svn.boost.org/trac/boost/ticket/7130. To see for yourself: http://people.pwf.cam.ac.uk/ahh34/dijkstra_test.zip I am interested to hear your opinion. With kind regards, Alex

5 24

[type_erasure][doc]static_binding doc: no mention of PH to PH use.
by Larry Evans 13 Aug '12

13 Aug '12

The static_binding doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Description Represents a mapping from placeholders to the actual types that they bind to. However, the doc for: template < typename Concept2 , typename Tag2 , typename Map > any ( const any< Concept2, Tag2 > & other , const static_binding< Map > & binding ); here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Requires: [snip] Map must be an MPL map with keys for all the placeholders used by Concept and values for the corresponding placeholders in Concept2. So the static_binding doc should contain something like: Represents a mapping from placeholders to the actual types that they bind to or a mapping from placeholders to placeholders, depending on where static_binding is used. HTH. -regards, Larry

1 0

[1.51.0] Beta 1 release candidates available
by Marshall Clow 12 Aug '12

12 Aug '12

Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z Thanks, --The release managers

10 15

[MPI] Jamfile tweak
by Daniel James 12 Aug '12

12 Aug '12

Hi, I've made a change to the MPI documentation Jamfile. The documentation build was failing on trunk because the same project name was used in 'libs/mpi/build/Jamfile.v2' and 'libs/mpi/doc/Jamfile.v2', so I gave the documentation project a more appropriate name: https://svn.boost.org/trac/boost/changeset/79974/ I'll merge to release once 1.51 is finished. Daniel

1 0

[1.51] Beta build of the PDF docs available
by John Maddock 12 Aug '12

12 Aug '12

A PDF build of the docs for 1.51 beta is now available from https://sourceforge.net/projects/boost/files/boost-docs/1.51.0/ John.

2 4

[fusion] 1.50.0 release broken on c++11
by Steve Lorimer 11 Aug '12

11 Aug '12

Hi folks I know it's been reported before, and has been fixed in trunk, but is there any plan to fix the released version? Reported here: http://boost.2283326.n4.nabble.com/fusion-g-4-6-deque-and-c-0x-compile-erro… Thanks Steve

4 4

[1.51] Context docs contains third party materials?
by John Maddock 11 Aug '12

11 Aug '12

Just noticed that the docs for the new context lib contains a "pdf" folder with a bunch of third-party PDF files, including the complete ISO C standard. Can we really re-distribute these? I would have thought not? Plus they occupy a few Mb of space when they could just be linked to elsewhere? Cheers, John.

2 2

[atomic] boost.atomic library/win32
by Tim Blechmann 10 Aug '12

10 Aug '12

hello helge, the shared library of boost.atomic on msvc is currently not really usable, as it does not export the pool_. atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library. tim [1] http://www.boost.org/development/tests/trunk/developer/lockfree.html

3 4

Cygwin svn client broken. Boost scripts failing as a result
by Beman Dawes 10 Aug '12

10 Aug '12

Failures in the inspection script have been tracked back to a cygwin problem. See http://stackoverflow.com/questions/11007024/cygwin-svn-e200030-sqlite-disk-… I did get a run of the trunk inspect script off this morning, but it may be erratic until this gets straightened out. If you are a cygwin svn user, and svn is working OK, you might want to avoid updating your cygwin installation until cygwin fixes this. --Beman

1 0

Meeting C++ - Full Program + Early Bird
by Jens Weller 10 Aug '12

10 Aug '12

Hi C++ & boost Community, just a short note to those who are interested in C++ conferences: The Schedule of Meeting C++ is online: http://meetingcpp.com/index.php/schedule.html The Keynote "Good C++11 Coding Style" is held by Michael Wong, the focus is on C++11 and boost. Early Bird Tickets are still available for one week until next wednesday! regards, Jens Weller

2 2

[intrusive_ptr] Why are comparison operators not friends?
by Carsten Fuchs 10 Aug '12

10 Aug '12

Hi all, I was just (re-)reading item 46, "Define non-member functions inside templates when type conversions are desired", in Scott Meyers "Effective C++, 3rd edition", and was wondering how and why the comparison operators for intrusive_ptr work when used with NULL, even though they're not friend functions as described in Scott Meyer's item 46. That is, the example program below compiles and links fine both with GCC 4.6 as well as with Visual C++ 2010 -- but how does do the compilers match the == operator, whose right operand is NULL, an int value? If I try to use the exact same templated binary operators like this in my own classes, and want NULL matched to one of the T* or U* operands, then I have to do it with friend functions or else the compilers don't find a match. Why does it work here? Best regards, Carsten #include <boost/intrusive_ptr.hpp> #include <iostream> class CRefCounted { public: CRefCounted() : RefCount(0) {} long RefCount; }; void intrusive_ptr_add_ref(CRefCounted* p) { ++(p->RefCount); } void intrusive_ptr_release(CRefCounted* p) { if (--(p->RefCount) == 0) delete p; } int main() { using namespace boost; intrusive_ptr<CRefCounted> p(new CRefCounted()); // I'd expect the next line of code to fail compilation, because the compiler // cannot find a match for operator == with left operand of type // intrusive_ptr<CRefCounted> and right operand of type int, but they do! if (p == NULL) std::cout << "p == NULL\n"; else std::cout << "p != NULL\n"; }

2 2

Re: [boost] Code question on fusion tag_of.hpp
by Dave Steffen 10 Aug '12

10 Aug '12

Mathias Gaunard wrote: > On 08/08/2012 23:39, Dave Steffen wrote: > > Hi Folks > > > > During a recent bug hunt, we came across the following (Boost 1.49, > > fusion/adapted/std_tuple/tag_of.hpp): > > > > #include <tuple> > > > > namespace std > > { > > template <typename... Elements> > > class tuple; > > } > > > > We find this rather puzzling -- why is this here? As far as we can > > tell, this doesn't do anything. > > It forward declares std::tuple so that it can specialize its traits > for it. > > But it really shouldn't do that, since there is no guarantee this > declaration is compatible with the standard one. Well, first of all, it's not a forward declaration, right? std::tuple is declared in whatever gets included with #include<tuple>, right? So it's not a forward declaration, it's a... what? A backwards declaration? :-) It's redundant at any rate. (Or I'm completely wrong, in which case I'm missing something.) And then, yes, this may or may not be compatible with the real std::tuple (which is what we were looking in to when we found this). -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

3 3

boost 1.50.0 - function_input_iterator issue
by hans ewetz 09 Aug '12

09 Aug '12

In boost v1.50.0 the function_input_iterator constructor performs dereferencing which may prevent creation of an 'end' iterator. Should it not instead dereference in the dereference() function and possibly keep a dirty flag indicating if the current value is valid? Apologies if I have missed any similar posting related to this problem. Hans

2 1

[review] Multiprecision review results
by Jeffrey Lee Hellrung, Jr. 09 Aug '12

09 Aug '12

Summary -------- John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL vote. Details -------- Most reviewers noted that this was a sufficiently good first step toward extended precision arithmetic for inclusion into Boost. I think John and Chris will agree that there remains quite a bit of work left to do, but as one reviewer noted, John has an excellent track record regarding Boost development and Chris has been extremely dedicated during the pre-review development, review process, and post-review development, so I think this bodes well for the library's future. I'm going to highlight what I perceive to be some of the bigger issues raised by various individuals involved with in discussion, but I will share all my notes via Google Docs [1], and of course even further details are available in the mailing list archive. I note that many of the issues raised during the review have already been addressed by John and Chris. Mixed-Type Arithmetic -------- This has come up over and over again, especially in the context of allowing extended precision types within the same "family" to interoperate, which I think is tractable. Removing my review manager hat for a moment, perhaps a tag dispatching system similar to Boost.MPL or Boost.Fusion could be used, where all arithmetic types within the same family have the same tag, and hence only allow mixing types with the same tag. Most types will have a unique tag (which, I don't know, could default precisely to the arithmetic type?), but, e.g., Vicente's family of fixed-precision (and maybe even fixed-point) types would all be identifiable as being in the same family, and a traits class would determine the result types of the various arithmetic operations. Mixed-type arithmetic outside the above scope seems more tricky, but some users seem to still desire this in some form. Actual desired use cases will undoubtedly help here. Naming -------- Several commented on the redundancy of "mp_" prefix for identifiers already residing the boost::mp namespace. Narrowing Conversions -------- cpp_dec_float should round rather than truncate on narrowing conversions. Review manager hat off: I wonder if a radix-2 implementation of an arbitrary precision float should ultimately be prioritized and recommended over the present radix-10 implementation? It sounds like conversions in general should be reviewed, but I'm entirely sure myself where they all stand. If possible, narrowing conversions should be explicit while others (that would guarantee no loss of precision) may be implicit. This would be a departure from C++ builtin types. Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation. Regularization/Normalization of Back-End Behavior via Front-End -------- As Edward pointed out, different back-ends generally have different behavior on some "exceptional" cases, making use of the corresponding front-ends in generic contexts at times cumbersome (specifically when the generic context needs to handle said exceptional cases). A couple examples given were division-by-zero and conversion from a string with invalid characters. It is by no means *necessary* to regularize/normalize *all* such differences, but as many as possible and practical should be identified, considered, and documented. Separation of Data Structures and Algorithms -------- Though requested, John and Steven have maintained that this simply isn't very practical. I've gathered that there are too many special cases that (1) would make implementations a nightmare; and (2) would have be addressed very carefully (i.e., in a likely not-very-readable way) to avoid any performance hits. Since this has come up a few times, maybe something could be said in the documentation about this. Thanks to everyone who submitted reviews and participated in the discussion. Let me know if I left out anything you feel is particularly significant or inaccurate. - Jeff [1] https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g…

7 6

Code question on fusion tag_of.hpp
by Dave Steffen 09 Aug '12

09 Aug '12

Hi Folks During a recent bug hunt, we came across the following (Boost 1.49, fusion/adapted/std_tuple/tag_of.hpp): #include <tuple> namespace std { template <typename... Elements> class tuple; } We find this rather puzzling -- why is this here? As far as we can tell, this doesn't do anything. (Well, it did participate in a long, ugly compiler error about variadic templates, which is why we found it.) What are we missing? Thanks for any insight. -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

2 1

Re: [boost] [review] Multiprecision and uBlas
by John Maddock 09 Aug '12

09 Aug '12

>> Also running the tests for UBLAS with mp_number put in place of >> floats/doubles would be interesting. > > I've added modified versions of uBlas tests 1-7 to the multiprecision lib, > most of the tests pass, but there are two outstanding issues: > > * Test1: I had to disable a couple of tests because they trigger debug > assertons inside the STL. I get the same errors when testing with type > double, so I conclude it's a uBlas issue, not sure why they aren't > triggered in the regular regression tests though... > * Test3: I can't get this to compile, and the error are so inscrutable I > don't know what the issue is, I'd need some help from a uBlas expert to > figure those out. Hold on that was a mistake, test1 does pass, tests 3 and 7 don't compile for reasons I don't understand. I'd need some help from a uBlas expert to figure those out. John.

2 1

[Algorithm] [Range] `is_sorted` is duplicate
by Michel Morin 08 Aug '12

08 Aug '12

Both Boost.Algorithm and Boost.Range have `is_sorted` function. Would it be better to deprecate Boost.Range's `is_sorted`? Also, Both Boost.Algorithm and Boost.Range have `iota` function. (In this case, Boost.Algorithm's `iota` returns void, but Boost.Range's `iota` returns the range.) Regards, Michel

1 0

[context] doesn't build on 32-bit osx
by Luke Elliott 08 Aug '12

08 Aug '12

Hello Oliver There's actually already a ticket on this (https://svn.boost.org/trac/boost/ticket/7110 not from me) but since it's unassigned I thought I'd post here with a few more details. bjam address-model=32 -d+2 Performing configuration checks - x86 : yes Jamfile</Users/macpro/dev/checkouts/boost-trunk/libs/context/build>.gas ../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o as -o "../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o" "../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S" ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:82:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:83:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:84:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:86:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:junk `[.-1b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:90:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:91:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:92:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:101:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:112:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:junk `[.-3b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:116:suffix or operands invalid for `push' darwin.compile.c++ ../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/fcontext.o Applying the 64-bit change from Daniel Larimer on 13th May and adding -arch=i386 to the as flags gets things further: as -o "../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o" "../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S" -arch i386 ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:junk `[.-1b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:junk `[.-3b]' after expression From a quick google, it sounds like _GLOBAL_OFFSET_TABLE is an ELF only thing. I'm now way out of my depth and probably can't really help any further (though happy to try out any fixes). Probably not of much relevance but: sw_vers ProductName: Mac OS X ProductVersion: 10.7.4 BuildVersion: 11E53 as -version Apple Inc version cctools-822, GNU assembler version 1.38 I hope that is of some use! ucontext throws up a deprecated warning so it would be nice to switch to boost.context one day. I've not tried Mountain Lion yet so don't know if they've actually removed ucontext support or if it's still deprecated. Best regards Luke Elliott.

2 3

[1.51][Wave] Last minute commit
by Hartmut Kaiser 07 Aug '12

07 Aug '12

Hey, I would like to ask for permission to commit rev 79783 to the release branch (see attached patch). This fixes a bug introduced only recently and will fix the current regressions (see here: http://tinyurl.com/c44ql68, for instance). The patch is for Wave only and does not touch any of the other Boost libraries. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 4

[review] Multiprecision review (June 8th - 17th, 2012)
by Jeffrey Lee Hellrung, Jr. 07 Aug '12

07 Aug '12

Okay, it's that time. Apologies for not sending a reminder, but there had been a lot of pre-review comments over the last week or so, so I think this has been on at least some people's radar. The original review announcement is given below. On Tue, May 29, 2012 at 2:08 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung(a)gmail.com> wrote: > Hi all, > > The review of the proposed Boost.Multiprecision library authored by John > Maddock and Christopher Kormanyos has been scheduled for > > June 8th - June 17th, 2012 > > and will be managed by myself. > > From the Introduction: > > -------- > "The Multiprecision Library provides *User-defined* integer, rational and > floating-point C++ types which try to emulate as closely as practicable the > C++ built-in types, but provide for more range and precision. Depending > upon the number type, precision may be arbitrarily large (limited only by > available memory), fixed at compile time values, for example 50 decimal > digits, or a variable controlled at run-time by member functions. The types > are expression-template-enabled for better performance than naive > user-defined types." > -------- > > And from the original formal review request from John: > > -------- > Features: > > * Expression template enabled front end. > * Support for Integer, Rational and Floating Point types. > > Supported Integer backends: > > * GMP. > * Libtommath. > * cpp_int. > > cpp_int is an all C++ Boost licensed backend, supports both arbitrary > precision types (with Allocator support), and signed and unsigned fixed > precision types (with no memory allocation). > > There are also some integer specific functions - for Miller Rabin testing, > bit fiddling, random numbers. Plus interoperability with Boost.Rational > (though that loses the expression template frontend). > > Supported Rational Backends: > > * GMP > * libtommath > * cpp_int (as above) > > Supported Floating point backends: > > * GMP > * MPFR > * cpp_dec_float > > cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher > Kormanyos' e_float code (published in TOMS last year). > > All the floating point types, have full std lib support (cos sin exp, pow > etc), as well as full interoperability with Boost.Math. > > There's nothing in principal to prevent extension to complex numbers and > interval arithmetic types (plus any other number types I've forgotten!), > but I've run out of energy for now ;-) > > Code is in the sandbox under /big_number/. > > Docs can be viewed online here: > http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… > -------- > Any review discussion should take place on the developers' list ( boost(a)lists.boost.org) and anyone may submit a formal review, either publicly to the entire list or privately to just myself. As usual, please consider the following questions in your formal review: 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? And, most importantly, please explicitly answer the following question: Do you think the library should be accepted as a Boost library? Lastly, please consider that John and Christopher have compiled a TODO list [1] based on pre-review comments. Feel free to comment on the priority and necessity of such TODO items, and whether any might be show-stoppers or warrant conditional acceptance of the library. Thanks in advance; looking forward to the discussion! - Jeff (& John & Christopher) [1] http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h…

16 67

[type_erasure] Review started (July 18-27, 2012)
by Lorenzo Caminiti 06 Aug '12

06 Aug '12

Hello all, *** The review of Steven Watanabe's proposed Boost.TypeErasure library begins on July 18, 2012 and ends on July 27, 2012. *** THE LIBRARY C++ provides runtime polymorphism through virtual functions. They are a very useful feature, but they do have some limitations. * They are intrusive. In generic programming, we can design an interface which allows third-party types to be adapted to it. * They require dynamic memory management. Of course, most of the problems can be avoided by using an appropriate smart pointer type. Even so, it still acts like a pointer rather than a value. * Virtual functions' ability to apply multiple independent concepts to a single object is limited. The Boost.TypeErasure library solves these problems allowing us to mirror static generic programming at runtime. Library source: http://svn.boost.org/svn/boost/sandbox/type_erasure/ Pre-built documentation: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ You can also download archives with pre-built documentation from: http://sourceforge.net/projects/steven-watanabe.u/files/ YOUR REVIEW Please submit a review to the mailing-list by replying to this email ("[boost] [type_erasure] Review ..." should be in the subject). Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? Thanks in advance to all who participate in the review discussion -- I'm looking forward to it! The review manager. --Lorenzo

12 56

interest in generic cyclic visitor?
by Jan Herrmann 06 Aug '12

06 Aug '12

Hello, I have an implementation of generic cyclic visitor. It is available at https://github.com/janherrmann/visitor . With my implementation it is possible to create non-member, non-friend templates which behave like virtual functions. Additionally it can be used as a base for multimethod implementation. Moreover it can be used to build a extensible type information system. All test cases compile with msvc-10.0 and gcc-mingw-4.6.2. Is there need for such a library? Jan Herrmann

3 5

[multiprecision] Some Performance gains
by John Maddock 05 Aug '12

05 Aug '12

Following the review of the multiprecision lib, I've been experimenting with some of the issues raised, currently focusing on performance improvements. Anyhow, I now have some results for improved *front end* performance, I haven't tried to seriously optimize the cpp_int backend yet (which was one of the criticisms), but for more on that see below. So... by way of measuring front end performance - the "abstraction penalty" if you like I've used a special backend type "arithmetic_backend<A>" where A can be any builtin arithmetic type. For tests I've used Boost.Math's special function test data for floating point types, and Phil Endecott's Delaunay code for integer performance. Win32 VC10 first: Delaunay test: int64_t : 9.45241 mp_number<arithmetic_backend<int64_t>, false> : 9.66815 Bessel Functions Test: Time for Bessel Functions - double = 0.015859 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.0225565 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0376449 seconds Non Central T: Time for Non-central T - double = 0.456739 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.459957 seconds Time for Non-central T - arithmetic_backend<double> = 1.08256 seconds Ubutunu Linux x64, GCC-4.6.1: Delaunay Test: int64_t 2.3969 mp_number<arithmetic_backend<int64_t>, false> 2.38334 Bessel Functions Test: Time for Bessel Functions - double = 0.0224617 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.020384 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0220476 seconds Non central T: Time for Non-central T - double = 0.622985 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.554527 seconds Time for Non-central T - arithmetic_backend<double> = 0.800129 seconds So to all intents and purposes there's now no abstraction penalty at all, except when using expression templates (which should be reserved for heavyweight backends anyway). Notice how the mp_number code is sometimes slightly faster, and sometimes slightly slower than the native type - I've observed that completely trivial changes to the test/measuring code can change this around - I suspect, but can't prove that the abstraction layer changes the decisions made by the compiler's optimizer resulting in somewhat capricious differences between results. With regard to the cpp_int backend, I still have work to do, however things do actually look pretty good on Linux x64 for the Delaunay test: Running calculations for: int64_t, int128_t (this is Phil's 128-bit special-case code) Number of flips = 23892000 Total execution time = 3.28337 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 3.05434 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Time per calculation = 3.02904e-08 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 5.41737 On Win32, I'm still a touch behind Phil's code, however, I haven't written a dedicated NxN->2N multiplication routine (yet): Running calculations for: int64_t, int128_t Number of flips = 23892000 Total execution time = 14.2189 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 24.5114 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Total execution time = 19.741 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 33.5 All the new code is in the sandbox, but I haven't documented any of the changes yet... Regards, John.

3 4

[typeof][implementation]why not use decltype or conditional expr?
by Larry Evans 05 Aug '12

05 Aug '12

Why couldn't the BOOST_TYPEOF macro be defined to simply use the new keyword, decltype, if it's available? I assume the macro, BOOST_HAS_DECLTYPE, indicates whether it is available. And if decltype not available, why couldn't it use the conditional expression method described here: http://www.artima.com/cppsource/foreach2.html I would think that would be simpler and more portable. -regards Larry

5 6

Formal review request: TypeIndex library
by Antony Polukhin 05 Aug '12

05 Aug '12

Hi, I'd like to ask to add Boost.TypeIndex to review queue. Introduction TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Docs: http://apolukhin.github.com/type_index/index.html Git: https://github.com/apolukhin/type_index Sources (zipped): https://github.com/apolukhin/type_index/zipball/master Git contains `patched` folder with TypeIndex'ed (and untested) versions of some existing boost libraries (Boost.Any, Boost.Graph, Boost.Math, Boost.MSM, Boost.PropertyMap, Boost.PropertyTree). Those libraries now do not require RTTI to compile. More libraries could be added to this list. Previous threads (checking interest): * Is there interest in typeid(TYPE).name() like function that does not require RTTI http://lists.boost.org/Archives/boost/2012/05/193491.php * [boost] Is there interest in copyable type_info that does not require RTTI (was: Is there interest in typeid(TYPE).name() like function that does not require RTTI) http://lists.boost.org/Archives/boost/2012/05/193519.php * [boost] [type_index] C++03 implementation in boost? http://lists.boost.org/Archives/boost/2012/07/194627.php P.S.: Additional thanks to Agustín K-ballo Bergé for pointing out and fixing some bugs. P.P.S.: It would be great to schedule review to the end of September. -- Best regards, Antony Polukhin

2 3

[1.51.0] Beta1 release available; release branch open for bug fixes and doc fixes
by Marshall Clow 05 Aug '12

05 Aug '12

The beta releases are available at: http://boost.cowic.de/rc/ They are identical to the rc2 releases. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1.7z The final release is scheduled for Monday, August 20th. The release candidate is scheduled to to be built Thursday, August 16th. That gives us less than two weeks to apply post-beta bug fixes and doc updates. Until August 13th permission is not required to merge bug fixes and documentation updates. Starting August 13th permission of a release manager is required for all merges. As always, New libraries and new features are not allowed during a post-beta period. Thanks, -- The Release Managers

2 1

[type_erasure] Review ended
by Lorenzo Caminiti 04 Aug '12

04 Aug '12

Hello all, The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for my decision on the library. Thank you very much to Steven, everyone that submitted a review, and everyone that participated in the discussions. The review manager, --Lorenzo On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are > planning to submit a review, please do so by the end of today. *** > > Thank you to all that have participated to the review so far. > > The review manager, > --Lorenzo > > On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >> >> Hello all, >> >> After consulting the review wizards and Steven, I am extending >> Boost.TypeErasure review of one week, until August 3, 2012. >> >> Thank you to all that have submitted a review already and I am looking >> forward to receiving additional submissions. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>> wrote: >>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>> > <lorcaminiti(a)gmail.com> wrote: >>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>> > >>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>> > :D *** >>> >>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>> planning to submit a review, please do so as soon as possible. *** >>> >>> Thank you to everyone who has commented on the library and submitted a >>> review so far! >>> >>> The review manager, >>> --Lorenzo >>> P.S. I am considering extending the review until end of day Sunday >>> July 29, 2012... I will keep you posted. >>> >>> > There have been interesting discussions on the library on the ML but I >>> > have not received any official review yet :( Especially if you are a >>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>> > take a look at Type Erasure as it generalizes solutions provided by >>> > those other libraries. >>> > >>> > Thank you. >>> > >>> > The review manager. >>> > --Lorenzo >>> > >>> >> THE LIBRARY >>> >> >>> >> C++ provides runtime polymorphism through virtual functions. They are >>> >> a very useful feature, but they do have some limitations. >>> >> * They are intrusive. In generic programming, we can design an >>> >> interface which allows third-party types to be adapted to it. >>> >> * They require dynamic memory management. Of course, most of the >>> >> problems can be avoided by using an appropriate smart pointer type. >>> >> Even so, it still acts like a pointer rather than a value. >>> >> * Virtual functions' ability to apply multiple independent concepts to >>> >> a single object is limited. >>> >> The Boost.TypeErasure library solves these problems allowing us to >>> >> mirror static generic programming at runtime. >>> >> >>> >> Library source: >>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>> >> >>> >> Pre-built documentation: >>> >> >>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>> >> >>> >> You can also download archives with pre-built documentation from: >>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>> >> >>> >> YOUR REVIEW >>> >> >>> >> Please submit a review to the mailing-list by replying to this email >>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>> >> >>> >> Please state clearly whether you think this library should be accepted >>> >> as a Boost library. >>> >> >>> >> Other questions you may want to consider: >>> >> 1. What is your evaluation of the design? >>> >> 2. What is your evaluation of the implementation? >>> >> 3. What is your evaluation of the documentation? >>> >> 4. What is your evaluation of the potential usefulness of the library? >>> >> 5. Did you try to use the library? With what compiler? Did you have >>> >> any problems? >>> >> 6. How much effort did you put into your evaluation? A glance? A >>> >> quick reading? In-depth study? >>> >> 7. Are you knowledgeable about the problem domain? >>> >> >>> >> Thanks in advance to all who participate in the review discussion -- >>> >> I'm looking forward to it!

1 0

[build] guru needed: static vs dynamic lib conundrum for serialization/filesystem library
by Robert Ramey 04 Aug '12

04 Aug '12

The serialiation library uses the boost.filesystem component in it's tests. On tests which test dlls on windows I'm getting an error: test_dll_exported.cpp ..\..\..\boost\filesystem\config.hpp(69) : fatal error C1189: #error : Must not define both BOOST_FILESYSTEM_DYN_LINK and BOOST_FILESYSTEM_STATIC_LINK call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj.rsp" Which I've traced to the command line "test_dll_exported.cpp" -Fo"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /Wp64 /GB /Op /wd4675 /EHs -Gy -wd4996 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS "-I..\..\.." which is produced by BJAM. The test application creates a DLL which is part of the test. BUT the dll created, as well as the serialization library used have been created with static linking. I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. Never the less, users do this and I want to test it. I believe that the problem resides in some thing in the BJAM files related to filesystem libraries or test but I've been unable to track it down further than the above. Any help would be appreciated. Robert Ramey

3 3

[rational] with optional over/underflow checking
by Dan Searles 04 Aug '12

04 Aug '12

Hello, Would there be any interest in a modified "rational" class template/header that optionally allows for an exception be generated if there is under/overflow during any of the operations? I have been developing such a template, where the new defaulted bool template parameter would generate the class exactly as before to preserve the original stable implementation, and to support unlimited-precision integer where over/underflow would not be possible. Setting the new template parameter to true, however would generate code that adds the over/underflow checking. I have also generated new test driver code (BTW test code referenced by the documentation does not appear to exist, or at least the link is broken). rational.hpp has been around and stable for quite some time, so there may be a desire to keep it unchanged, but its original function (and indeed its original source code) can be maintained through the template system. If such a class were to be included in boost, what would be the best submission method?

3 4

Boost.Atomic on Windows, patch
by Václav Zeman 04 Aug '12

04 Aug '12

Hi. I have noticed that boost/atomic/detail/generic-cas.hpp is directly including Windows.h header. I consider this problematic for WinSock using applications as Windows.h automatically pulls in Winsock.h, the WinSock 1 header. This is problematic because it requires users that want to use WinSock 2 to order their include of WinSock2.h before inclusion of Boost.Atomic. At this point in time anybody serious about sockets on Windows really do not want to use WinSock 1 but version 2 instead. So I suggest the attached patch. -- VZ

4 6

[iterator] Error in documentation
by Gabriel Redner 04 Aug '12

04 Aug '12

In the boost::iterator documentation [1], the synopsis for make_function_input_iterator is missing the second 'state' argument. Specifically, this: template <class Function, class State> typename function_input_iterator<Function, State> make_function_input_iterator(Function & f); should be replaced by: template <class Function, class State> typename function_input_iterator<Function, State> make_function_input_iterator(Function & f, State state); Thanks, -Gabe [1] http://www.boost.org/doc/libs/1_50_0/libs/iterator/doc/function_input_itera…

2 2

[type_erasure] Review ends today Aug 3, 2012
by Lorenzo Caminiti 03 Aug '12

03 Aug '12

Hello all, *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are planning to submit a review, please do so by the end of today. *** Thank you to all that have participated to the review so far. The review manager, --Lorenzo On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: > Hello all, > > After consulting the review wizards and Steven, I am extending > Boost.TypeErasure review of one week, until August 3, 2012. > > Thank you to all that have submitted a review already and I am looking > forward to receiving additional submissions. > > The review manager, > --Lorenzo > On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> > wrote: > >> Hello all, >> >> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >> wrote: >> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti < >> lorcaminiti(a)gmail.com> wrote: >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> >> begins on July 18, 2012 and ends on July 27, 2012. *** >> > >> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >> :D *** >> >> *** Boost.TypeErasure review ends today July 27, 2012. If you are >> planning to submit a review, please do so as soon as possible. *** >> >> Thank you to everyone who has commented on the library and submitted a >> review so far! >> >> The review manager, >> --Lorenzo >> P.S. I am considering extending the review until end of day Sunday >> July 29, 2012... I will keep you posted. >> >> > There have been interesting discussions on the library on the ML but I >> > have not received any official review yet :( Especially if you are a >> > user of Boost Any, Function, and Any Iterator, you definitely want to >> > take a look at Type Erasure as it generalizes solutions provided by >> > those other libraries. >> > >> > Thank you. >> > >> > The review manager. >> > --Lorenzo >> > >> >> THE LIBRARY >> >> >> >> C++ provides runtime polymorphism through virtual functions. They are >> >> a very useful feature, but they do have some limitations. >> >> * They are intrusive. In generic programming, we can design an >> >> interface which allows third-party types to be adapted to it. >> >> * They require dynamic memory management. Of course, most of the >> >> problems can be avoided by using an appropriate smart pointer type. >> >> Even so, it still acts like a pointer rather than a value. >> >> * Virtual functions' ability to apply multiple independent concepts to >> >> a single object is limited. >> >> The Boost.TypeErasure library solves these problems allowing us to >> >> mirror static generic programming at runtime. >> >> >> >> Library source: >> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >> >> >> >> Pre-built documentation: >> >> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >> >> >> >> You can also download archives with pre-built documentation from: >> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >> >> >> >> YOUR REVIEW >> >> >> >> Please submit a review to the mailing-list by replying to this email >> >> ("[boost] [type_erasure] Review ..." should be in the subject). >> >> >> >> Please state clearly whether you think this library should be accepted >> >> as a Boost library. >> >> >> >> Other questions you may want to consider: >> >> 1. What is your evaluation of the design? >> >> 2. What is your evaluation of the implementation? >> >> 3. What is your evaluation of the documentation? >> >> 4. What is your evaluation of the potential usefulness of the library? >> >> 5. Did you try to use the library? With what compiler? Did you have >> >> any problems? >> >> 6. How much effort did you put into your evaluation? A glance? A >> >> quick reading? In-depth study? >> >> 7. Are you knowledgeable about the problem domain? >> >> >> >> Thanks in advance to all who participate in the review discussion -- >> >> I'm looking forward to it! >> >

1 0

1.51.0] Beta 1 release candidate 2 available
by Marshall Clow 03 Aug '12

03 Aug '12

Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1_rc2.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1_rc2.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1_rc2.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1_rc2.7z Thanks to everyone who tried out rc1, and especially Neal Becker, who helped me track down a permissions error in the build process --The release managers

3 4

[forward_declare] Interest Inquiry toward Faster Compile Times
by Daniel Larimer 02 Aug '12

02 Aug '12

I have been increasingly frustrated with how long it takes to compile c++ code. After spending some time in Java and C# I can feel the pain of compile times much sharper than I use to. After seeing that Java and C# were able to achieve some level of generics without requiring 'everything in the header' and knowing that C compiles an order of magnitude faster than c++ I set about to find a way to increase my compile times. One of the common recommendations is to 'forward declare' everything and to use the PIMPL (private implementation pattern). Unfortunately, PIMPL usually implies heap allocation and if you ever want to return-by-value you are stuck including the entire header for the types you use in your header. I started inspecting some of my code and running it through the pre-processor and noticed that almost every source file was in the 50K+ lines of code post-preprocessor and that some files were north of 250K lines of code. This was ridiculously inefficient, especially because I was already using PIMPL everywhere I could and most of these lines were stl + boost. After a little bit of work I was able to abstract vector, boost::exception, iostream, string, threading, and many of the other types that I had been including that resulted in 'code-bloat'. The resultant library was able to reduce my post-preprocessor output to just one or two thousand lines of code (assuming the .cpp itself was 500+ lines). My compile times dropped to sub-second per object file from 10+ seconds (some up to 40 seconds). There are some side effects from doing this, performance in some cases was slightly slower due to one level of indirection, but with with link-time optimization this performance loss was minimized. And any loss of performance was clearly acceptable trade for the gain in development efficiency. In situations were performance really is critical I can choose to include the raw header in individual cpp files, but in most cases that level of 'optimization' is overkill. One of the things I realized doing this work was that often the only reason you need to include a header is because the compiler needs to know the SIZE of the type that you wish to forward declare and nothing else. So our development is slowed entirely due to the lack of a SINGLE NUMBER. So I created a utility that allowed me to 'forward declare' the size of the variable. This allowed me to use return by value and member variables via forward declaration WITHOUT having to resort to heap allocation. It occurred to me that a library that allowed developers to choose a little drop in runtime performance for a dramatic improvement in compile times would be generally useful to the C++ community. I have included an example of the 'technique' and general purpose utility that would allow others to quickly and easily integrate forward declaration of 'value types'. A full up boost submission would probably include pre-wrapped versions of most of the STL and Boost types.

9 24

bjam bug? Strange permission
by Neal Becker 02 Aug '12

02 Aug '12

While tracking down strange directory permissions, I noticed this: find . -name .hg -prune -o -type d $ \! -perm 755 -and \! -perm 775 $ -ls 17315044 4 drwxrw-r-- 3 nbecker nbecker 4096 Aug 2 08:41 ./bin.v2 I assume that dir was created by bjam during the test build, for some reason with strange mode.

3 4

Announce: Boost 1.50 installer for 32-bit Windows now available
by John Wiegley 01 Aug '12

01 Aug '12

With apologies to the community for not finding the time to release Windows installers for 1.48 and 1.49, we now have an installer for 1.50 available for immediate download: http://www.boostpro.com/download The version installs 32-bit libraries and/or DLLs for the following compilers: Visual C++ 8.0 (Visual Studio 2005) Visual C++ 9.0 (Visual Studio 2008) Visual C++ 10.0 (Visual Studio 2010) We are dropping support for Visual C++ 7.1 as of this time, unless someone wishes to contract us to bring it back. Also, although I have prepared a 64-bit installer, I have not yet found a solution for integrating it with the existing installer. If anyone with NSIS scripting experience would be willing to assist me, we'd be happy to provide a free installer which installs both 32-bit and 64-bit Boost libraries for applicable Windows platforms. Enjoy! -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

Re: [boost] [Boost-commit] svn:boost r79832 - trunk/tools/build/v2
by Vladimir Prus 01 Aug '12

01 Aug '12

On 01.08.2012 19:26, jurko.gospodnetic(a)docte.hr wrote: > Author: jurko > Date: 2012-08-01 11:26:26 EDT (Wed, 01 Aug 2012) > New Revision: 79832 > URL: http://svn.boost.org/trac/boost/changeset/79832 > > Log: > Boost Build cleanup - minor stylistic comment changes + better commented the project-config.jam configuration file usage. Jurko, are these reformatting changes really necessary? It sounds like it will just make it harder to update Python port when we get back to it when semester starts in September. Thanks,

1 1

Re: [boost] [Boost-commit] svn:boost r79779 - trunk/tools/build/v2/engine
by Steven Watanabe 01 Aug '12

01 Aug '12

AMDG On 07/28/2012 02:04 AM, jurko.gospodnetic(a)docte.hr wrote: > Author: jurko > Date: 2012-07-28 05:04:41 EDT (Sat, 28 Jul 2012) > New Revision: 79779 > URL: http://svn.boost.org/trac/boost/changeset/79779 > > Log: > Boost Jam version information output cleaned up a bit to make it easier to update it with additional information. /Really/? If you want some kind of key/value feature testing, it doesn't belong under the regular version flag. Please revert this. I just find it ugly. > Text files modified: > trunk/tools/build/v2/engine/jam.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > Modified: trunk/tools/build/v2/engine/jam.c > ============================================================================== > --- trunk/tools/build/v2/engine/jam.c (original) > +++ trunk/tools/build/v2/engine/jam.c 2012-07-28 05:04:41 EDT (Sat, 28 Jul 2012) > @@ -263,6 +263,8 @@ > { > printf( "Boost.Jam " ); > printf( "Version %s. %s.\n", VERSION, OSMINOR ); > + printf( "\n" ); > + printf( "Copyright information:\n" ); > printf( " Copyright 1993-2002 Christopher Seiwald and Perforce " > "Software, Inc.\n" ); > printf( " Copyright 2001 David Turner.\n" ); > In Christ, Steven Watanabe

1 0

[type_erasure] Review ends today July 27, 2012
by Lorenzo Caminiti 01 Aug '12

01 Aug '12

Hello all, On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** > > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews :D *** *** Boost.TypeErasure review ends today July 27, 2012. If you are planning to submit a review, please do so as soon as possible. *** Thank you to everyone who has commented on the library and submitted a review so far! The review manager, --Lorenzo P.S. I am considering extending the review until end of day Sunday July 29, 2012... I will keep you posted. > There have been interesting discussions on the library on the ML but I > have not received any official review yet :( Especially if you are a > user of Boost Any, Function, and Any Iterator, you definitely want to > take a look at Type Erasure as it generalizes solutions provided by > those other libraries. > > Thank you. > > The review manager. > --Lorenzo > >> THE LIBRARY >> >> C++ provides runtime polymorphism through virtual functions. They are >> a very useful feature, but they do have some limitations. >> * They are intrusive. In generic programming, we can design an >> interface which allows third-party types to be adapted to it. >> * They require dynamic memory management. Of course, most of the >> problems can be avoided by using an appropriate smart pointer type. >> Even so, it still acts like a pointer rather than a value. >> * Virtual functions' ability to apply multiple independent concepts to >> a single object is limited. >> The Boost.TypeErasure library solves these problems allowing us to >> mirror static generic programming at runtime. >> >> Library source: >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >> >> Pre-built documentation: >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >> >> You can also download archives with pre-built documentation from: >> http://sourceforge.net/projects/steven-watanabe.u/files/ >> >> YOUR REVIEW >> >> Please submit a review to the mailing-list by replying to this email >> ("[boost] [type_erasure] Review ..." should be in the subject). >> >> Please state clearly whether you think this library should be accepted >> as a Boost library. >> >> Other questions you may want to consider: >> 1. What is your evaluation of the design? >> 2. What is your evaluation of the implementation? >> 3. What is your evaluation of the documentation? >> 4. What is your evaluation of the potential usefulness of the library? >> 5. Did you try to use the library? With what compiler? Did you have >> any problems? >> 6. How much effort did you put into your evaluation? A glance? A >> quick reading? In-depth study? >> 7. Are you knowledgeable about the problem domain? >> >> Thanks in advance to all who participate in the review discussion -- >> I'm looking forward to it!

6 7

interest in generic cyclic visitor
by Jan Herrmann 01 Aug '12

01 Aug '12

Hello, I have an implementation of generic cyclic visitor. It is available at https://github.com/janherrmann/visitor . With my implementation it is possible to create non-member, non-friend templates which behave like virtual functions. Additionally it can be used as a base for multimethod implementation. Moreover it can be used to build a extensible type information system. All test cases compile with msvc-10.0 and gcc-mingw-4.6.2. Is there need for such a library? Jan Herrmann

1 0

Review Request: Endian
by David Stone 01 Aug '12

01 Aug '12

A few months back I posted a proposal for an endian conversion library: http://lists.boost.org/Archives/boost/2012/04/191931.php I believe my library is now in a finished state, and I would like to have it considered for inclusion into Boost. A zip file containing everything can be found here: https://bitbucket.org/davidstone/endian/get/tip.zip or you can just browse the repository here: https://bitbucket.org/davidstone/endian/ The only file that users need to be concerned with is endian.hpp. endian.cpp contains performance + correctness tests, and example.cpp is a very short example program on how to use the library that opens up a file, reads in a number that was written in big-endian format, and prints it to the user's screen in host format. There is no special compiling / linking instructions (people who wish to test the program can simply compile endian.cpp). Included is a SCons script that allows easy compilation with gcc or clang with many warnings + optimizations turned on. My programs all compile cleanly at very high warning levels in these compilers because I know many users compile their own projects at such a setting, and I don't want a library file causing noise. I included the documentation in index.html, but I'm not quite sure on how to correctly format things.

3 2

My take on an allocate_shared_array and make_shared_array implementation
by Glen Fernandes 31 Jul '12

31 Jul '12

Hi all, I've desired an allocate_shared_array for a while (and, looking at some existing threads about the topic, it seems others have also). Recently, while working with a code base that accepted both shared_ptr<T> and shared_array<T> for a sequence of T elements, I decided to write both (for shared_ptr<T> since shared_array<T> does not support allocators). The code for both my make_array<T> and allocate_array<T> initial implementation can be found at: https://github.com/glenfe/glenfern/tree/master/glenfern I was wondering if there is any desire for these (after necessary tweaking, refinement, and testing) to become part of Boost. I'm not certain how useful they are in their current form for people using shared_array<T> that can't switch to shared_ptr<T>. Is there any desire to update shared_array<T> so that it supports custom allocators? In that event, my implementation can then easily be applied to shared_array<T> as well. Alternatively, are there any plans to provide a separate smart pointer type for an array with allocator support? Cheers, Glen

1 0

[block_ptr] Update
by Phil Bouchard 31 Jul '12

31 Jul '12

Hi, It's been more than a year since a completed the block_ptr and it seems as if more recent library are being reviewed first. This would suggest the FIFO of the schedule is not followed. I was just wondering since at the same time the reviewing of block_ptr is cost / beneficial. Regards, -Phil Author of: http://www.fornux.com/ http://www.finitetheory.com/

4 7

Fwd: deep-thought reboot
by DongInn Kim 31 Jul '12

31 Jul '12

Dear all, Can we reboot our NFS server sometime tomorrow? If nobody objects this reboot, I will go ahead to reboot deep-thought at 9am (E.T.) on July 31st, 2012. Date: Tuesday, July 31 2012 Time: - 6:00am-6:10am Pacific US time - 7:00am-7:10am Mountain US time - 8:00am-8:10am Central US time - 9:00am-9:10am Eastern US time - 1:00pm-1:10pm GMT The following services would not be available during the reboot. - NFS $HOME - web sites (e.g., www.open-mpi.org, svn.mpi-forum.org, www.osl.iu.edu/publications, ...) Please let me know if you have any issues or question about the outage. Regards, -- - DongInn --------------------------- CREST System administrator dikim(a)cs.indiana.edu Indiana University Bloomington, IN Begin forwarded message: > From: Rob Henderson <robh(a)indiana.edu> > Subject: deep-thought reboot > Date: July 30, 2012 8:36:41 AM EDT > To: DongInn Kim <dikim(a)osl.iu.edu> > > DongInn, we need to reboot deep-thought in order to get updated raid controller firmware in place and boot to the new kernel. This should be very quick with only a few minutes of downtime. Would there be a good time for us to do this? > > Thanks, > > --Rob

1 1

[type_erasure] Performance
by Julien Nitard 31 Jul '12

31 Jul '12

Hi all, I took time to write a simple benchmark for boost::any. Please find the code attached. It requires C++11. I could only test with g++ because clang 3.0/Ubuntu segfaults on the code. I'd be more than happy to get feedback on whether the tests are relevant. I think the compiler can't impact the result by optimizing away the payloads because there's the virtual call barrier preventing it from doing so. The results are quite good for a library that is not optimized yet. Here are some typical results on my machine (though results may vary slightly on each run): Times are in seconds for 100 million iterations, using -O3 -std=c++0x and no other special flags. * Classic inheritance replacement: Inherited: 0.261134 Erased: 0.260092 Erased + ctor: 0.343596 Erased + ctor 3 concepts: 0.295584 * boost::function replacement: boost::bind: 0.260356 boost::function: 0.469181 std::function: 0.515477 te::any + boost::bind: 0.494241 te::any + lambda: 0.379945 Basically that means that TypeErasure has a cost that's zero or at worse neglectible when compared to normal inheritance. It probably means that those simple use cases can't be optimized since the theoretical performance is achieved. If you create the any object each time, then there's something like a 30% loss. That's against an empty virtual function which means that for non trivial payloads the cost is still low. Good job ! The only thing I can't explain is why creating an any with 3 concepts in an mpl::vector is faster than a single primitive concepts. Any ideas ? Nice as well is that callable<> matches or bests boost::function in the simple cases I have tested (likely to be common thanks to C++ lambdas). Actually, I guess that the results would be even better in "normal" circumstances because the way I wrote the test any has 2 virtual call to perform. I guess that in that case again, optimization is not required before acceptance and release. Regards, Julien

1 0

[multiprecision] Huge testcase datafile in commit r79802
by Lars Viklund 31 Jul '12

31 Jul '12

Hi list. My boost-commit@ mbox made my mail agent go into a nice crawl today when displaying the commit details for r79802. It turns out that it's about 6.3 MiB large, most of which is a massive 100k line test case in sandbox/big_number/libs/multiprecision/performance/delaunay_data.txt Will this behemoth file end up in the real repository in case of library acceptance, and even worse, will it end up in the deployed tarballs? Are there any guidelines on keeping tests neat, or possibly generating performance test data if it's excessively huge? While in the discussion, has there been any thoughts of separating documentation from the tree, and/or having codegen of the source files that are clearly generated (vector200.hpp, etc.) in the build tree? It's very straining on disk space to have multiple Boost trees lying around, particularly if you're working in some kind of homedir environment. Combating-bloat'ly-yours, -- Lars Viklund | zao(a)acc.umu.se

2 2

[type_erasure]suggest tuple doc contain requires clause specifying T... are unique
by Larry Evans 31 Jul '12

31 Jul '12

http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… Specifies that the T... are placeholders; however, it doesn't specify that they be unique; hence, tuple<concept,_a,_a> x(int(0),std::vector<int>(0)); would satisfy the current description but wouldn't be right. Of course no one would intentionally do that; however, if the Tags are calculated in some meta-program, it might happened accidentally. Hence the requires class should also say, "If T... are not unique, no diagnostic occurs", or something similar. The reason I think "no diagnostic occurs" is that I've looked briefly in tuple.hpp, at the: ::boost::type_erasure::cons<Concept, T...> impl; in the class tuple definition and the cons definition, and I don't see any check for duplicates. -regards, Larry

2 3

[preprocessor metaprogramming] tools
by Nathan Ridge 31 Jul '12

31 Jul '12

Hello, I've noticed preprocessor metaprogramming has become more popular of late, both as a means to provide a cleaner alternative interface to a library (e.g. the DEFINE and ADAPT macros in Boost.Fusion or the proposed macro wrappers for Boost.TypeErasure) and as a means to emulate new language features (e.g. Boost.LocalFunction, Boost.Generic, and Boost.Contract). Sadly, IDE support for writing macro metaprograms is fairly poor in comparison to IDE support for writing regular C++ code. I wanted to share with you something I've found very useful for tracing/debugging macro metaprograms: the Eclipse CDT IDE has a "macro stepper" that allows you to step through the expansion of a macro step-by-step from the initial invocation to the final expansion. (This feature can be accessed by using the "Explore Macro Expansion" context menu item on a macro invocation.) I would be curious to hear what tools you have found useful for writing or debugging macro metaprograms. Regards, Nate

7 11

Re: [boost] BlueGo Beta 0.0.1
by Julian Amann 30 Jul '12

30 Jul '12

> How can I get the sources? the sources can be found at https://bitbucket.org/Vertexwahn/bluego Julian

1 0

[date_time] Who is in charge?
by Philippe Vaucher 30 Jul '12

30 Jul '12

According to the tracker, it looks like the last ticket with activity is https://svn.boost.org/trac/boost/ticket/5257 which is 16 months ago. Also, according to the mailing list I see a lot of discussion/patches dieing out of inactivity ("[boost] [date_time] warning removal", "[boost] [Date Time] bug in documentation example (Localization Demonstration)"). I'm not here to point fingers, we all have busy times where we just cannot handle open-source responsabilities anymore, but maybe this lib should be switched to "no active maintainers" to avoid any confusion? Also, and probably I should have begin with this, is there a page that lists who is the maintainer of what lib beside the Trac? I couldn't find any, but I didn't look very hard either. Philippe

11 18

[type_erasure]any(U,static_binding) stores wrong type
by Larry Evans 30 Jul '12

30 Jul '12

When the attached is run, it produces output: ./static_binding.exe std::is_copy_constructible<ph_erasee_type>=0 53:ph_ctor_arg<boost::type_erasure::_a>::CTOR.default:my_instance=0 creating a_fst from a_ctor_arg 64:ph_ctor_arg<boost::type_erasure::_a>::CTOR.copy:my_instance=1:(void*)this=0x66ab50 :*fst_cast=ph_erasee<boost::type_erasure::_a>.my_instance=0:(void*)fst_cast=0x66ab50 dynamic_cast<ph_ctor_arg_type*>(value_base_ptr)=0x66ab50 dynamic_cast<ph_erasee_type*>(value_base_ptr)=0 Indicating that a ph_ctor_arg_type is being stored in a_fst instead of the expected ph_erasee_type. -regards, Larry

2 6

[1.51][thread] Compile errors when chrono is disabled
by Andrey Semashev 29 Jul '12

29 Jul '12

Hi, There is a problem with Boost.Thread on windows, when BOOST_THREAD_USES_CHRONO macro is defined. In win32/basic_timed_mutex.hpp there are references to Boost.Chrono not guarded with this macro, which results in compile errors. Could this be fixed before the 1.51 release? I can apply the change, if permission is granted.

2 5

[offtopic] C++11 useful trick
by Eric Niebler 29 Jul '12

29 Jul '12

I recently ran into a limitation in recursive functions that make use of decltype in trailing return types. I've come up with a work-around that I think is a little non-obvious, so I thought I'd share. The problem came up while trying to implementing something like a variadic back() function. The "obvious" implementation doesn't work: template<typename T> T back(T && t) { return t; } template<typename T, typename ...U> auto back(T && t, U &&... u) -> decltype(::back(static_cast<U &&>(u)...)) // ERROR { return ::back(static_cast<U &&>(u)...); } int main() { int i = ::back(1,2,3); } The problem occurs on the line marked "HERE". Trouble is, the variadic "back" function is not yet in scope until after the return type. However, we'd like to use it when specifying the return type. The solution uses a default function template parameter to make the ::back symbol dependent, thereby deferring it's lookup until phase 2, when the symbol is visible. Check it: struct S { template<typename T> static T back(T && t) { return t; } template<typename T, typename ...U, typename Impl = S> static auto back(T && t, U &&... u) -> decltype(Impl::back(static_cast<U &&>(u)...)) { return Impl::back(static_cast<U &&>(u)...); } }; int main() { int i = S::back(1,2,3); } The trick is the "typename Impl = S" followed by a (now dependent) invocation of Impl::back. Voila. Apologies if this is a known technique, and I'm spamming the list with old news. It's news to me. -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 26

[type_erasure]broken link in any.html#any(const U&, const static_binding&)
by Larry Evans 29 Jul '12

29 Jul '12

The html page fragment: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains a link, CopyConstructible, which sends my browser to: http://steven_watanabe.users.sourceforge.net/trunk/doc/html/CopyConstructib… which is not there. Maybe it should go to: http://www.boost.org/doc/libs/1_50_0/libs/utility/CopyConstructible.html or something similar? Also, why couldn't there be any number of arguments, something like: template<typename Map, class... U> explicit any(const static_binding< Map > & binding, U &&... arg); I think this would then allow any constructor to be used for the contained type. Of course then the requirement would have to be modified to be something like: The underlying type has a constructor accepting arguments, U&... arg. -regards, Larry

1 0

[fusion] typo in documentation
by Steve Lorimer 28 Jul '12

28 Jul '12

In the fusion documents for algorithm pop-back, the example shows usage of pop_back as: assert(___pop_back__(make_vector <http://www.boost.org/doc/libs/1_50_0/libs/fusion/doc/html/fusion/container/…>(1,2,3)) == make_vector <http://www.boost.org/doc/libs/1_50_0/libs/fusion/doc/html/fusion/container/…>(1,2)); this should read: assert(pop_back(make_vector <http://www.boost.org/doc/libs/1_50_0/libs/fusion/doc/html/fusion/container/…>(1,2,3)) == make_vector <http://www.boost.org/doc/libs/1_50_0/libs/fusion/doc/html/fusion/container/…>(1,2)); link: http://www.boost.org/doc/libs/1_50_0/libs/fusion/doc/html/fusion/algorithm/…

1 0

[type_erasure]any(const binding<Concept>&, ...) compile error
by Larry Evans 28 Jul '12

28 Jul '12

The attached, when compiled with with gcc4.8-20120624, produces compile error: ../../../boost/type_erasure/detail/construct.hpp: In instantiation of 'boost::type_erasure::any<Concept, T>::any(const boost::type_erasure::binding<Concept>&, U0&) [with U0 = value<boost::type_erasure::_a>; Concept = boost::mpl::vector<boost::type_erasure::copy_constructible<boost::type_erasure::_a>, boost::type_erasure::copy_constructible<boost::type_erasure::_b> >; T = boost::type_erasure::_a]': binding_of.cpp:71:32: required from here ../../../boost/type_erasure/detail/construct.hpp:99:9: error: invalid use of void expression ) ^ Am I doing something wrong? TIA. -Larry

2 13

[1.51][ICL] Last minute commit
by Joachim Faulhaber 28 Jul '12

28 Jul '12

Hi, unaware of the fact that commits to the release branch need permission this week I did a commit today (Revision 79767). Sorry for that. So I'd like to ask for permission now. In other words, is it possible to not reverse this commit? Thanks, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 4

Re: [boost] [type_erasure] Review
by Thomas Jordan 28 Jul '12

28 Jul '12

Hi, A couple of comments on the documentation (apologies my comments are not in the review template format): 1. The documentation should explain why the library is called 'TypeErasure' (as opposed to something like, e.g., 'Run Time Concepts' (RTC), for example). 2. The documentation needs a section placing the library in the context of 'Related Work', for example Adobe::Poly and related research papers. Some indication of the key differences and similarities would also be useful in this regard. 3. The description of the problem(s) the library addresses - i.e., the motivation for the library - in context of best-practice in 'modern C++', needs to be expanded in the documentation. This could be expedited by pointing to aforementioned outside papers/research on the subject, which already explain things like run-time concepts. 4. The documentation should give some brief glossary and/or include references to technical terms such as 'concept' 5. The documentation could do with some details regarding performance Vs classical OO. 6. The further work mentions support for C++11 rvalue references, what about move emulation for C++03? Cheers, Tom.

1 0

Interest in a tweener library
by Julien Jorge 27 Jul '12

27 Jul '12

Hello, I wrote a C++ library to create tweeners and I'm thinking about porting it to Boost. The purpose of the tweeners is to interpolate the intermediate values between two given values during a time interval. Various easing functions can be applied to control the computation of the intermediate values. The library provides the following functionalities: - Interpolation is done on the value of a given variable or using an user-provided callback function, - The interpolated values are computed using a predefined easing function or any user-provided function respecting the contract, - Several tweeners can easily be executed simultaneously or in a row, The documentation of the library is available at http://libclaw.sourceforge.net/tweeners.html and the source code is available at http://sourceforge.net/projects/libclaw/files/libclaw/1.7.1/ as part of a larger library named Claw (check the claw/tween and claw/code/tween folders) Is there an interest to add this tweener library to Boost and what would be the adaptations to do? Regards, -- Julien Jorge

8 24

Last minute commit
by Joachim Faulhaber 27 Jul '12

27 Jul '12

Hi, unaware of the fact that commits to the release branch need permission this week I did a commit today (Revision 79767). Sorry for that. So I'd like to ask for permission now. In other words, is it possible to not reverse this commit? Thanks, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[type_erasure] Review
by Karsten Ahnert 27 Jul '12

27 Jul '12

Hi, here is my review for Steven Watanabe's TypeErase library. First of all, I want to thank Steven for developing this library. My overall evaluation is that TypeErasue should be accepted as boost library. I did not looked very deeply into all details or the implementation but I tried to solve some problems with the library. So, I only looked at the library from the users perspective. = 1. What is your evaluation of the design? = The design looks clear and concise. I have only two small point: * Why do I need to specify relaxed_match to get a default constructable any? Maybe a empty() function would be nice to check if any holds a value (in case it is default constructable). I think a hint about a default constructable any should be in the tutorial. It is important for users. * Sometimes it is not clear, why some constructors work and others not, at least for me. Details are shown below. = 2. What is your evaluation of the implementation? = I did not looked into the implementation. = 3. What is your evaluation of the documentation? = * The documentation looks good. But I think more real-world examples would be very useful. I also encountered some problems where I could not find a hint how to solve it. For example, consider the case where you need an any (for example in a recursive data structure) to be a member of some other class: struct my_class { private: any_type a; }; What kind of constructor do I need to set up this any properly? I came up to define two constructors: struct my_class { template< class T > my_class( T t ) : a( std::move( t ) ) { } my_class( any_type a_ ) : a( a_ ) { } private: any_type a; }; = 4. What is your evaluation of the potential usefulness of the library? = The library is very useful and can be applied to a large number of problems. The library provides an alternative to classical OOP and can be used in many situations. = 5. Did you try to use the library? With what compiler? Did you have any problems? = I tried with gcc-4.7 and gcc-4.6 without problems. I wrote a test application with some kind of an expression system which can be build at runtime. (Maybe this example would be useful for the docs?) My main any definition is template< class Return , class Context > struct requirements : public mpl::vector< te::copy_constructible<> , te::typeid_<> , te::callable< Return( Context ) > , te::relaxed_match > { }; // ... template< class Return , class Context > using expr = te::any< requirements< Return , Context > > ; template< class Context > using boolean_expr = expr< bool , Context >; Then you can build base classes for unary and binary expressions which model the expr concept and contain the subexpression, for example: template< class Return , class Context > class unary_expr { public: typedef expr< Return , Context > expr_type; template< class T > unary_expr( T child ) : m_child( std::move( child ) ) { } unary_expr( expr_type child ) : m_child( child ) { } expr_type& child( void ) { return m_child; } const expr_type& child( void ) const { return m_child; } protected: expr_type m_child; }; At this point I needed some time to figure out that you need at least these two overloads of the constructor. Actually I am not sure if these two overloads are sufficient for all use cases. Some clarification in the docs or any hints would be very useful here. Having the base classes it is very easy to implement concrete expressions, for example: // Boolean expressions struct true_ { template< class Context > bool operator()( Context ) const { return true; } }; struct false_ { template< class Context > bool operator()( Context ) const { return false; } }; template< class Context > class not_ : struct unary_expr< bool , Context > { template< class T > not_( T child ) : unary_expr< bool , Context >( child ) { } bool operator()( Context c ) { return ! this->m_child( c ); } }; This works quite nice, but I always had problems to figure out how the any type are constructed, for example using expr_type = boolean_expr< void >; using not_ = not_< void >; using and_ = and_< void >; using or_ = or_< void >; true_ t; false_ f; // why does this not work? // expr_type e3( not_( f ) ); // cout << e3() << endl; // why does this work? expr_type e4( and_( t , or_( f , t ) ) ); cout << e4() << endl; The first example expr_type e3( not_( f ) ) does not compile. It fails because not_( f ) is interpreted as a function pointer: rule_engine.cpp:35:16: error: too few arguments to function ‘expr_type e3(not_)’ rule_engine.cpp:34:15: note: declared here I have no idea why the second one compiles. = 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? = I spend about 10 hours with studying the library. = 7. Are you knowledgeable about the problem domain? = Some experience in boost.any, boost.function and a self written type erasure application. Not too much. Thank you again! Karsten

2 2

[1.51.0] Release branch closed except by permission, beta next week
by Daniel James 27 Jul '12

27 Jul '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 me and I'll add them for you. The release notes are linked from the main page soon after the beta is released, so it would be complete by then. You can see the work in progress at: http://www.boost.org/users/history/version_1_51_0.html Finally, remember that the release notes are being compiled on the live site now, not the beta site. thanks, Daniel

5 5

[graph] fails to complile on Cygwin
by Bernd Prager 27 Jul '12

27 Jul '12

Hi, I'm having trouble compiling Boost 1.51 on Cygwin 1.7.15, g++ (GCC) 4.5.3. It fails with: gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/read_graphviz_new.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from libs\graph\src\read_graphviz_new.cpp:50: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\threading-multi\read_graphviz_new.o" "libs\graph\src\read_graphviz_new.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/read_graphviz_new.o... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/graphml.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from ./boost/graph/graphml.hpp:20, from libs\graph\src\graphml.cpp:17: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\threading-multi\graphml.o" "libs\graph\src\graphml.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/graphml.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>cygboost_graph.dll for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>read_graphviz_new.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>libboost_graph.dll.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>read_graphviz_new.o... ...skipped <p/usr/local/bin>cygboost_graph.dll for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>cygboost_graph.dll... ...skipped <p/usr/local/lib>libboost_graph.dll.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>libboost_graph.dll.a... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/read_graphviz_new.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from libs\graph\src\read_graphviz_new.cpp:50: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\link-static\threading-multi\read_graphviz_new.o" "libs\graph\src\read_graphviz_new.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/read_graphviz_new.o... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/graphml.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from ./boost/graph/graphml.hpp:20, from libs\graph\src\graphml.cpp:17: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\link-static\threading-multi\graphml.o" "libs\graph\src\graphml.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/graphml.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a(clean) for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>read_graphviz_new.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>read_graphviz_new.o... ...skipped <p/usr/local/lib>libboost_graph.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a...

3 3

Building Boost 1.4.4 with mpi enabled.
by Mike Van Duzee 26 Jul '12

26 Jul '12

I am having issues building boost with mpi enabled. (Windows 7 64bit, Visual Studio 2008) - OpenMPI 1.6 was downloaded and compiled at C:\\openmpi - The following has been added to my user-config.jam: using mpi : mpicxx : <include>C:\\openmpi \\installed\\include <library-path>C:\\openmpi )\\installed\\lib : C:\\openmpi \\installed\\bin\\mpirun ; - The '--with-mpi' flag has been added to the call to bjam.exe. When I build I boost I get a number of unresolved external symbols: packed_skeleton_iarchive.obj : error LNK2001: unresolved external symbol ompi_mpi_byte packed_skeleton_oarchive.obj : error LNK2001: unresolved external symbol ompi_mpi_byte point_to_point.obj : error LNK2001: unresolved external symbol ompi_mpi_byte request.obj : error LNK2001: unresolved external symbol ompi_mpi_byte ... request.obj : error LNK2001: unresolved external symbol ompi_request_null mpi_datatype_cache.obj : error LNK2001: unresolved external symbol ompi_mpi_datatype_null bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll : fatal error LNK1120: 15 unresolved externals After looking at the call to link I can see that it is not linking to any of the Open MPI libs: link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X64 /subsystem:console /out:"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll" /IMPLIB:"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.lib" /LIBPATH:"d:\thirdparty\msvc2008\x64\OPENMPI\1.6\installed\lib" @"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll.rsp" Any help with this would be appreciated, Mike

1 0

[1.51][program_options] Changesets not merged to release
by Andrey Semashev 26 Jul '12

26 Jul '12

Hi, I've noticed that changesets 79280 and 79283 have not been merged to the release branch. The first fixes compilation with STLPort and the second one removes warnings. Both look quite harmless and have been committed to trunk for quite a while. I don't see any regressions in tests caused by these changes. Can these be merged to trunk? I can do the merge, if permitted.

3 3

BlueGo Beta 0.0.1
by Julian Amann 26 Jul '12

26 Jul '12

I build a small tool which builds boost libraries using Visual Studio 2010 x64. It can be downloaded from here: http://vertexwahn.de/ You just have to start the application and click the "Download and Build Boost 1.50.0 with Visual Studio 2010 x64" button - everything else should work automatically. The application downloads the current boost library and builds it. Julian

2 1

[iterators]: collection_keys and collection_values
by Igor Lubashev 26 Jul '12

26 Jul '12

I'd like to propose adding collection_keys and collection_values to iterators library. ======== Motivation ======== I find myself very often having to iterate over all keys or values of a map (or multimap). The best I can do is to use BOOST_FOREACH to iterate over the collection value_type pairs and then work with .first or .second. That makes for awkward and unclear code. BOOST_FOREACH( const foo_bar_map_t::value_type &foo_bar_pair, my_map ) { baz(foo_bar_pair.second); } Instead, I'd like to do something like: BOOST_FOREACH( const bar_t &bar, collection_values(my_map) ) { baz(bar); } BOOST_FOREACH( const foo_t &foo, collection_keys(my_map) ) { baz(foo); } ======== Proposal ======== Add this to iterators library as collection_iterators.hpp Thanks, - Igor #ifndef .... #define .... #include <boost/iterator/transform_iterator.hpp> namespace boost { namespace detail { template<typename CollectionT> struct key_function : public std::unary_function<const typename CollectionT::value_type&, const typename CollectionT::key_type&> { typename key_function::result_type operator()(typename key_function::argument_type p) const { return p.first; } }; template<typename CollectionT> struct value_function : public std::unary_function<const typename CollectionT::value_type&, const typename CollectionT::mapped_type&> { typename value_function::result_type operator()(typename value_function::argument_type p) const { return p.second; } }; template<typename CollectionT, typename AdapterF> class collection_adapter { const CollectionT &c; public: typedef boost::transform_iterator<AdapterF, typename CollectionT::const_iterator> const_iterator; typedef const_iterator iterator; collection_adapter(const CollectionT &c) : c(c) {} const_iterator begin() const { return boost::make_transform_iterator(c.begin(), AdapterF()); } const_iterator end() const { return boost::make_transform_iterator(c.end(), AdapterF()); } }; } // Adapter for map-like collection -> iterable keys collection template<typename CollectionT> const detail::collection_adapter<CollectionT, detail::key_function<CollectionT> > collection_keys(const CollectionT &c) { return detail::collection_adapter<CollectionT, detail::key_function<CollectionT> >(c); } // Adapter for map-like collection -> iterable values collection template<typename CollectionT> const detail::collection_adapter<CollectionT, detail::value_function<CollectionT> > collection_values(const CollectionT &c) { return detail::collection_adapter<CollectionT, detail::value_function<CollectionT> >(c); } } // namespace boost #endif // ....

2 1

website/docs: link broken
by Markus Werle 25 Jul '12

25 Jul '12

Hi! On http://www.boost.org/doc/libs/1_50_0/libs/scope_exit/doc/html/scope_exit/Ge… g_Started.html There is a link to http://www.boost.org/doc/libs/1_50_0/libs/scope_exit/doc/html/scope_exit/Tu… al.html which is broken. Error message is: 404 Not Found File "/home/grafik/www.boost.org/archives/live/boost_1_50_0/libs/scope_exit/doc /html/scope_exit/Tutorial.html" not found. Unable to find file. Markus

1 0

Re: [boost] Macro for BOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or use BOOST_NO_NUMERIC_LIMITS_LOWEST
by Stewart, Robert 24 Jul '12

24 Jul '12

John Maddock wrote: > > >> is there a way to don't include all the deprecated macros? > > Whoa - interesting question. > > I don't know of one. > > > > However, all the deprecated macros are defined (I > > _believe_) in one place, in boost/config/suffix.hpp > > Making it so none of them are defined _should_ be > > straightforward. > > > >Could I suggest to define all of them in a specific > >boost/config/deprecated.hpp file, so that we can add a > >deprecated warning when the file is included. +1 > I think it's too soon for that - as things stand you would > basically be injecting that warning into every Boost header > that includes boost/config.hpp. Aren't there some that have been deprecated for long enough to get that sort of treatment? IOW, create a mechanism for complaining about the use of old names and a policy for how long old names are defined without complaint, how long with complaint, and how long before they are removed. For example, newly renamed macros might be kept in config/suffix.hpp for four releases before moving them to config/deprecated.hpp. Then, names in deprecated.hpp might remain for two releases before removing them altogether. > Besides I don't see what harm defining the old names does? If you can't ever remove the old names, then the set of names that can appear in Boost code grows uncomfortably large. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[TypeErasure]
by Markus Werle 24 Jul '12

24 Jul '12

Hi Steven! I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set? Markus

4 6

[move] Implementing operator= in terms of pass-by-value and swap
by Krzysztof Czainski 24 Jul '12

24 Jul '12

Hello, Implementing the assignment operator (that is, the copy-, move- and other assignments) in terms of pass-by-value and swap is a common idiom [1]. {{{ T operator=( T b ) { swap(*this,b); return *this; } }}} If T is copy-constructible, the above works as a copy-assign. If T is movable, the above works as a move-assign. And for anything convertible to T the above assign will work (right?). Furthermore, this will also work for movable but not copyable classes (right?). It may not be the optimal version of assignment in some cases. In rare cases it might even be incorrect - for types like std::vector, which aren't expected to free reserved memory upon assignment. But assuming swap is a cheap operation, it should be close to optimal in many if not most cases. And in cases, where RVO kicks in, it may be even better than providing separate overloads of operator= for lvalues and rvalues [2]. Boost.Move docs [3] suggest writing the separate overloads of operator=, and in C++03 move emulation the macro BOOST_COPYABLE_AND_MOVABLE(classname) provides a third overload (necessary for the emulation to work in C++03). Should the user choose to write one overload of operator= in the pass-by-value version, he needs to use a different macro, that doesn't provide the additional overload of operator=. I found such a macro: BOOST_COPYABLE_AND_MOVABLE_ALT(classname), but no docs about it. I have the following suggestions, regarding Boost.Move: 1. Providing a macro, BOOST_MOVABLE(classname), that only provides the two needed conversion operators. Or if that is the purpose of BOOST_COPYABLE_AND_MOVABLE_ALT(classname), I couldn't find docs about it. And to avoid a macro entirely, maybe it is possible to provide a CRTP base class 'movable', that would provide these? 2. Now, that there's a separate macro, defining a movable class, it may make sense to add a separate macro for making a class noncopyable. And we already have a base class for that, if one wants to avoid a macro. 3. It would be nice if the docs [3] mentioned something about the alternative of providing only one operator= passing by value. [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Copy-and-swap [2] http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ [3] http://www.boost.org/doc/libs/1_50_0/doc/html/move/implementing_movable_cla… Regards, Kris

1 0

Re: [boost] [type_erasure] [docs]contrast with boost::any
by Larry Evans 23 Jul '12

23 Jul '12

On 07/23/12 15:37, Larry Evans wrote: > On 07/18/12 00:13, Lorenzo Caminiti wrote: >> Hello all, >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** >> > The page: > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > says: > > x is approximately equivalent to a boost::any > > however, it doesn't say how te::any differs from boost::any. > > The attached shows that a boost::any can change it's > type, and, as such, is somewhat like boost::variant. > However, te::any, once it's created, cannot change > it's type, AFAICT. At least that's what the > attached code indicates when compiled with: > > #define SHOW_TE_FIXED_TYPE > A simplified version of that code (which doesn't require demangled_type_name), is attached. The attached also suggests that, when multiple placeholders are in the concept, the unary any *requires* a binding argument. This is shown by trying to compile the attachment with: #define SHOW_BINDINGS_MUST_BE_COMPLETE In contrast, the example here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… shows no binding is needed because the only placeholder in the concept is the default, _self. HTH. -regards, Larry

1 0

[Review Request] array
by Brian Smith 23 Jul '12

23 Jul '12

Hi All, Based on the assumption that, almost no feedback is good feedback, I'd like to submit the array class for review. The requisite files are hosted at, https://github.com/BrianJSmith/Array Comment: The array class is a C++11 compatible implementation of static multidimensional arrays. Kind Regards Brian

5 12

[TypeErasure] Forward constructors and binded types
by Vicente J. Botet Escriba 23 Jul '12

23 Jul '12

Hi,, In the example from the doc typedef mpl::vector< copy_constructible<_a>, copy_constructible<_b>, copy_constructible<_c>, constructible<_a(const _b&, const _c&)> > construct; std::vector<double> vec; int i = 10; double d = 2.5; tuple<construct, _a&, _b, _c> t(vec, i, d); any<construct, _a> v(get<1>(t), get<2>(t)); I don't see which type is constructed and stored in v and how this type is given. That is I don't see how _a is binded. Could you help me? Best, Vicente

9 32

[TypeErasure] BOOST_TYPE_ERASURE_MEMBER
by Julien Nitard 23 Jul '12

23 Jul '12

Hi Steven, all BOOST_TYPE_ERASURE_MEMBER is only mentioned in the reference, it could be useful to add it to the tutorial: I guess that most user concepts will start from member functions of a given type. A sample on how to specialize it for types not having the said member function would be also welcome. Finally, why did you choose not to include the member's signature in the macro ? Isn't this giving the way for hard to find mistakes ? Regards, Julien

2 2

[website] Server problems
by Daniel James 23 Jul '12

23 Jul '12

Hello, As you might have noticed, many of the php based pages were down this morning. The cause appears to be that the directory '/home/grafik/www.boost.org/' didn't have read and execute permissions for all, so php couldn't read a file within it. I fixed it by giving read permission - nothing in that directory is private so I don't think that will be a problem. Hopefully that's okay? I don't like messing round with these things too much, as I don't know the details about the setup. Does anyone have any idea what changed to cause this issue? Maybe an upgrade or configuration change? Could it use group permissions before but can't now for some reason? Or perhaps something accidentally changed the permission on the directory? It'd be useful to understand what happened. Daniel

1 0

[spirit][phoenix] Spirit v2 conflicts with Phoenix v3
by Andrey Semashev 23 Jul '12

23 Jul '12

Hi, Recently I tried to port my code to Boost.Spirit v2 and Boost.Phoenix v3. After including the following headers: #include <boost/phoenix/core.hpp> #include <boost/spirit/include/qi_core.hpp> I got the following error: In file included from ./boost/spirit/home/phoenix/core.hpp:13:0, from ./boost/spirit/include/phoenix_core.hpp:14, from ./boost/spirit/home/support/make_component.hpp:15, from ./boost/spirit/home/support/meta_compiler.hpp:20, from ./boost/spirit/home/qi/domain.hpp:15, from ./boost/spirit/home/qi/parser.hpp:15, from ./boost/spirit/include/qi_core.hpp:16, from libs/log/src/text_file_backend.cpp:51: ./boost/spirit/home/phoenix/core/actor.hpp:46:16: error: redefinition of ‘struct boost::phoenix::detail::error_expecting_arguments’ ./boost/phoenix/core/actor.hpp:41:16: error: previous definition of ‘struct boost::phoenix::detail::error_expecting_arguments’ ./boost/spirit/home/phoenix/core/actor.hpp:65:12: error: redefinition of ‘struct boost::phoenix::actor<Expr>’ ./boost/phoenix/core/actor.hpp:161:12: error: previous definition of ‘struct boost::phoenix::actor<Expr>’ I take it the problem is that Boost.Spirit always include Phoenix v2 which causes name clashes with v3. Is this a known problem? Shouldn't Boost.Spirit include Phoenix v3 headers instead? I can see v3 redirects includes to v2 if BOOST_PHOENIX_USE_V2_OVER_V3 macro is defined (BTW, there's an error in boost/phoenix/stl.hpp: BOOST_PHOENIX_USE_V2 macro is checked instead). This happens in the release branch.

2 6

[TypeErasure]_self
by Markus Werle 23 Jul '12

23 Jul '12

Hi Steven, In [docs]/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/feedback.html you ask for feedback: I would be perfectly happy with _ instead of _self. You would be in sync with the folks that wrote C# Reactive Extensions (http://msdn.microsoft.com/en-us/data/gg577611) who have the convention that _ stands for "unused", which it is here, too. To me constructible<_(const std::string&)> reads fine. Markus

2 1

[website][unordered] Patches on release notes.
by Daniel James 22 Jul '12

22 Jul '12

Hi, There's a fairly serious bug in Boost.Unordered in 1.50 so I wanted to make a patch available. I've added it to the release notes, at the top so it's quite visible, you can see it here: http://www.boost.org/users/history/version_1_50_0.html I'm emailing about this, partly to bring the patch to people's attention and partly to find out what you think of using the release notes this way. Daniel

3 4

[asio] windows::basic_stream_handle
by Daniel Larimer 22 Jul '12

22 Jul '12

Is there a reason why basic_stream_handle does not/can not implement bytes_available() or non_blocking() but can implement sync and async methods? Dan

1 0

Container docs: 404 image
by Olaf van der Spek 22 Jul '12

22 Jul '12

Hi, Page A has a link to image B which doesn't exist. A http://www.boost.org/doc/libs/1_50_0/doc/html/container/non_standard_contai… B http://www.boost.org/doc/libs/1_50_0/doc/html/images/stable_vector.png -- Olaf

1 1

[preprocessor] Sequences vs. All Other Data Structures
by Paul Mensonides 22 Jul '12

22 Jul '12

Hello all. In the past, I've said several times that sequences are a superior to every other data structure when dealing with a collection of elements (tuples are better in some very specific contexts). One of those reasons is that, if a library is built for it, non-unary (or even variadic) elements are natural because the structure of the sequence itself encapsulates each element. (int)(std::pair<int, int>)(double) Another reason is that, if a library is built for it and if placemarkers ala C99/C++11 are available, there is a natural representation of the nil sequence: /**/ ...i.e. nothing. This leads to very natural appends, prepends, and joins, since these operation are simply variations on juxtaposition. s (e) (e) s s1 s2 I'll use these in the examples that follow. Another reason, which I'll demonstrate in this post, is that the very structure of sequences usually contain the potential "processing power" to process them. By "processing power," I'm referring to algorithmic steps (i.e. headroom)--which can be a finite resource in preprocessor metaprogramming. The structure of the sequence itself allows what I've called "sequential iteration." #define A(...) + B #define B(...) - A A(1)(2)(3) // + - + B (The reason that this works is because B is not invoked "within" A and vice versa.) So, to convert a sequence to a comma-separated-list, you can just do something like #define CSV(seq) CSV_A seq #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) , __VA_ARGS__ CSV_C #define CSV_C(...) , __VA_ARGS__ CSV_B CSV( (1)(2)(3) ) // 1, 2, 3 CSV_B Unfortunately, we still have to get rid of the spurious CSV_A, CSV_B, or CSV_C (depending on the length of the sequence) that comes out the end. That's easily done with concatenation. #define CSV(seq) \ CHAOS_PP_REVERSE_CAT(0, CSV_A seq) \ /**/ #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) , __VA_ARGS__ CSV_C #define CSV_C(...) , __VA_ARGS__ CSV_B #define CSV_A0 #define CSV_B0 #define CSV_C0 CSV( (1)(2)(3) ) // 1, 2, 3 The REVERSE_CAT is used here so that the commas don't have to be encoded. Essentially, it's defined as REVERSE_CAT(a, ...) => __VA_ARGS__ ## a except that it allows its arguments to expand. A regular CAT could be used, but you'd have to delay the existence of the commas. Now *if* the number of scans applied to a macro argument is guaranteed by definition of CAT (as it is with CHAOS_PP_CAT), one can do something like this #define CC CHAOS_PP_DEFER(CHAOS_PP_COMMA)() #define CSV(seq) \ CHAOS_PP_CAT(CSV_A seq, 0) \ /**/ #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) CC __VA_ARGS__ CSV_C #define CSV_C(...) CC __VA_ARGS__ CSV_B #define CSV_A0 #define CSV_B0 #define CSV_C0 CSV( (1)(2)(3) ) // 1, 2, 3 The DEFER macro used here delays the expansion of the COMMA() invocation through exactly one scan which is all that CAT applies to its argument. The CC is used here only as an abbreviation so that the example doesn't get too cluttered. This latter version is significantly more verbose, but this type of thing is sometimes unavoidable especially when dealing with unmatched parentheses rather than commas which is exactly what we'll run into next. Let's say we wanted to calculate the length of the sequence. #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define SIZE(seq) \ CHAOS_PP_CAT(SIZE_A seq, 0) 0 CHAOS_PP_CAT(SIZE_C seq, 0) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_C(...) RP SIZE_D #define SIZE_D(...) RP SIZE_C #define SIZE_C0 #define SIZE_D0 SIZE( (1)(2)(3) ) // CHAOS_PP_INC(CHAOS_PP_INC(CHAOS_PP_INC(0))) (As with CC above, the LP and RP macros are just sugar to avoid clutter in the example.) Essentially, we've iterated the sequence twice. The first time, we generated CHAOS_PP_INC( for each element. The second time, we generated ) for each element. However, this doesn't "finish the job" because an expression like MACRO CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() ... ) causes the invocation of MACRO to be deferred through two scans, not one. This is actually a good thing in this scenario, because we don't really want CHAOS_PP_INC to be invoked "inside" CAT. To cause the evaluation, we just add another scan: #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define SIZE(seq) \ SIZE_I(CHAOS_PP_CAT(SIZE_A seq, 0) 0 CHAOS_PP_CAT(SIZE_C seq, 0)) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_C(...) RP SIZE_D #define SIZE_D(...) RP SIZE_C #define SIZE_C0 #define SIZE_D0 #define SIZE_I(x) x SIZE( (1)(2)(3) ) // 3 Like BOOST_PP_INC, CHAOS_PP_INC saturates at a finite value, and thus the above implementation can only "correctly" measure the length of a sequences of limited length. One could use the unlimited, but more expensive, CHAOS_PP_ARBITRARY_INC instead if necessary. Generating a closing parentheses is common, so we'll generalize it #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define CLOSE(seq) CHAOS_PP_CAT(CLOSE_A seq, 0) #define CLOSE_A(...) RP CLOSE_B #define CLOSE_B(...) RP CLOSE_A #define CLOSE_A0 #define CLOSE_B0 The above then becomes #define SIZE(seq) \ SIZE_I(CHAOS_PP_CAT(SIZE_A seq, 0) 0 CLOSE(seq)) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_I(x) x Now, let's do something more serious. I recently ran into a scenario where I needed to generate something for each permutation of each element of the powerset of a sequence. For the powerset: #define POWERSET(seq) \ POWERSET_1(CHAOS_PP_CAT(POWERSET_T seq, 0) CLOSE(seq)) \ /**/ #define POWERSET_1(x) x #define POWERSET_2(e, ps) \ CHAOS_PP_IIF(CHAOS_PP_SEQ_IS_CONS(ps))( \ ps CHAOS_PP_SPLIT( \ 1, \ POWERSET_5(CHAOS_PP_CAT(POWERSET_P ps, 0) e, CLOSE(ps)) \ ), \ (e)() \ ) \ /**/ #define POWERSET_3(...) POWERSET_4(__VA_ARGS__) #define POWERSET_4(seq, e, ps) e, (e seq) ps #define POWERSET_5(...) __VA_ARGS__ #define POWERSET_T(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_F #define POWERSET_F(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_T #define POWERSET_T0 #define POWERSET_F0 #define POWERSET_P(seq) POWERSET_3 LP seq CC POWERSET_Q #define POWERSET_Q(seq) POWERSET_3 LP seq CC POWERSET_P #define POWERSET_P0 #define POWERSET_Q0 POWERSET( (a)(b)(c) ) // ( (c) ) // ( ) // ( (b)(c) ) // ( (b) ) // ( (a)(c) ) // ( (a) ) // ( (a)(b)(c) ) // ( (a)(b) ) It important to note that this implementation is not limited by any library-defined resource. It is limited only by the amount of available compiler resources. With unlimited CPU and memory resources, this algorithm compute the powerset of a sequence of *any* length. For generating permutations, I'll use a helper algorithm which I've called "FOCUS". The job of this algorithm is to produce a sequence which isolates each element in the input sequence. For example, FOCUS((a)(b)(c)(d), ~) // ( (a)(b)(c), (d), , ~) // ( (a)(b), (c), (d), ~) // ( (a), (b), (c)(d), ~) // ( , (a), (b)(c)(d), ~) This is kind of a weird form. Essentially, for each element x in the input sequence, the algorithm produces an element in the resulting sequence of the form: ( seq-of-elements-before-x, (x), seq-of-elements-after-x, ~) #define FOCUS(seq, ...) \ CHAOS_PP_INLINE_WHEN(CHAOS_PP_SEQ_IS_CONS(seq))( \ FOCUS_1( \ (CHAOS_PP_SEQ_HEAD(seq)), \ CHAOS_PP_SEQ_TAIL(seq), \ __VA_ARGS__ ) \ ) \ /**/ #define FOCUS_1(h, t, ...) \ FOCUS_4(CHAOS_PP_CAT(FOCUS_T t, 0)(, h, t, __VA_ARGS__) CLOSE(t)) \ /**/ #define FOCUS_2(seq) FOCUS_3 seq #define FOCUS_3(l, m, r, ...) \ (l m, (CHAOS_PP_SEQ_HEAD(r)), CHAOS_PP_SEQ_TAIL(r), __VA_ARGS__) \ (l, m, r, __VA_ARGS__) \ /**/ #define FOCUS_4(x) x #define FOCUS_T(...) FOCUS_2 LP FOCUS_F #define FOCUS_F(...) FOCUS_2 LP FOCUS_T #define FOCUS_T0 #define FOCUS_F0 As with POWERSET, this implementation is unlimited WRT library resources. Finally, the permuations themselves: #define PERMUTE(seq) \ PERMUTE_3(CHAOS_PP_CAT(PERMUTE_P seq, 0) PERMUTE_1(seq,) CLOSE(seq)) \ /**/ #define PERMUTE_1(seq, pf) \ CHAOS_PP_IIF( \ CHAOS_PP_BITAND(CHAOS_PP_SEQ_IS_CONS(seq)) \ (CHAOS_PP_SEQ_IS_CONS(CHAOS_PP_SEQ_TAIL(seq))))( \ PERMUTE_2, (pf seq) CHAOS_PP_EAT \ )(FOCUS(seq, pf)) \ /**/ #define PERMUTE_1_INDIRECT() PERMUTE_1 #define PERMUTE_2(fs) CHAOS_PP_CAT(PERMUTE_T fs, 0) #define PERMUTE_3(x) x #define PERMUTE_4(x) x #define PERMUTE_T(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_F \ /**/ #define PERMUTE_F(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_T \ /**/ #define PERMUTE_T0 #define PERMUTE_F0 #define PERMUTE_P(...) PERMUTE_4 LP PERMUTE_Q #define PERMUTE_Q(...) PERMUTE_4 LP PERMUTE_P #define PERMUTE_P0 #define PERMUTE_Q0 PERMUTE((a)(b)(c)) // ( (c)(b)(a) ) // ( (c)(a)(b) ) // ( (b)(c)(a) ) // ( (b)(a)(c) ) // ( (a)(c)(b) ) // ( (a)(b)(c) ) Putting these together: #define A(s, seq) \ CHAOS_PP_EXPR_S(s)(CHAOS_PP_SEQ_FOR_EACH_S( \ s, B, PERMUTE(seq) \ )) \ /**/ #define B(s, seq) CHAOS_PP_SEQ_CONCAT(seq) CHAOS_PP_EXPR(CHAOS_PP_SEQ_FOR_EACH( A, POWERSET( (a)(b)(c) ) )) // c cb bc b ca ac a cba cab bca bac acb abc ba ab This generates \sum_{k=0}^n\frac{n!}{\left({n-k}\right)!} = e\int_1^\infty t^ne^{-t}\,dt = e\Gamma\left({n + 1, 1}\right) results (apologies for the LaTeX). For n = 3, as above, that's 16 results (where the 16th is empty from the nil sequence). For n = 6, that's 1957 results. For n = 7, it's 13700 results--which was enough to ICE g++ running on my VM. The moral of the story is that sequences are powerful because in many cases, an input sequence itself often contains enough "potential energy" to process it. It isn't very difficult to produce n^2, 2^n, or even n^n computational steps. I only really needed the case for n = 3, and I ultimately didn't use the above because the cost of a runtime solution acceptable and not really worth adding the above machinery (and I didn't want to take the time to add it to Chaos), but I thought I'd share it anyway. Regards, Paul Mensonides implementation... g++ -E -P -std=c++11 (or -std=c++0x) -I $CHAOS_ROOT <filename> --- #include <chaos/preprocessor/cat.h> #include <chaos/preprocessor/control/iif.h> #include <chaos/preprocessor/control/inline_when.h> #include <chaos/preprocessor/facilities/split.h> #include <chaos/preprocessor/logical/bitand.h> #include <chaos/preprocessor/punctuation/comma.h> #include <chaos/preprocessor/punctuation/paren.h> #include <chaos/preprocessor/recursion/basic.h> #include <chaos/preprocessor/recursion/expr.h> #include <chaos/preprocessor/seq/concat.h> #include <chaos/preprocessor/seq/core.h> #include <chaos/preprocessor/seq/for_each.h> #include <chaos/preprocessor/tuple/eat.h> #ifndef SEQ #define SEQ (a)(b)(c) #endif #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define CC CHAOS_PP_DEFER(CHAOS_PP_COMMA)() #define CLOSE(seq) CHAOS_PP_CAT(CLOSE_T seq, 0) #define CLOSE_T(...) RP CLOSE_F #define CLOSE_F(...) RP CLOSE_T #define CLOSE_T0 #define CLOSE_F0 #define POWERSET(seq) \ POWERSET_1(CHAOS_PP_CAT(POWERSET_T seq, 0) CLOSE(seq)) \ /**/ #define POWERSET_1(x) x #define POWERSET_2(e, ps) \ CHAOS_PP_IIF(CHAOS_PP_SEQ_IS_CONS(ps))( \ ps CHAOS_PP_SPLIT( \ 1, \ POWERSET_5(CHAOS_PP_CAT(POWERSET_P ps, 0) e, CLOSE(ps)) \ ), \ (e)() \ ) \ /**/ #define POWERSET_3(...) POWERSET_4(__VA_ARGS__) #define POWERSET_4(seq, e, ps) e, (e seq) ps #define POWERSET_5(...) __VA_ARGS__ #define POWERSET_T(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_F #define POWERSET_F(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_T #define POWERSET_T0 #define POWERSET_F0 #define POWERSET_P(seq) POWERSET_3 LP seq CC POWERSET_Q #define POWERSET_Q(seq) POWERSET_3 LP seq CC POWERSET_P #define POWERSET_P0 #define POWERSET_Q0 // -- #define FOCUS(seq, ...) \ CHAOS_PP_INLINE_WHEN(CHAOS_PP_SEQ_IS_CONS(seq))( \ FOCUS_1( \ (CHAOS_PP_SEQ_HEAD(seq)), CHAOS_PP_SEQ_TAIL(seq), \ __VA_ARGS__ \ ) \ ) \ /**/ #define FOCUS_1(h, t, ...) \ FOCUS_4(CHAOS_PP_CAT(FOCUS_T t, 0)(, h, t, __VA_ARGS__) CLOSE(t)) \ /**/ #define FOCUS_2(seq) FOCUS_3 seq #define FOCUS_3(l, m, r, ...) \ (l m, (CHAOS_PP_SEQ_HEAD(r)), CHAOS_PP_SEQ_TAIL(r), __VA_ARGS__) \ (l, m, r, __VA_ARGS__) \ /**/ #define FOCUS_4(x) x #define FOCUS_T(...) FOCUS_2 LP FOCUS_F #define FOCUS_F(...) FOCUS_2 LP FOCUS_T #define FOCUS_T0 #define FOCUS_F0 // -- #define PERMUTE(seq) \ PERMUTE_3(CHAOS_PP_CAT(PERMUTE_P seq, 0) PERMUTE_1(seq,) CLOSE(seq)) \ /**/ #define PERMUTE_1(seq, pf) \ CHAOS_PP_IIF( \ CHAOS_PP_BITAND(CHAOS_PP_SEQ_IS_CONS(seq)) \ (CHAOS_PP_SEQ_IS_CONS(CHAOS_PP_SEQ_TAIL(seq))))( \ PERMUTE_2, (pf seq) CHAOS_PP_EAT \ )(FOCUS(seq, pf)) \ /**/ #define PERMUTE_1_INDIRECT() PERMUTE_1 #define PERMUTE_2(fs) CHAOS_PP_CAT(PERMUTE_T fs, 0) #define PERMUTE_3(x) x #define PERMUTE_4(x) x #define PERMUTE_T(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_F \ /**/ #define PERMUTE_F(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_T \ /**/ #define PERMUTE_T0 #define PERMUTE_F0 #define PERMUTE_P(...) PERMUTE_4 LP PERMUTE_Q #define PERMUTE_Q(...) PERMUTE_4 LP PERMUTE_P #define PERMUTE_P0 #define PERMUTE_Q0 // -- #define A(s, seq) \ CHAOS_PP_EXPR_S(s)(CHAOS_PP_SEQ_FOR_EACH_S( \ s, B, PERMUTE(seq) \ )) \ /**/ #define B(s, seq) CHAOS_PP_SEQ_CONCAT(seq) CHAOS_PP_EXPR(CHAOS_PP_SEQ_FOR_EACH( A, POWERSET(SEQ) ))

9 42

[filesystem] C++11 range-based for statement and BOOST_FOREACH support
by Beman Dawes 21 Jul '12

21 Jul '12

Support for the C++11 range-based for statement and BOOST_FOREACH for directory_iterator and recursive_directory_iterator has been added to trunk. This clears feature requests 5896 and 6521. The range-based for has been tested against gcc 4.6, which works, and against VC++2012 RC, which ICEs the compiler. The ICE has been reported to Microsoft. If anyone gives either C++11 range-based for or BOOST_FOREACH a try, I'd appreciate hearing about any problems. Both of these are new to me, and I'm nervous about getting the enabler free functions right. Here is what usage looks like: for (directory_entry& x : directory_iterator(".")) { std::cout << " " << x.path() << "\n"; } BOOST_FOREACH(directory_entry& x, directory_iterator(".")) { std::cout << " " << x.path() << "\n"; } Thanks, --Beman

8 21

[assignment] += for containers on right side
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! is it possible to make += also work for containers on right side? i.e. int a; std::vector<int> b; std::list<int> c; std::vector<int> d; d += a,b,c,d; this would be similar to strings where += at least works with one string on the right side. -Jochen

6 7

[type_traits] Is it possible to test for an explicit conversion?
by John Maddock 20 Jul '12

20 Jul '12

OK, so we don't have such a trait at present, but one of the requests from the multiprecision review was "make conversions explicit in the front end if they are in the backend". Which to do it nicely (and semi-automagically) requires a trait that tests whether A is explicitly convertible to B. Which would obviously make a useful type trait in it's own right, but.... anyone have any ideas on how such a trait could be implemented? At present it looks "impossible" to me, but I've learned never to say never ;-) Thanks, John.

2 2

Proposal: Linear map
by Amir Ansari 20 Jul '12

20 Jul '12

Hi, In my work I have repeatedly had the need to create a sorted array in which I can insert/lookup from using a key. This is like a map except that it uses an array. The contention is that in some cases, it is faster to insert/remove from a sorted array rather than traversing a tree (the underlying data structure for a map) which involves pointer de-referencing. I would like to call the class linear_map. Looking forward to feedback from everyone. Many thanks, - Amir

5 11

[array] - array_vector
by Hite, Christopher 20 Jul '12

20 Jul '12

I've a got a small utility class that is a cross between boost::array and std::vector for when I only have a compile time constant max things. This is beats to complexity of fighting with custom allocators/pools. const unsigned n=100; Thing array[n]; unsigned count=0; goes to: array_vector<Thing,100> things; It's stl compliant and should drop in anywhere you've got a vector. Like vector and unlike boost::array (or regular array) 100 Things are not constructed. Have I reinvented something in boost? Should I submit it? Also related to this. There are a class of problems where n is known only on runtime, but you still only need it in a certain scope. gcc (C99 standard) allows variable length arrays on the stack. Does anyone know if that is allowed in C++11? What would think about something like this? unsigned n=readInt(); placeholder<Thing> bufffer[n]; //variable length data on stack buffer_vector<Thing> v(buffer,n); Chris

1 0

[numeric][ublas] please add vector constructor from boost::range
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! is it possible to add a constructor for ublas::vector from boost::range? this would it make easier to construct from pain data (e.g. float*). something like boost::numeric::ublas::vector<float> v(boost::iterator_range<const float*>(myDataBegin, myDataEnd)); -Jochen

4 3

[optional] reduce need for operator ==
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! currently boost::optional<Type> requires an operator == for Type. If I only want to check if the optional is present or not, then this is not necessary. e.g. struct Foo {int i;}; boost::optional<Foo> foo; if (foo == boost::none) ... is it possible to change this? for example by template<class T> inline bool operator == ( optional<T> const& x, none_t ) { return !x; } -Jochen

3 2

[TypeErasure] Composing Concepts & some notes
by Fabio Fracassi 20 Jul '12

20 Jul '12

Hi Steven, I am going through the documentation and simultaneously try out some things that weren't immediately obvious to me. When I came to the paragraph about composing concepts the last sentence "We can even specialize concept_interface for it." tripped me up. My thought was "but do I have to? and how do composed concepts interact with manually composed any's?" so I gave it a try: I used your push_back concept and defined a size concept like this: template<class C> struct size { static size_t apply(C& cont) { return cont.size(); } }; namespace boost { namespace type_erasure { template<class C, class Base> struct concept_interface< ::size<C>, Base, C> : Base { size_t size() { return call(::size<C>(), *this); } }; } } which works fine: std::vector<int> vec; typedef any<push_back<_self, int>, _self&> any_push_back; any_push_back pb(vec); pb.push_back(10); pb.push_back(2); typedef any<size<_self>, _self&> any_size; any_size s(vec); std::cout << "Size = " << s.size() << std::endl; Now I wanted to try composition first manually: typedef any< mpl::vector< push_back<_self, int>, size<_self> >, _self& > any_manual_vecconcept; any_manual_vecconcept alvec(vec); alvec.push_back(13); alvec.push_back(11); std::cout << "Size = " << alvec.size() << std::endl; and then via "named composition": template<class T, class C> struct vecconcept : mpl::vector< push_back<T, C>, size<T> > {}; typedef any<vecconcept<_self, int>, _self&> any_vecconcept; any_vecconcept acvec(vec); acvec.push_back(15); acvec.push_back(17); std::cout << "Size = " << acvec.size() << std::endl; great everything works as expected, and no, I did not have to define a concept_interface for the composite interface. Now the first question is why would I want to? now the main reason for the exercise was how do these interact with each other and while I am at it how do they interact with the concepts they are composed of? Well I can freely interact as I hoped: any_vecconcept acvec2(alvec); any_manual_vecconcept alvec2(acvec); any_push_back pb3(alvec); any_push_back pb4(acvec); any_size s2(alvec); any_size s3(acvec); This is great! I might have missed it in the documentation, but I think this is really an important feature that deserves special mention. Now I gather that there is no way to do the opposite, something along the lines of any_vecconcept acvec3 = dynamic_any_cast<any_vecconcept>(s3); Well over the next days I will dive a bit deeper into the internals to see if implementing such a feature would be feasible. (because I need it before I could replace my current solution with type erasure) Steven, let me finish by saying thank you for the great work. regards Fabio

2 2

[pool] Calling all library designers: The future of Boost.Pool???
by John Maddock 19 Jul '12

19 Jul '12

As one of the last people to try and do any maintenance of Boost.Pool I feel I should try and start some discussion here on it's future. First off some random thoughts based on my last experiences with this library: * It should be simple, but it's confusing. In particular the difference between ordered and unordered pools is not particularly intuitive, but IMO the distinction between the various components, and what should be used where is also poor. * I believe the decision to support both ordered and unordered pools in the same interface was a mistake. At the very least it's potentially error prone in use, but it's also inefficient. It looks to me that this, along with the allocators provided, were a classic case of feature creep post-review. I'm sure they sounded like good ideas during the review, but in practice a smaller more tightly focused library might actually be better. * It's not clear that the claimed performance improvements are actually there in practice (any more). This is partly due to compiler and std lib improvements, partly due to feature creep in Boost.Pool. Some bug fixes have had a negative effect too - however needed they may have been for correctness. * Many of the existing bug reports were deliberately left "in limbo" because there was no obvious/easy way to fix them without compromising Boost.Pool's core mission (providing fixed size blocks of memory really fast). * There have been many changes to the standard, compiler technology, and to Boost's best practices since the library was designed, many of which would result in a different design today, but also different requirements today (per instance allocators in containers for example). * In no way do I want to be lumbered with maintaining Boost.Pool and in any case I don't believe it's really fit for purpose any more [1]. So..... in an ideal world, I'd like someone to step up to the plate and design it's replacement.... yes a whole new Pool2. Off the top of my head, here's my wish list: * There should be a very small, very focused (i.e. fast) core that provides fixed sized blocks of memory. Nothing more. * Thread synchronization when needed (template param?) should be via lockfree programming wherever possible. Indeed a simple pool like this, is pretty much the poster child for lock-free-programming. And of course we have Boost.Lockfree now. * There should probably be a heap implementation for variable sized allocation requests. I'm assuming that this can't be done lockfree(?). * Allocators: both singleton and stateful allocators should be provided (templated on pool type?). But there's a trick here: many containers only allocate fixed size blocks, but we have no way of knowing what that size is upfront at compile time. Connecting the allocation request to the correct pool interface in an efficient manner is pretty tricky here, especially if 99% of allocations are of fixed sized, but there are a few odd-sized control blocks also allocated. In any case, all allocations should come from the same underlying block of memory, even if they're for different types/sizes. * Both pools and allocators, should be able to accept a single fixed sized block of memory (from wherever) and divide it up to clients. A good example for this use case is an arena-allocator: a stateful allocator whose memory all comes from the stack, no thread synchronization required. Containers using such types can be blisteringly fast compared to regular allocators, particularly when using a scoped container for just a few manipulations. Ideal for use with C++11 containers or Boost.Container. Hopefully others will chime in here with their requirements as well. Cheers all, John. 1) This doesn't preclude applying *trivial* fixes to Boost.Pool, but I genuinely believe that big changes are more likely to be counterproductive at this point.

11 19

[website] Build & link field in library list
by Daniel James 19 Jul '12

19 Jul '12

Hi, In the library list (http://www.boost.org/doc/libs/) I don't think the 'build & link' field is very accurate. There's a recent bug report about pool, which apparently isn't header only. I suspect it's wrong for some other libraries as well, and for some libraries the situation is a bit more complicated. So, I'm thinking about removing it. Incorrect and misleading information can be worse than no information at all. Does anyone have an attachment to it? Daniel

1 0

[TypeErasure] assignment operator of any references
by Vicente J. Botet Escriba 19 Jul '12

19 Jul '12

Hi, The References section constains this example: int i, j; any<typeid_<>, _self&> x(i), y(j); x = y; // error The following basic c++ code int i=1, j=0; int& x(i); int& y(j); x = y; // [1] works and the expected value of x after [1] is 0. Which concept requirements should I add to make the following work? assignable? int i, j; any<mpl::vector<typeid_<>, ...>, _self&> x(i), y(j); x = y; // no error Best, Vicente

2 3

How to find all paths with a length in a certain range
by J Birch 18 Jul '12

18 Jul '12

I am fairly new to Boost, and not the greatest at C++, but I do have a bit of experience in dealing with graphs in other languages. We currently have some very ugly and inefficient code that effectively builds up a graph structure (DAG), and must calculate all paths with a length between a certain range, say 3-7. I have seen the question asked a few times via Google, but I have seen no solution. I have been tinkering around with different examples, but have yet to come up with anything useful. Would anyone be able to point me in the right direction? Thanks! Birch

3 3

Merging to release
by Marshall Clow 18 Jul '12

18 Jul '12

The deadline for bug fixes for 1.51 is tomorrow; and I'd like to merge the changes I made to the following libraries to release: * Config - reorganized the c++11 macros * Unordered - changed #ifdefs to use non-deprecated macros * functional/hash - changed #ifdefs to use non-deprecated macros * Random - changed #ifdefs to use non-deprecated macros * Regex - changed #ifdefs to use non-deprecated macros * Math - changed #ifdefs to use non-deprecated macros I've been watching the test results; and it turns out I broke two of the C++11 tests, which only affects people running the tests on C++11 compilers. I fixed those this morning. Any objections? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

9 11

Re: [boost] Boost.config limits_test testcase and qnan checks
by Matthew Markland 18 Jul '12

18 Jul '12

Extra text elided below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost- > bounces(a)lists.boost.org] On Behalf Of boost-request(a)lists.boost.org > Sent: Friday, July 13, 2012 10:51 PM > To: boost(a)lists.boost.org > Subject: Boost Digest, Vol 3701, Issue 4 >----- <elided> > Message: 5 > Date: Fri, 13 Jul 2012 18:07:45 +0000 > From: Thomas Klimpel <Thomas.Klimpel(a)synopsys.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] Boost.config limits_test testcase and qnan > checks. > Message-ID: > <4468C9C2AE594745A32DC93C799A224A01D0FB(a)DE02WEMBX2.inte > rnal.synopsys.com> > > Content-Type: text/plain; charset="us-ascii" > <elided> MARKLAND> My question is whether it is valid to test the qnan behavior when a MARKLAND> platform MARKLAND> > does not claim compliance? > > I wonder how you measure "claim compliance"? I once had a long debug > session with gcc-4.5.2 before I found out that the builtin "is_nan" was > returning wrong results. Isn't compiling the code that uses "is_nan" without > warning also some sort of "compliance claim"? I know you are probably > referring to "numeric_limits<double>::is_iec559", but on which floating point > functionality can I still rely as a programmer if (is_iec559 == false)? > > Regards, > Thomas I've now been trying to come up with a good answer to this for days and have yet to get there. So I'm going to just comment and see if the discussion continues. These are my interpretations and should not be construed as the opinion of my employer. In the case of this particular test, from a language perspective, I think the check for is_iec559 makes sense. The part of the test in question is testing a behavior that is only defined for certain if the platform is using an IEEE compliant implementation. Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true. As for what you can rely on if is_iec559() is false, that is a good question. Most of the items in numeric_limits<> appear to require explicit checks for availability if is_iec559() is false. My readings of the Standards (C/C++) seem to show them to be silent on what happens with a function like isnan() if is_iec559() is false. Most of what I've seen on the web is that these functions are of dubious usefulness due to optimizations performed. Clearly one would like to expect that if the compiler is being used at an optimization level that breaks floating-point compliance then is_iec559() would be set to false, but from what I've read that isn't a safe expectation. I guess you're at the mercy of your compiler vendor to describe their levels of support and what these functions may mean. Does anyone else have insight into this situation? Matt

3 2

conversion review report
by Gordon Woodhull 18 Jul '12

18 Jul '12

Hi Vicente, all, Profuse apologies for the long delay in writing this report. Cheers, Gordon Report on Boost Conversion Library Review, August 20-29, 2011. I want to thank Vicente Botet Escriba for submitting the Conversion library for review and for his general good nature in receiving criticism and alternate designs. The Conversion library presents a general framework for plugging in conversion operations between arbitrary types, providing a consistent interface for type-to-type conversions. The library is unfortunately rejected. During the review, there were two votes for acceptance and two against, and some interesting conversation from about a dozen participants. The major reason the library can't be accepted in its current form is that there was near consensus that there is no universal conversion domain, especially when the source or destination type might be a string. Much of the review focused on possible One Definition Rule (ODR) violations, which are a consequence of having a universal customization point using template specializations or function overloads. Many solutions were offered, which will make up the second part of this report, "How to Avoid Universality." I. Concerns about the library Conversions Are Not Generic? While some reviewers didn't see the need for a generic conversion library (and I was a little surprised at the vehemence of their opinions), I don't see this in itself as a reason to reject the library. The library's stated purpose is to provide a common interface for general type <-> type conversions, like lexical_cast does for string <-> type conversions. However, it was interesting that seemingly no one could come up with applications of truly generic conversion, although Jeffrey Lee Hellrung and Antony Polukhin alluded to their existence. Also, some reviewers pointed out that you often need to choose what kind of conversion to do, and a generic library can get in the way here. Strings are the most obvious example: if you are converting from a string representing a binary value it would not work to use a decimal converter. Antony Polukhin pointed out a more subtle example: "lexical_cast<char>(1) and numeric_cast<char>(1) will produce different output." Jeff Hellrung summed this point up nicely: "I think it's certainly possible for different clients using the same generic component to want different conversion implementations for a given pair of types, and that point, Boost.Conversion's universally-defined conversion implementations become useless. One wants the conversion operation to be parametrized as well as the types involved in the conversion." Multi-Client Specialization Concerns Leaving aside possible ODR violations, which we'll return to in Part II, some reviewers questioned the scalability of using template specialization and overloads when many clients (i.e. independent headers) may be customizing the behavior. Vladimir Batov claimed that a system which allows partial specializations on both Source and Target can't be made to work generally. Jeroen Habraken said SFINAE/enable_if "does make code fragile". I'm not clear if these conversations were resolved (or resolvable ;). Non-Generic Solutions Some reviewers objected that conversions should just be defined within individual libraries, but of course this begs the question (as came up recently on the ML between DateTime and Chrono), "which library should house the conversions?" Others (such as Phil Endecott) thought that simple c-style functions such as rgb_to_cmyk() were more explicit and direct. Why is this so complex? Kevlin Henney, initially excited about a general solution to the problem which lexical_cast first set out, commented on the documentation: "Based on casual reading, it feels a little more complex and requires a higher-entry level of knowledge than would be appropriate for many of the people who actually need this functionality." II. How to Avoid Universality One of the positive results of this review was a small catalog of alternatives to a universal customization point involving template specialization or overloaded functions. a. Avoid the Problem In the strictest sense, any library which allows either kind of universal customization can be prone to ODR violations. But many reviewers particularly thought that a customization point involving two UDTs was especially dangerous. To his credit, Vicente was very up-front about the limitations of his design, and attempted to formulate rules for how the library could be used safely. In the documentation, he suggests (IIUC) that header-only libraries could use generic conversions as long as they don't define them, or define them as long as they don't use them. http://tinyurl.com/cmbgyfk b. Inherited tags John Bytheway suggested a tag-dispatch system where conversions are tagged with their source library, and any library which depends on conversions from two libraries would define a tag which inherits from the tags of both libraries. Thus ODR violations are avoided at the expense of having to specify an extra tag (effectively a sort of global conversion domain). http://lists.boost.org/Archives/boost/2011/08/184836.php c. Conversion Domains and Overloaded Function Objects Going on the consensus that there is no universal conversion domain, your humble review manager suggested a metaprogramming solution that defines conversion domain objects which combine a set of conversions within an object. http://lists.boost.org/Archives/boost/2011/08/185259.php A more general solution would be to create an overloaded polymorphic function object, much like a polymorphic-source version of Lorenzo Caminiti's OverloadedFunction library (http://tinyurl.com/72nolyj) However, I have been warned (by Daveed Vandevoorde) that the rules for function overloading are too dangerously complicated to implement in a metaprogram. d. Boost.Dispatch Matthias Gaunard announced that he is working on a library particularly to "solve the problem of specializing a function template for a category of types with best-match selection." http://lists.boost.org/Archives/boost/2011/08/185286.php e. Abuse of Unnamed Namespaces Emil Dotchevski suggested that "It might be possible to abuse unnamed namespaces to avoid violating ODR". I'm not clear if this was a serious suggestion as it wasn't spelled out. :) f. GIL's solution (?) Christian Henning wrote: "GIL has such functionality. I like their way of structuring conversion." However, I was not able to find a description of this mechanism for the report. Thanks to everyone who participated in the review!

2 1

[Pool] Patches
by DUPUIS Etienne 17 Jul '12

17 Jul '12

Greetings, https://svn.boost.org/svn/boost/sandbox/pool at revision 79460 contains a solution for tickets #3789, #5902, #6561, #6610, #6701, #6718, #6865 and #6867. Related test cases for each ticket are also present. By the way, the Pool tests fail in the trunk; a missing dependency on Boost.System, which I added to the JamFile in sand box. https://svn.boost.org/svn/boost/sandbox/pool at revision 79460 does not contain any other new features or modifications other than those related to the above tickets. As Boost.Pool currently has no maintainer and is thus orphaned, and also since I am leaving the mailing list, I reassigned these tickets to John Maddock since he was the last to commit code changes into Boost.Pool. Regards, Étienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

2 1

[mpl] std::integral_constant support?
by Eric Niebler 17 Jul '12

17 Jul '12

The following reasonable-seeming use of mpl::plus doesn't compile: #include <utility> #include <boost/mpl/plus.hpp> typedef std::integral_constant<int, 1> one; typedef boost::mpl::plus<one, one>::type two; That's because mpl only works with its own integral constant wrappers, not the standard one. That seems unfortunate to me. Is there any interest in supporting this? Here's the error (from clang trunk with glibc++): 1> In file included from main.cpp:2: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/plus.hpp:19: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/arithmetic_op.hpp:34: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/include_preprocessed.hpp:37: 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:60:25: error: no type named 'tag' in 'std::integral_constant<int, 1>' 1> typedef typename T::tag type; 1> ~~~~~~~~~~~~^~~ 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:111:20: note: in instantiation of template class 'boost::mpl::plus_tag<std::integral_constant<int, 1> >' requested here 1> typename plus_tag<N1>::type 1> ^ -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[Memory][SmartPtr][Interprocess] Is there an interest in a Boost library more or less c++11 compliant?
by Vicente J. Botet Escriba 16 Jul '12

16 Jul '12

Hi, Boost has a lot of pieces of the c++11 header <memory>, shared_ptr, weak_ptr , ... in Boost.SmartPtr, unique_ptr, allocator argument tag, uses_allocator ... in Boost.Interprocess. Other are already in the C++03 <memory> header. Others are missing, as pointer_traits, default_delete, ... I would like we complete all these features and move them to a Boost.Memory library smoothly (something like the Boost.Utility). As these are standard features, I propose to use directly the boost namespace for them. boost memory.hpp memory pointer_traits_hpp ... unique_ptr.hpp shared_ptr.hpp weak_ptr.hpp ... What do you think? Best, Vicente

2 1

[type_traits] has_equal_to< std::vector<T> > always true_
by lcaminiti 15 Jul '12

15 Jul '12

-- View this message in context: http://boost.2283326.n4.nabble.com/boost-type-traits-has-equal-to-std-vecto… Sent from the Boost - Dev mailing list archive at Nabble.com.

11 33

[1.50.0] PDF documentation available
by John Maddock 15 Jul '12

15 Jul '12

With apologies for being so late with these.... The PDF build of Boost's documentation for 1.50 is available from the usual SF site: https://sourceforge.net/projects/boost/files/boost-docs/1.50/ John.

2 1

[atomic] trunk doesn't build with VC++
by Luke Elliott 14 Jul '12

14 Jul '12

compile-c-c++ ..\..\..\bin.v2\libs\atomic\build\msvc-9.0\debug\threading-multi\lockpool.obj lockpool.cpp D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(125) : error C2039: 'platform_cmpxchg32' : is not a member of 'boost::atomics::detail' D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(125) : error C3861: 'platform_cmpxchg32': identifier not found D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(127) : warning C4800: 'boost::uint32_t' : forcing value to bool 'true' or 'false' (performance warning) Should it be using platform_cmpxchg32_strong at line 125 of interlocked.hpp? And return (0 != expected) (or something) on line 127 to clean up the warning? Best regards Luke Elliott.

1 0

Clang Darwin trunk Cray 8.0 and max_digits10 support - problem in config?
by Paul A. Bristow 14 Jul '12

14 Jul '12

I note that the test of ztest_max_digits10 and zztest_max_digits10 in http://www.boost.org/development/tests/trunk/developer/math.html both fail for these platforms. ztest_max_digits10 tests of native std::numeric_limits<>::max_digits10 is supported. zztest_max_digits10 test if BOOST_NO_NUMERIC_LIMITS_LOWEST is a proxy to signal support. where using std::numeric_limits<>::max_digits10 should be possible using BOOST_NO_NUMERIC_LIMITS_LOWEST as a proxy for Clang the messages are In file included from ../libs/math/test/zztest_max_digits10.cpp:27: In file included from ../boost/config.hpp:40: ../boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef> In file included from ../libs/math/test/ztest_max_digits10.cpp:27: In file included from ../boost/config.hpp:40: ../boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found or for Cray CC-1353 crayc++: INTERNAL File = /opt/gcc/4.4.4/snos/include/g++/bits/move.h, Line = 34 CIF Error #include <cstddef> ^ This appears to be a problem in the config - a missing include. Suggestions? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 24

[asio] boost::asio::read with empty input vector leads to an infinite loop
by Michael Kochetkov 13 Jul '12

13 Jul '12

Hello, In the code bellow I have forgotten to set the input vector (request) size. Is the code really supposed to react as an infinite loop (no errors, length is always 0, boost::asio::read returns immediately) or such behavior is a defect? for (;;) { std::vector<uint8_t> request; boost::system::error_code error; size_t length = boost::asio::read(sock, boost::asio::buffer(request), error); if (error == boost::asio::error::eof) break; else if (error) throw my_exception(L"Socket error"); ... } Thank you in advance, -- Michael Kochetkov

4 5

[filesystem] 1.49 linking with c++0x
by Daniel Larimer 13 Jul '12

13 Jul '12

Given: // cp.cpp #include <boost/filesystem.hpp> int main( int argc, char** argv ) { if( argc < 3 ) return -1; boost::filesystem::copy_file( argv[1], argv[2] ); return 0; } g++ -o cp cp.cpp -std=c++0x -I /usr/local/include /usr/local/lib/libboost_filesystem.a /usr/local/lib/libboost_system.a Undefined symbols for architecture x86_64: "boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option, boost::system::error_code*)", referenced from: boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&) in ccUAyvBD.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status If I remove the -std=c++0x flag then it links just fine. g++ --version g++ (MacPorts gcc47 4.7.0_3) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Dan

6 9

Boost.config limits_test testcase and qnan checks.
by Matthew Markland 13 Jul '12

13 Jul '12

First an introduction; my name is Matt Markland and I support the Cray Compiling Environment (CCE) C/C++ compiler for Cray, Inc. We (Cray) are in the process of improving our Boost support and currently have an intern doing some work for us on this path. While working on Boost.config, he has run into a testcase failure with the limits_test function test_float_limits(). With default options, CCE fails the qnan tests due to the fact that we do not conform to the IEEE specification. CCE is a little different here in that by default it runs at a higher optimization level then other compilers. Gcc will fail this portion of the test if you compile with optimization on and -ffast-math. My question is whether it is valid to test the qnan behavior when a platform does not claim compliance? It seems to me that these checks should be wrapped in an is_iec559 check. Thoughts? Thanks for your time! Matt ---- Matthew Markland Compiler Front-End and Libraries C/C++ Front-End markland(a)cray.com 651-605-9186

3 2

Update request to Boost Discussion Policy maintainers
by Mateusz Loskot 13 Jul '12

13 Jul '12

Folks, May I request to update the "Effective Posting" section of the policy at: http://www.boost.org/community/policy.html#effective adding the following new sub-section as first: """ Use Sensible Subject Please make sure that your postings have a meaningful subject line that is related to the contents of your mail. Many people use this to help determine which posts to read and which to ignore when they're operating under time constraints. """ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Review Wizard Status Report for July 2012
by Ronald Garcia 13 Jul '12

13 Jul '12

============================================== Review Wizard Status Report for July 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Type Erasure * Range Extensions * Contract * Nowide (M) * ODEint (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Type Erasure ------------ :Author: Steven Watanabe :Review Manager: Lorenzo Caminiti :Download: http://sourceforge.net/projects/steven-watanabe.u/files/ :Description: The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Needed :Download: https://github.com/headmyshoulder/odeint-v2 :Description: 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. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[interprocess] named_condition compile failure...
by Joseph Van Riper 13 Jul '12

13 Jul '12

I have either not understood the documentation, or found a bug in Boost.Interprocess's named_condition class. If I'm in error, I hope someone can help me. Otherwise, I will need to approach my needs another way. I assume that named_condition requires a named_mutex, as the documentation states in the Description here: http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_cond… "This condition variable is designed to work with named_mutex<http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_mute…> and can't be placed in shared memory or memory mapped files." Unfortunately, at least on a VC++ 2010 compiler, this doesn't seem to compile for me. I am using the following test code: #include "stdafx.h" #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/named_mutex.hpp> int _tmain(int argc, _TCHAR* argv[]) { boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, "test" ); boost::interprocess::named_condition condition( boost::interprocess::open_or_create, "test" ); condition.wait( mutex ); return 0; } With this code, I get the following error: 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex(void) const' 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>' being compiled 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait<L>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1> c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait<boost::interprocess::named_mutex>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments - Trey

2 3

[1.50] Beta build of the PDF docs
by John Maddock 13 Jul '12

13 Jul '12

A PDF build of the 1.50(beta) docs is here: https://sourceforge.net/projects/boost/files/boost-docs/1.50/ Please let me know if there are any issues, John.

3 6

Macro fo rBOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or use BOOST_NO_NUMERIC_LIMITS_LOWEST
by Paul A. Bristow 13 Jul '12

13 Jul '12

I have recently used BOOST_NO_NUMERIC_LIMITS_LOWEST to act as a proxy for support of numeric_limits<T>:: max_digits10 (as correctly suggested by John Maddock). Do we need yet another new macro for this, say BOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or continue to use BOOST_NO_NUMERIC_LIMITS_LOWEST as a proxy. I think the latter will suffice (despite its unfortunate name for this task). But I think an addition to the configuration macro reference docs would be useful. Perhaps in macro_reference.qbk [[`BOOST_NO_NUMERIC_LIMITS_LOWEST`][Standard library][ Static function `numeric_limits<T>::lowest()` is not available for use. Also acts as a proxy for static const int `numeric_limits<T>:: max_digits10;` is not available for use. ]] I suspect there are also other additions that went with these two items, but I'm having a senior moment about what they are ;-( Views? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 12