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

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

Interest in Base2/16/32/64 Encoding Library?
by Thomas Kemmer 27 Jan '14

27 Jan '14

Dear Boost Developers, I would like to know if there is interest in incorporating a generic Base2/16/32/64 encoding library into Boost. I am the author of such a libray, hosted at http://code.google.com/p/stlencoders/ and would be willing to contribute and make the effort of "Boostifying" it, if the Boost community is interested in such a thing. There have been several suggestions for a Base64 encoding library on this mailing list in the past. Most of them have been dismissed, since Boost already provides a Base64 implementation with Boost.Serialization's "Dataflow Iterators". Though I appreciate the dataflow iterator's design, from personal experience I think that for the basic task of encoding/decoding, a higher-level interface, e.g. one that takes padding and intermittent whitespace (MIME) into account, would benefit many developers. Currently, the stlencoders library - implements the Base16, Base32 and Base64 encoding schemes as defined in RFC 4648. Base2, i.e. binary encoding, is also supported. - implements encoding and decoding operations as generic algorithms that operate on STL-style iterators - supports different encoding alphabets using custom traits classes - supports different character types - lets the user define if/which non-alphabet characters should be ignored via predicates - provides reasonable performance that matches most "plain C" implementations stlencoders is currently designed as a stand-alone library with no dependencies on Boost (or anything but C++03); it would therefore take some effort and guidance from the community to properly integrate it with the rest of Boost. I would therefore appreciate any feedback regarding your interest in this. Kind Regards, Thomas

7 11

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 6

[asio] Randomly having problems reading from the socket
by Torben Wiggerich 29 Jul '13

29 Jul '13

Hi all, I have some problems using the boost.asio.read for a TCP-socket. So far it works fine, but it randomly stops the transfer for at least 5 seconds. To resolve the error I used a simple synchronous server and client from the boost examples and modified it too send a larger amount of data. (307400 Bytes; this size comes from the program I'm trying to get run). On the client side I also changed the reading from the socket to read the complete data with boost.asio.read and transfer_all as argument. Both, server and client, measure the time for sending and reading to the socket and will give an error if it needs more than 1 second. Here is the sourcecode for the server: #include <iostream> #include <string> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main() { try { boost::asio::io_service io_service; tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); tcp::socket socket(io_service); acceptor.accept(socket); unsigned char * array = new unsigned char[307400]; for (;;) { boost::system::error_code ignored_error; ptime startTime = microsec_clock::universal_time(); boost::asio::write(socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), ignored_error); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } My client sourcecode: #include <iostream> #include <boost/array.hpp> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main(int argc, char* argv[]) { try { if (argc != 2) { std::cerr << "Usage: client <host>" << std::endl; return 1; } boost::asio::io_service io_service; boost::asio::ip::tcp::endpoint endpoint( boost::asio::ip::address::from_string( argv[1] ), 8002 ); tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; socket.connect( endpoint, error ); if (error) throw boost::system::system_error(error); int counter = 0; unsigned char* array = new unsigned char[307400]; for (;;) { boost::system::error_code error; ptime startTime = microsec_clock::universal_time(); size_t len = boost::asio::read( socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), error ); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( error ) { printf( "body read error %s\n", error.message().c_str() ); } if ( counter % 5000 == 0 ) { std::cout << "passed: " << counter << "\r"; } ++counter; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } To reproduce the error just let it run for a while. It can take up to 30 minutes or even more... After a while it will produce the line: "ERROR needed too much time: 5007ms". Maybe with slightly different times, but all around 5 seconds. I tested it on different machines with Windows Vista and Seven. So am I'm doing sth. wrong? Is the reading from the socket correct? I'm using boost version 1.44. Kind regards Torben Wiggerich

6 11

A more convenient Variant visitation syntax
by Kevin Wu Won 19 Jul '13

19 Jul '13

While Boost Variant is a wonderful library that fills a genuine hole in the C++ language, it is not as nice to use as it could be. The "correct" way to unwrap a variant is to apply a static visitor, but this method carries a high syntactic burden because it needs the user to define a class (probably somewhere far away) just so they can "switch" on the type of the object stored in the variant. I came up with a solution where the handler functions can be specified inline with C++11 lambdas. Here's an example: boost::variant< int, std::string > u("hello world"); int result = match(u, [](int i) -> int { return i; }, [](const std::string & str) -> int { return str.length(); }); The `match` function accepts the variant followed by the handler functions. The functions can be specified in any order. It will fail to compile if the functions do not match the types of the variant, if the return types are not all the same, or if a non-unary function is supplied. This is C++11 only because it's quite pointless without lambda functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, which can't handle the variadic templates. Here's the code: https://github.com/exclipy/inline_variant_visitor What do you think? This started out for me as an exercise to learn template metaprogramming and C++11, but hopefully, it can actually evolve into something useful.

7 8

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[TypeErasure] references
by Chapman, Alec 10 May '13

10 May '13

Hi Steven, I have a somewhat-generic type erasure class that I would like to switch to yours. The main difficulty I can see is in the way capturing by reference is handled. The approach I take in my class is to pass a boost::reference_wrapper to the constructor: typedef mpl::vector<copy_constructible<>, type_id_<>, incrementable<> > requirements; int i = 0; any<requirements> x(boost::ref(i)); // capture i by reference ++x; // i == 1 any<requirements> y(x); // makes a copy of i ++y; // i == 1, any_cast<int>(y) == 2 My motivation is that I have a bunch of template functions already written that I often call directly, but in other cases I need to compile them separately by instantiating them with any<...>: ---------------------- module 1 ------------------------- // some long algorithm that I don't want to modify to be aware of any<...> template<class T> void f(T& t) { ++t; T t2 = t; ++t2; // do something with t2 } // make a type-erased version for separate compilation void any_f(any<requirements>& x) { return f(x); } -------------------- module 2 ---------------------------- // provide a thin wrapper that applies type erasure before calling any_f template<class T> void f_fwd(T& t) { any<requirements> x(boost::ref(t)); any_f(x); } // some function that needs to call f void g(int& i) { // do something with i... // then pass it to f f_fwd(i); } Is something like this possible with your method? Are there advantages that I'm not seeing to having the type signature contain information about whether the object is held by reference? Thanks, Alec

3 6

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

Fwd: [Thread] Solution to conflict with MFC?
by Thorsten Ottosen 28 Feb '13

28 Feb '13

Hi Thread maintainers, Anthony speaks about a patch to make this work. Does anyone know where it is? And could it be applied? Thanks -Thorsten -------- Original Meddelelse -------- Subject: [Thread] Solution to conflict with MFC? Date: Tue, 26 Apr 2011 13:28:56 +0200 From: Christian Larsen <contact(a)dword.dk> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Newsgroups: gmane.comp.lib.boost.user Hello, I know this has been asked before, but I could not find a good solution. I'm experiencing problems with an application using both MFC and Boost.Thread. Specifically the assertion ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); in AfxCoreInitModule() fails. I link Boost.Thread statically into a DLL in my project. From previous posts to this list and elsewhere, e.g. http://lists.boost.org/boost-users/2009/04/46929.php, I see that the issue is caused by setting _pRawDllMain in tss_pe.cpp. Commenting this line does "solve" the problem, but I would rather not have to hack the Boost source code this way. It seems there is a patch somewhere for this problem (referred to in http://lists.boost.org/boost-users/2009/04/47015.php) but it appears it never made it into the source. Is there any chance of this issue being solved in a better way? Best regards, Christian Larsen

5 9

[multi_index] Move Semantics
by Mark Snelling 27 Feb '13

27 Feb '13

Hi, I've been a user of Boost.MultiIndex for a number of years and think it's a great library. Is there any firm plan to add move semantics? It's been noted under "Future Work" in the docs since Boost 1.32. Regards, Mark

6 10

[Lockfree] ringbuffer
by Rich E 17 Feb '13

17 Feb '13

First off, all Boost.Lockfree tests in trunk are passing for me on clang 4.0 on OS X, hurrah! Thank you Tim for working on this for so long... I'm running through the examples now, only with the outdated documentation as a guide (more than a couple years old). I cannot find the ringbuffer container - was it renamed or removed altogether during the review period? I notice spsc_queue acts awefully like a ringbuffer, and it's implementation contains many

2 6

[fixed_point] Request for interest in a binary fixed point library
by Vicente J. Botet Escriba 02 Feb '13

02 Feb '13

Hi, the recent discussion on the MultiplePrecission Arithmetic library has show that some people has its ow fixed point library. Is there an interest in a Boost library having as base http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html? I have started a prototype http://svn.boost.org/svn/boost/sandbox/fixed_point (there is no doc yet but the basic goal is quite close to the N3352 C++ proposal). This prototype should allow you to play a little bit with. If yes, what would you like to be changed, added or improved in n3352? Next follows some design decisions that IMO need to be decided before hand. * Should integers and reals be represented by separated classes? * Should signed and unsigned be represented by separated classes? * Should the library use a specific representation for signed numbers (separated sign, 2-complement? Let the user choose? * Should the library provide arbitrary range and resolution and allocators? * Should the library be open to overflow and rounding or just implement some of the possible policies? and in this case which ones? * Should fixed_point be convertible to/from integer/float/double? * Could the result of an arithmetic operation have more range and resolution than his arguments? * Is there a need for a specific I/O? * is there a need for radix other than 2 (binary)? * Should the library implement the basic functions, or should it imperatively implement the C++11 math functions? Could a first version just forward to the c++11 math functions? * Should the library support just one of the know ways to name a fixed-point, a U(a,b), nQm, ...? Provide some ways to move from one to another? * Could expect the same/better performances respect to hand written code? * What should be the size used by a fixed_point instance? _fast? _least? Should the user be able to decide which approach is better for his needs? * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp? ... * others you can think of. Please, replay if you are interested, have some experience in the domain, good ideas, .. Best regards, Vicente

6 44

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

Using c++11 features in clang
by Marshall Clow 10 Dec '12

10 Dec '12

In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html I don't know if this should be a FAQ entry for Boost, or for clang. Suggestions/comments/edits welcome. -- 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

3 3

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[build] 1.49 unable to bootstrap boost
by yuri kilochek 12 Sep '12

12 Sep '12

Not sure if this goes here. On Windows 7, when I try to do bootstrap on a freshly unzipped boost 1.49 at the root directory, I get the following output: Building Boost.Build engine But that is as far as it gets before os terminates whatever it is doing with this (roughly translated from russian): **** STACK SIZE EXCEEDED **** **** WHILE PERFORMING RECURSION IN BATCH MODE **** Recursion depth=654, Stack usage=90 percent. **** BATCH PROCESSING ABORTED **** Is there a way to build boost bypassing this?

4 3

[Variant] C++11 variadic template implementation
by Florian Goujeon 11 Sep '12

11 Sep '12

Hi Boosters, I'd like to know if anybody were working on a C++11 version (using variadic templates) of Boost.Variant. I currently use the 'classic' version in my project, but since I need more-than-20-type variants, the compilation take a lot of time (extending the number of types that variant can support forces you to disable the use of precompiled headers). Plus, I'll need to use 70 type variants (MPL lists are physically limited to 50 types). If nobody has started to implement such a version yet, I'd be pleased to contribute. I've written an implementation. It's incomplete and far from perfect, but it could (hopefully) be a viable working basis.

6 16

[intrusive] patch to resolve compiler error for WinCE
by David Deakins 09 Sep '12

09 Sep '12

Hi Ion, I had a little bit of time to look into the compile error mentioned in ticket 6841 and determine a patch from detail/mpl.hpp that I think should resolve it. The patch is attached to that Trac ticket, although I could also just go ahead and apply it if you like. Thanks, -Dave

2 1

[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

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

[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

[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

[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

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

[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

[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

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

[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

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

[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

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

Running the regression tests
by Sergey Cheban 12 Jul '12

12 Jul '12

On 09.07.2012 10:26, Tim Blechmann wrote: > .... there are still some test failures on win32, but i think i found > the reason and fixed the tests (btw it is rather time consuming to > work with the test farm as the win32 tests are only run about once a > week). I'm trying to setup the regression tests on our build server and I have some problems with specifying the toolset(s). The command line is: C:\Python27\python.exe run.py --runner=MSVC9_x64_DoctorWeb --toolsets=msvc-9.0 --bjam-options=architecture=x86 --bjam-options=address-model=64 --tag=branches/release --force-update --bjam-options="-j 10" In the bjam.log, I see: warning: No toolsets are configured. warning: Configuring default toolset "msvc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: [msvc-cfg] msvc-10.0 detected, command: 'C:\program files (x86)\microsoft visual studio 10.0\VC\bin\cl.exe' notice: [msvc-cfg] msvc-9.0 detected, command: 'C:\program files (x86)\microsoft visual studio 9.0\VC\bin\cl.exe' notice: will use 'C:\program files (x86)\microsoft visual studio 10.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-10.0 notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>32', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>32', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_amd64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_amd64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>ia64/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_ia64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>ia64/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_ia64 >nul ' C:/Users/BoostTest/Release/tools_bb/build\feature.jam:308: in implied-subfeature from module feature error: "9.0" is not a known subfeature value of <toolset>msvc C:/Users/BoostTest/Release/tools_bb/build\feature.jam:491: in validate-value-string from module feature C:/Users/BoostTest/Release/tools_bb/build\feature.jam:358: in expand-subfeatures-aux from module feature C:/Users/BoostTest/Release/tools_bb/build\feature.jam:419: in feature.expand-subfeatures from module feature C:/Users/BoostTest/Release/tools_bb/build\build-request.jam:20: in apply-to-property-set from module build-request C:/Users/BoostTest/Release/tools_bb/kernel\modules.jam:103: in modules.call-in from module build-request C:/Users/BoostTest/Release/tools_bb/util\sequence.jam:48: in sequence.transform from module sequence C:/Users/BoostTest/Release/tools_bb/build\build-request.jam:32: in build-request.expand-no-defaults from module build-request C:/Users/BoostTest/Release/tools_bb\build-system.jam:630: in load from module build-system C:\Users\BoostTest\Release\tools_bb/kernel\modules.jam:283: in import from module modules C:\Users\BoostTest\Release\tools_bb/kernel/bootstrap.jam:142: in boost-build from module C:\Users\BoostTest\Release\boost\boost-build.jam:17: in module scope from module What am I doing wrong? -- Sergey Cheban

3 3

[trac] Version defaults to 1.51
by Daniel James 12 Jul '12

12 Jul '12

Hi, When you create a new ticket, the version is set to 1.51 by default, which hasn't been released yet. It should be set to 1.50, can someone change it please? thanks, Daniel

1 0

[Algorithm] Incorrect behavior of is_sorted_until (predicate version)
by Michel Morin 12 Jul '12

12 Jul '12

Hi Marshall, Suppose we have an array int ar[5] = {1, 2, 2, 2, 2}; Then, `is_sorted_until(ar, ar + 5, std::less<int>())` should return `ar`'s end pointer. But it gives `ar + 2`. To fix this, change line 49 of is_sorted.hpp if ( !p ( *first, *next )) return next; to if ( p ( *next, *first )) return next; After fixing it, don't forget to change the predicate used in non-predicate version of is_sorted_until ;) Spotted by "clang-cxx11-r159746" test runner. Regards, Michel

2 1

[lockfree] include into 1.51?
by Tim Blechmann 11 Jul '12

11 Jul '12

hi all, especially release managers, boost.lockfree is now in trunk and it passes the tests on most supported platforms. atm it includes a private copy of boost.atomic, which will be removed once boost.atomic is merged (helge wanted to do it quite soon) ... there are still some test failures on win32, but i think i found the reason and fixed the tests (btw it is rather time consuming to work with the test farm as the win32 tests are only run about once a week). iac, the deadline for new libraries in 1.51 is today, but from my side, boost.lockfree could be included as it is now. however if the release managers consider it as too late, i'm don't have a problem with waiting for another release cycle ... thoughts? tim

5 29

Who runs the Cray test runner?
by Paul A. Bristow 11 Jul '12

11 Jul '12

I note that the Cray tests are all failing. Concerned that this is possibly (though I think not entirely from look of error messages) due to changes I have made to Boost.Test recently, I'd like to contact whoever manages the Sandia Cray test runner. Does anyone know who to contact? Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 2

[container] Forward declarations for scoped allocator traits
by Daniel James 11 Jul '12

11 Jul '12

Hi Ion, I was just looking at the scoped allocator support. A container currently needs to include all of scoped_allocator.hpp just to customize the appropriate traits which seems a bit much. Could you declare (not define) constructible_with_allocator_suffix and constructible_with_allocator_prefix in a separate header so that they can be specialised without including all the other things? I've also attached a patch that fixes a couple of typos that I noticed. Daniel

2 2

[config] Add BOOST_NO_RANGE_BASED_FOR macro?
by Beman Dawes 10 Jul '12

10 Jul '12

I'm about to add Boost.Filesystem support for C ++11 range-based for statements, and would like to include direct test cases for compilers that have the feature. Is it OK to add a BOOST_NO_RANGE_BASED_FOR macro to trunk? --Beman

7 19

[xpressive] Compiler error on VC7.1
by Robert Dailey 10 Jul '12

10 Jul '12

Hi, I'm using Boost 1.49 Xpressive on VC7.1. When I compile the following code, I get compiler errors (these do not appear on VC9): sregex const& rex = bos >> _serverName >> !as_xpr("_GWDomino") >> ".diagnostics" >> *(as_xpr(".base")|".renamed"); 'rex' is really a function parameter in my real world use case. I'm passing the entire static regex into a function that takes a 'sregex const&'. I get the compiler error below. Anyone know why this is happening? C:\Code\work\cmake-decomp\build-vc7\third_party\boost\1.49.0-stlport-5.2.1\include\boost\proto\traits.hpp(691) : error C2664: 'boost::proto::exprns_::expr<Tag,Args,Arity>::expr(const boost::proto::exprns_::expr<Tag,Args,Arity> &)' : cannot convert parameter 1 from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity> &' with [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] and [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] Reason: cannot convert from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity>' with [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] No constructor could take the source type, or constructor overload resolution was ambiguous \Code\work\cmake-decomp\server\exchange\tools\uploadlog\uploader.cpp(1372) : see reference to function template instantiation 'const boost::add_const<T>::type boost::proto::functional::as_expr<>::operator ()<char,10>(const char (&)[10]) const' being compiled with [ T=boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::result_type ]

3 18

[thread][chrono][system] fails to compile with -fno-exceptions
by Vicente J. Botet Escriba 10 Jul '12

10 Jul '12

Hi, I'm trying to make Boost.Thread work when -fno-exceptions is defined and I getting a lot of errors on Boost.System cd libs/system/build bjam toolset=darwin-4.7.0 -j4 cxxflags="-fno-exceptions" define=BOOST_NO_EXCEPTION darwin.compile.c++ ../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o ../../../libs/system/src/error_code.cpp: In member function ‘virtual std::string {anonymous}::generic_error_category::message(int) const’: ../../../libs/system/src/error_code.cpp:149:10: error: expected ‘catch’ before ‘(’ token ../../../libs/system/src/error_code.cpp:149:12: error: expected type-specifier before ‘sz’ ../../../libs/system/src/error_code.cpp:149:12: error: exception handling disabled, use -fexceptions to enable ../../../libs/system/src/error_code.cpp:149:15: error: expected ‘)’ before ‘>’ token ../../../libs/system/src/error_code.cpp:149:15: error: expected ‘{’ before ‘>’ token ../../../libs/system/src/error_code.cpp:149:15: error: expected primary-expression before ‘>’ token ../../../libs/system/src/error_code.cpp:149:29: error: expected ‘;’ before ‘)’ token In file included from ../../../libs/system/src/error_code.cpp:19:0: ../../../boost/system/error_code.hpp: At global scope: ../../../boost/system/error_code.hpp:214:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] ../../../boost/system/error_code.hpp:215:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] ../../../boost/system/error_code.hpp:216:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] "/usr/local/gcc-4-7-svn/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -gdwarf-2 -fexceptions -fPIC -fno-exceptions -DBOOST_ALL_NO_LIB=1 -DBOOST_NO_EXCEPTION -DBOOST_SYSTEM_DYN_LINK=1 -I"../../.." -c -o "../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o" "../../../libs/system/src/error_code.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o... ...skipped <p../../../bin.v2/libs/system/build/darwin-4.7.0/debug>libboost_system.dylib for lack of <p../../../bin.v2/libs/system/build/darwin-4.7.0/debug>error_code.o... ...failed updating 1 target... After applying this patch the library builds Index: ../../../libs/system/src/error_code.cpp =================================================================== --- ../../../libs/system/src/error_code.cpp (revision 79245) +++ ../../../libs/system/src/error_code.cpp (working copy) @@ -133,7 +133,9 @@ } } std::string msg; +# ifndef BOOST_NO_EXCEPTIONS try +# endif { msg = ( ( result == invalid_argument ) ? "Unknown error" : bp ); } cd libs/chrono/build bjam toolset=darwin-4.7.0 -j4 cxxflags="-fno-exceptions" define=BOOST_NO_EXCEPTION darwin.compile.c++ ../../../bin.v2/libs/chrono/build/darwin-4.7.0/debug/threading-multi/process_cpu_clocks.o In file included from ../../../boost/chrono/detail/inlined/process_cpu_clocks.hpp:21:0, from ../../../libs/chrono/src/process_cpu_clocks.cpp:17: ../../../boost/system/system_error.hpp: In member function ‘virtual const char* boost::system::system_error::what() const’: ../../../boost/system/system_error.hpp:73:16: error: exception handling disabled, use -fexceptions to enable After applying this patch Index: ../../../boost/system/system_error.hpp =================================================================== --- ../../../boost/system/system_error.hpp (revision 79245) +++ ../../../boost/system/system_error.hpp (working copy) @@ -21,7 +21,7 @@ class BOOST_SYMBOL_VISIBLE system_error : public std::runtime_error // BOOST_SYMBOL_VISIBLE is needed by GCC to ensure system_error thrown from a shared - // library can be caught. See svn.boost.org/trac/boost/ticket/3697 + // library can be caught. See svn.boost.org/trac/boost/ticket/3697 { public: system_error( error_code ec ) @@ -61,13 +61,17 @@ { if ( m_what.empty() ) { +#ifndef BOOST_NO_EXCEPTIONS try +#endif { m_what = this->std::runtime_error::what(); if ( !m_what.empty() ) m_what += ": "; m_what += m_error_code.message(); } +#ifndef BOOST_NO_EXCEPTIONS catch (...) { return std::runtime_error::what(); } +#endif } return m_what.c_str(); } I get darwin.link.dll ../../../bin.v2/libs/chrono/build/darwin-4.7.0/debug/threading-multi/libboost_chrono.dylib Undefined symbols for architecture x86_64: "boost::throw_exception(std::exception const&)", referenced from: boost::chrono::chrono_detail::steady_full_ec(boost::system::error_code&) in chrono.o boost::chrono::steady_clock::now(boost::system::error_code&) in chrono.o boost::chrono::process_real_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_user_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_system_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o Does this mean that the user needs to link with a static library? Is there a way to provide a dynamic library for Boost.Chrono if it is up to the user to define boost::throw_exception? Is there a possibility that Boost.System support this mode? BTW, an alternative to redefine the the what function is to pass the string at the construction of the exception. Best, Vicente

1 1

date_time fixes.
by GAURAV GUPTA 10 Jul '12

10 Jul '12

Hi Marshall, I have raised 3 tickets 7111,7112,7113 for some issues in date_time. As the owner of date_time is not active and my earlier bug in date_time was verified by you. So Please verify and commit these bugs also. Thanks. -- Regards, Gaurav

1 0

Trac Errro
by Olaf van der Spek 10 Jul '12

10 Jul '12

Hi, https://svn.boost.org/trac/boost/browser/trunk/boost/algorithm/wrappers.hpp… says "No handler matched request to /browser/trunk/boost/algorithm/wrappers.hpp" https://svn.boost.org/trac/boost/changeset/79385 What went wrong? -- Olaf

3 5

[chrono] time_point.hpp depends on Boost.System; should it?
by Krzysztof Czainski 09 Jul '12

09 Jul '12

Hello, I want to create my own clock class, and in it among other things I would like to typedef a time_point<...>. struct MyClock { typedef int64_t rep; typedef boost::milli period; typedef boost::chrono::duration<rep,period> duration; typedef date_chrono::time_point<SystemClock,duration> time_point; static bool const is_monotonic = false; static time_point now(); }; Now, for this to work I obviously need to #include <boost/chrono/time_point.hpp>. Including it causes a dependency on Boost.System, making me have to link with it. But since I don't use any clocks provided by Boost.Chrono, I think the dependency on Boost.System is unnecessary. In fact, I was able to get rid of the dependency, and everything seems to work. I commented out 1 line from <boost/chrono/time_point.hpp>: //#include <boost/chrono/detail/system.hpp> Could this #include be removed from time_point.hpp, or is it needed for something I am not using ATM? Regards, Kris

2 5

[interprocess]
by Joseph Van Riper 09 Jul '12

09 Jul '12

I am either having some problems with the documentation, or I've stumbled into a bug in Boost.Interprocess's named_condition. I'm compiling on VC++ 2010, 32 or 64 bit, with 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; } I get the following compiler errors: 1>------ Build started: Project: TestInterprocess, Configuration: Debug Win32 ------ 1>Build started 09-Jul-12 11:45:22 AM. 1>InitializeBuildStatus: 1> Touching "Debug\TestInterprocess.unsuccessfulbuild". 1>ClCompile: 1> All outputs are up-to-date. 1> TestInterprocess.cpp 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 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:05.97 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== I am lead to believe that I should used a named_mutex by the documentation here: http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_cond… which states in the description that "This condition variable is designed to work with named_mutex and can't be placed in shared memory

1 0

[1.51][Release] Short release cycle
by Daniel James 08 Jul '12

08 Jul '12

Hello everyone, Just a quick warning that due to the delay releasing 1.50, the 1.51 release cycle is going to be a lot shorter than normal. It's a little under 2 months until the scheduled 1.51 release date. This means that the deadlines are pretty soon. If you haven't checked it yet, please take a look at the calendar at: http://www.boost.org/community/ The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon. thanks, Daniel

21 54

[trunk] bootstrap failure
by Tim Blechmann 08 Jul '12

08 Jul '12

hi, just moved my boost source tree from one hd to another. trying to bootstrap leads to: Building Boost.Build engine with toolset gcc... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details the bootstrap.log contains: rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c function.c: In function ‘argument_list_print’: function.c:3126:17: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘struct OBJECT *’ [-Wformat] ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean Segmentation fault (core dumped) any idea? tim

2 2

[lockfree/win32] looking for help
by Tim Blechmann 08 Jul '12

08 Jul '12

hi all, i've been trying to sort out some compile problems of boost.lockfree, but now i find myself in a position that for some reasons, the tests on on the windows platform fail ... not only with msvc, but also with gcc/mingw. the main problem that i have is that two test cases compile, but fail at runtime ... unfortunately the error messages are not necessarily expressive: mingw: -- Run [2012-07-04 16:08:25 UTC]: fail EXIT STATUS: -1073741819 -- msvc: -- Running 8 test cases... unknown location(0): fatal error in "spsc_queue_test_buffering": stack overflow ..\libs\lockfree\test\spsc_queue_test.cpp(435): last checkpoint: "spsc_queue_test_buffering" entry. *** 1 failure detected in test suite "Master Test Suite" EXIT STATUS: 201 -- i am pretty clueless, what is happening there ... would it be possible that someone who has a win32 machine can send me a backtrace of this crash? thanks, tim

2 3

[Lockfree] examples with clang
by Rich E 08 Jul '12

08 Jul '12

Hi all, I've been attempting to test Lockfree (while at the same time learning to work with boost from trunk, so bare with me I'm a bit new) using Clang 4.0, the version that will ship with Xcode 4.5. It appears that the preprocessor check is only for gcc. If I change: #if __cplusplus < 201103L to #if __cplusplus < 201103L && ( defined( __clang__ ) && ! __has_include(<atomic>) ) and compile the examples with (from libs/lockfree/examples): ../../../bjam toolset=clang cxxflags="-std=c++0x -stdlib=libc++" linkflags="-stdlib=libc++" Then the examples work correctly (queue output: "produced 40000000 objects. consumed 40000000 objects."). I'm sure there is a more elegant way to check for libc++ existence when compiling with clang, possibly with boost/config.hpp? Also, I think a message in the dummy main would be nice to inform the user that lockfree won't work with their current setup / compile method. Cheers, Rich

2 1

[context] a couple of build fixes for Solaris (10)
by Luke Elliott 07 Jul '12

07 Jul '12

First is to get the definition of mprotect() that takes void * rather than char * by defining _XPG4_2, which causes a compilation failure with Solaris Studio 12.3. Second is a workaround for a bug in their csignal header which uses the same include guard that signal.h uses, which csignal includes (leaving SIGSTKSZ undefined). Attached if of any help. Regards Luke Elliott.

3 3

memory leak in fileiter.cpp
by GAURAV GUPTA 07 Jul '12

07 Jul '12

There is a possible memory leak in fileiter.cpp in Regex component. I have raised a ticket https://svn.boost.org/trac/boost/ticket/7084 along with the patch. Please verify and commit it. -- Regards, Gaurav

1 0

[gil::io_new] Help with gcc compiler
by Christian Henning 07 Jul '12

07 Jul '12

Hi there, I'm in the process of making my gil extension ready for inclusion. The code is now stable and I'm trying to get gcc/clang to work. Since I'm no expert with gcc I would like to ask for some help with various compiler errors. Could someone get the latest from here: http://gil-contributions.googlecode.com/svn/trunk/gil_2 and try to compile the following code: ------------------- #include <boost/gil/extension/io_new/bmp_all.hpp> using namespace std; using namespace boost::gil; int main() { { const char* bmp_filename = ""; const char* bmp_out = ""; rgb8_image_t img; read_image( bmp_filename, img, bmp_tag() ); write_view( bmp_out + "all_formats_test.bmp", view( img ), bmp_tag() ); } } ----------------- It should generate some errors which I don't quite understand. I have posted the errors here: http://pastebin.com/Wps3YH1N I'm using gcc 4.4.1 . The complete test suite compiles with Visual Studio 2010 without any warnings. Thanks a lot! Christian

5 10

noncopyable && C++11
by Ben Pope 06 Jul '12

06 Jul '12

Hi all, boost::noncopyable interferes with the implicit generation of move construction and move assignment, so I was wondering if anybody had any thoughts on something like this: class noncopyable { protected: noncopyable() = default; noncopyable(noncopyable&&) = default; noncopyable& operator=(noncopyable&&) = default; noncopyable(noncopyable const&) = delete; noncopyable& operator=(noncopyable const&) = delete; }; Which would replace the existing technique when C++11 support is on. I guess it could be argued that non copyable should imply non moveable. However, you won't hear me defending that position; plenty of thought went into move semantics with the defaults chosen to have sa[f|n]e behaviour. The derived class will still be subject to that criteria, I'm just trying to prevent noncopyable from artificially inhibiting move semantics. Would anybody want nonmovable? nonmoveable? Any thoughts / comments / omissions gratefully received. Ben

2 2

[iostreams] cin wrapper
by Daniel Larimer 06 Jul '12

06 Jul '12

I am attempting to 'wrap' std::cin such that all 'blocking' occurs in a dedicated 'cin' thread. This is required because in a cooperatively scheduled thread, no fiber can call cin and block. So I went about attempting a boost::iostreams::source: class cin_source : public boost::iostreams::source { streamsize read( char* s, streamsize n ) { if( n == 0 ) return n; auto r = std::cin.readsome(s,n); if( r <= 0 ) { // post read request to another thread. // cooperatively wait for it to finish... return n; } return r; } }; The problem I have is that this code causes read to be called with 'n == 0'; boost::iostreams::stream<cin_source> my_cin; char buf[100]; my_cin.read( buf, 100 ); It doesn't matter how I attempt to read from the stream, n always equals 0. What am I doing wrong? Dan

1 0

[format] Any interest in decoupling it from std::basic_string?
by news.gmane.org 06 Jul '12

06 Jul '12

I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.

5 11

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[exception] [type_traits] warning: unrecognized #pragma GCC system_header
by Krzysztof Czainski 06 Jul '12

06 Jul '12

Hello, Below is a list of files, that contain: #if defined(__GNUC__) #pragma GCC system_header #endif which causes a warning on my TI compiler. E:\boost\include\boost-1_50_0\boost\exception\all.hpp E:\boost\include\boost-1_50_0\boost\exception\current_exception_cast.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\error_info_impl.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\exception_ptr.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\is_output_streamable.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\object_hex_dump.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\type_info.hpp E:\boost\include\boost-1_50_0\boost\exception\diagnostic_information.hpp E:\boost\include\boost-1_50_0\boost\exception\errinfo_errno.hpp E:\boost\include\boost-1_50_0\boost\exception\exception.hpp E:\boost\include\boost-1_50_0\boost\exception\get_error_info.hpp E:\boost\include\boost-1_50_0\boost\exception\info.hpp E:\boost\include\boost-1_50_0\boost\exception\info_tuple.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string_stub.hpp E:\boost\include\boost-1_50_0\boost\throw_exception.hpp E:\boost\include\boost-1_50_0\boost\type_traits\is_virtual_base_of.hpp In other files, i.e. boost\integer.hpp, I've found this #pragma guarded against __GNUC__ >= 4: #if defined(__GNUC__) && (__GNUC__ >= 4) #pragma GCC system_header #endif which doesn't cause a warning on my compiler, because it defines __GNUC__ to 3. Could this be fixed in the files on the list above, or are there some __GNUC__ 3 compilers, that need this pragma to be enabled? Regards, Kris

3 5

[1.50.0] Release candidates available for testing
by Beman Dawes 05 Jul '12

05 Jul '12

Release candidate files for 1.50.0 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. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

Re: [boost] [cfe-dev] Using c++11 features in clang
by Marshall Clow 05 Jul '12

05 Jul '12

On Jul 5, 2012, at 12:41 PM, Joseph Galbraith wrote: > On 07/05/2012 12:29, Marshall Clow wrote: >> In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: >> http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html >> >> I don't know if this should be a FAQ entry for Boost, or for clang. >> Suggestions/comments/edits welcome. > > Isn't one of both of -std=c++11 and -stdlib=libc++ an ABI change? > > If so, it should probably be noted that all code should be build with > the same settings for these flags. Yes. > In particular, I think that you can't pass a std:: classes from libstdc++ > built code to libc++ code without bad things happening. I would expect that also, but libc++ has versioned namespaces that _should_ prevent that from happening (I.e, cause linker errors). > I'm not sure whether just turning whether the following is safe or not: > > clang++ -c -stdlib=libc++ x.cpp > clang++ -c -stdlib=libc++ -std=c++11 y.cpp > clang++ -stdlib=libc++ x.o y.o I would expect either: * It would "just work" * It would fail to link depending on what the contents of x.cpp and y.cpp were. If you can come up with a good way of explaining this, I'll be happy to add it to my post. -- 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

1 0

[interprocess] Problem building i386 binary on x86_64 MacOSX machine
by Walter Horsten 05 Jul '12

05 Jul '12

Hello, I have a program that uses boost::interprocess::message_queue, it used to compile correctly as a universal binary (i386 & x86_64) with boost version 1.47, however compiling for i386 fails with version 1.49 and 1.50. The most important parts of the error message are: - no matching function for call to 'boost::interprocess::message_queue_t<boost::interprocess::offset_ptr<void, int, long unsigned int, 0u> >::try_receive(void*, size_t, size_t&, unsigned int&)' - no matching function for call to 'get_rounded_size(long unsigned int, const unsigned int&)' ... is this a bug or is my code incorrect? (I suspect the size of the void* might have something to do with it?) The sample code in the attachment reproduces the problem on my MacBook Pro running OSX Snow Leopard (edit the boost prefix variable in the scripts to your own needs). Kind regards, Walter

1 0

[fusion] g++-4.6, deque, and c++0x compile error
by Karsten Ahnert 05 Jul '12

05 Jul '12

The following trivial program does not compile with g++-4.6.1 and std=c++0x enabled. #include <boost/fusion/container.hpp> int main( int argc , char *argv[] ) { } Seems like a bug, or should I configure something via macros?

3 5

[stratified] library for micro-/userland-threads
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, some of the community members ask me to provide a micro-/userland-thread library based on boost.context - I hope boost.stratified is a sufficient implementation. The library contains classes and interfaces similar to boost.thread. Examples and documentation (not finished and needs some updates/correction) is included. I hope I get some feedback from you. best regards, Oliver source: http://olk.bplaced.net/boost-stratified.zip documentation: http://olk.bplaced.net/boost/libs/stratified/doc/html/

9 24

[c++11] compile_if utility
by Lorenzo Caminiti 04 Jul '12

04 Jul '12

Hello all, I was thinking how to program assertion requirements in C++11. I need to program something like this if "has_equal_to<T>" then "assert(back() == value)" else do nothing, don't even compile "assert(back() == value)" Using C++11 lambdas, I was able to program a compile_if utility to do the following: compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); // compiled and executed iff has_equal_to<T> }); Any interest in adding compile_if to Boost.Utility? It could be renamed exec_if if compile_if is too "strong". I didn't play with compile_if much so there might cases where it doesn't work... but I wanted to share it with the ML anyway: #include <boost/type_traits.hpp> #include <cassert> #include <vector> #include <iostream> template< bool Boolean > struct compile_if_c { template< typename UnaryFunc > compile_if_c ( UnaryFunc f ) { std::cout << "compiling" << std::endl; f(); } }; template< > struct compile_if_c <false> { compile_if_c ( ... ) { std::cout << "not compiling" << std::endl; } }; template< class BooleanMetafunc, class UnaryFunc > void compile_if ( UnaryFunc f ) { compile_if_c<BooleanMetafunc::value> compile(f); } template< typename T > class vector { public: typedef typename std::vector<T>::const_reference const_reference; public: void push_back ( T const& value ) { vector_.push_back(value); compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); }); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; struct x {}; // no operator== int main ( void ) { vector<x>().push_back(x()); // no == so skip assertion back() == value vector<int>().push_back(123); // has == so assert back() == value return 0; } Thanks. --Lorenzo P.S. Eh, if C++11 lambda had constant captures [const&](){ assert(this->back() == value; } I could have even made the assertion constant-correct...

3 4

[Review Request] Inclusion of the Boost.Polygon Voronoi Library
by Andrii Sydorchuk 04 Jul '12

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. 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). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86

[ratio] error in template specialization: template parameter n1 depends on another template parameter
by Krzysztof Czainski 04 Jul '12

04 Jul '12

Hello, In order to use Boost.Ratio with my poor compiler from TI, I had to apply the attached fix. I suspect a more general fix would be desirable, should such a fix be added to Boost. However, before investigating further, I'd like to ask, if such a fix would be welcome, or is my compiler too poor to be supported by Boost.Ratio? Regards, Kris

2 3

boost.stratified -> boost.fiber
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, as requested I've renamed boost.stratified to boost.fiber. archive is avialble at : http://olk.bplaced.net/boost-fiber.zip for those in Japan, Korea, etc please use http://www.hidemyass.com/ (proxy) to circumvent http 403 from the web-hoster. regards, Oliver

1 0

[type_index] C++03 implementation in boost?
by Agustín K-ballo Bergé 03 Jul '12

03 Jul '12

After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11. It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values? I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code. Agustín K-ballo Bergé.- http://fusionfenix.com

3 6

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

Dear Boosters, I have written a Boost-compatible library for the representation and manipulation of integers of large or arbitrary size (including 128bit and above). I would like to make a preliminary submission of this library for your review and input, for potential inclusion into Boost v1.51.0 or later, as per the Boost Library Submission Process. The library and all its files are publicly available on github, at: http://github.com/mjtryhorn/Boost.LargeInt A tagged .zip of these files (v1.0.0) is available for download at: http://github.com/mjtryhorn/Boost.LargeInt/tags This library has been written for strict conformance to C++03 and the Boost coding guidelines. This library is also header-only, and as such may be directly merged into existing Boost installations without the need for recompilation. All files are distributed under the Boost Software License, Version 1.0. Now a quick explanation of why I've written this library and what it does: I have found myself on several occasions to be working with unsigned 64bit numbers, mostly for the sizes of files or C++ collections. Where I had a need to perform a calculation upon those numbers, there was often the possibility of overflow. 128bit integers would have been an appropriate fix, but these are either entirely unavailable, non-portable, or in a library which I preferred not to use either due to its complexity or incompatible licensing. Floating-point arithmetic is also a means around the problem, but is inherently inaccurate. I decided to fix this problem once-and-for-all by writing a new integer arithmetic library, making judicious use of C++'s template-metaprogramming and Boost to make my solution both as simple and as transparent as possible. Now, what started out as 128bit integers for my own use has grown into a fully- functional library which has the ability to compose any two integer or integer- like types into a new, larger, signed or unsigned integer type, including all the standard integral operators and a number of utility functions to support them. Thus, Boost.LargeInt supports not only signed and unsigned 128bit integer arithmetic but 24bit, 64bit, 160bit, 192bit, 256bit, 512bit and more. Boost.LargeInt is compatible and has been tested with the following compilers and platforms: GNU GCC 4.6.1, 4.6.2 (Linux, Ubuntu 11.10 (64bit) & openSUSE 12.1 (32bit)) Borland C++ 5.6.4 (Windows XP SP3, Borland C++ Builder 6) Microsoft Visual C++ 2010 (Windows XP SP3, Microsoft Visual Studio 2010) (I have also tried to add compatibility for Microsoft Visual C++ 6, but unfortunately this compiler's support for template-metaprogramming is insufficient and the tests for Boost.LargeInt fail to compile.) Documentation is included in BoostBook format (.qbk), but a pre-compiled version is available alongside the library code itself for your convenience. Please, if you have the time, download this library and give it a try. Any comments, or information upon its compatibility (or lack thereof) with compilers which are or are not listed would be greatly appreciated. If no-one has any comments (I think that unlikely ;-) ), then I shall resubmit this library for formal review. Thanks, Michael J. Tryhorn

9 20

CRC 16 Bit Implementation
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Hi, In my application I need to use crc_64_type. I did not find its implemetation in crc.hpp. Anyone implemented it? -- Regards, Gaurav

2 1

[range] treating N-ary function with N-1 default args as unary
by Nathan Ridge 03 Jul '12

03 Jul '12

Hi, Some Boost.Range adaptors, such as 'transformed' or 'filtered', require a unary function. The documentation does not formally define "unary function", but it's pretty clear what it ought to be: a function (object) that's callable with one argument. Thus, to me, the following is a perfectly valid unary function: int foo(int a, int b = 0); as it is callable with one argument. However, Boost.Range does not accept such a function as an argument to 'transformed' or 'filtered'. For example, the following code: #include <boost/range/adaptor/transformed.hpp> int foo(int a, int b = 0); int main() { int A[5]; A | boost::adaptors::transformed(foo); } produces the following compiler errors (recent Boost trunk, with GCC 4.7): In file included from boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from boost/utility/result_of.hpp:113, from boost/iterator/transform_iterator.hpp:23, from boost/range/adaptor/transformed.hpp:16, from test.cpp:1: boost/utility/detail/result_of_iterate.hpp: In instantiation of 'struct boost::detail::cpp0x_result_of_impl<int (* const(int&))(int, int)>': boost/utility/detail/result_of_iterate.hpp:46:8: required from 'struct boost::result_of<int (* const(int&))(int, int)>' boost/mpl/eval_if.hpp:38:31: required from 'struct boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::result_of<int (* const(int&))(int, int)>, boost::mpl::identity<boost::use_default> >' boost/iterator/iterator_adaptor.hpp:160:12: required from 'struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<int (* const(int&))(int, int)> >' boost/iterator/transform_iterator.hpp:50:17: required from 'struct boost::detail::transform_iterator_base<int (*)(int, int), int*, boost::use_default, boost::use_default>' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: recursively required from 'constexpr const bool std::__has_iterator_category_helper<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >::value' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: required from 'struct std::__has_iterator_category<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' c++/4.7.0/bits/stl_iterator_base_types.h:160:12: required from 'struct std::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/detail/iterator.hpp:81:8: required from 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp:30:75: required from 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/utility/detail/result_of_iterate.hpp:69:5: error: too few arguments to function In file included from boost/range/iterator_range_core.hpp:22:0, from boost/range/iterator_range.hpp:13, from boost/range/adaptor/transformed.hpp:15, from test.cpp:1: boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:30:75: error: no type named 'value_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_difference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:143:54: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:49:80: error: no type named 'difference_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_reference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:157:53: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:36:74: error: no type named 'reference' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' Would it be possible to treat N-ary functions with N-1 default arguments as unary? Thanks, Nate

6 8

[Trac] New components
by Daniel James 03 Jul '12

03 Jul '12

Hello, Please can someone with the appropriate trac permissions add two new components "functional/overloaded function" and "local function", both have maintainer "lcaminiti". Maybe also "utility/identity type", or does that come under "utility"? thanks, Daniel

3 4

Thread (win32) and current_thread_tls_key issues
by Pekka Seppänen 03 Jul '12

03 Jul '12

Hi, Currently Threads's Win32 TLS implementation uses a global static variable thread::current_thread_tls_key that is defined in src/win32/thread.cpp. As you may know, static variables have a tendency of not being allocated in a very specific order. Say, that you have a statically allocated class A that ends up calling thread::set_current_thread_data() (eg. uses thread::thread_specific_ptr). If compiler initializes this class before it initializes current_thread_tls_key (this did happen to me on MSVC9) things go boom: a) Compiler initializes class A, thread::set_current_thread_data() is called, thread::create_current_thread_tls_key() is called once (as expected) and ::TlsAlloc() result is stored to thread::current_thread_tls_key. b) Compiler initializes thread::current_thread_tls_key, TLS_OUT_OF_INDEXES is stored and, as you may guess, c) Any following thread::set_current_thread_data calls will fail as the proper result from ::TlsAlloc() was overwritten. Don't know why this haven't happened before, as previous versions use a static variable, too. Maybe some compilers (MSVC in this case) omit initialization code unless initial value is a non-zero (as with TLS_OUT_OF_INDEXES [0xffffffff] in this case) value. I propose that thread::current_thread_tls_key is moved to a static function that sole purpose is to return reference to that variable (and thus ensure that current_thread_tls_key is initialized before it is used for the first time). Also, move thread::current_thread_tls_init_flag to thread::set_current_thread_data() to make sure this won't happen to that, too. Attached a patch that does the above trick (did move TLS_OUT_OF_INDEXES back to a macro as otherwise the code got too cumbersome, does get undef'd unless it was already defined by Winapi). If you like it, I can submit a ticket to Trac that includes the patch. (Haven't looked what happens during destruction, but guess it's not safe to use TLS features thru Thread.) -- Pekka

4 8

memcpy handling bug in regex_raw_buffer.cpp
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Can anyone verify and commit the following Ticket: https://svn.boost.org/trac/boost/ticket/7032 -- Regards, Gaurav

2 1

Does Boost.Pool have a maintainer ?
by DUPUIS Etienne 03 Jul '12

03 Jul '12

Greetings, Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ? If there is no maintainer, can I become the maintainer ? If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs. 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 2

Priority Deque Container Adaptor
by Nathaniel McClatchey 03 Jul '12

03 Jul '12

Greetings. I have written a container adaptor implementing efficient double-ended priority queues. This preliminary submission is made to determine if/when a formal submission should be made and in the hope that it will be improved by your comments and reviews. The library (a single header file) is publicly available on mediafire: http://www.mediafire.com/download.php?gq8qjpgdoecgqq2 All files are distributed under the Boost Software License, Version 1.0. An explanation of what it does: This library replicates all functions of the STL priority_queue and adds functions for efficient access to the other end of the queue. Where the STL priority_queue uses a max-heap, I use a max-min heap (see article on Wikipedia). This leads to O(log n) complexity for single-element operations, and O(n) complexity for initialization and merging. TL;DR: Double-ended priority queue with algorithmic complexity equaling the STL single-ended priority queue. The current revision has been tested on: GCC 4.7.0 (MinGW on Windows 7 x64) Microsoft Visual C++ 2010 (on Windows 7 x64) Documentation may be generated by Doxygen. Any comments, criticisms, or compatibility information will be appreciated. I currently have one decision to make that requires experience beyond mine. Some const functions require calling operator() in a comparison class; should I make the class mutable, make a non-cost copy of the comparison class when needed, or require that operator() be a const function? So far, I have avoided the last option because it would make the class prerequisites more strict. Thanks, Nathaniel McClatchey

1 0

[1.51.0] Open for merging
by Daniel James 02 Jul '12

02 Jul '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

1 0

Is there a macro to test if std::numerc_limits<>::max_digits10 is supported by a platform?
by Paul A. Bristow 02 Jul '12

02 Jul '12

A proposed (but not reverted) fix for Trac #5758: Boost.Test Floating-point comparison diagnostic output does not support radix 10 if( std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 10 ) ostr.precision( 2 + std::numeric_limits<T>::max_digits10); // Assume that max_digits10 is provided for all radix 10 as they are quite new, // and anyway Kahan formula will not work for decimal. has caused trouble on platforms that do not yet support std::numeric_limits<T>::max_digits10 We need a macro perhaps BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 that will prevent the compiler seeing this code if max_digits10 is not supported. Do I need to add a default for all compilers # define BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 and then undefine for compilers that DO support #if defined (_MSC_VER >=1600) || (... other compilers that DO support) # undef BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 #endif Can anyone advise compiler versions or library versions that DO support max_digits10? Suggestions? Paul PS maxdigits10 will become more useful generally as the wrong value in float in MSVC 2011 seems to be corrected in Microsoft Visual Studio Ultimate 2012 RC 11.0.50522.1 --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 4

[contract] C++11-like auto-functions
by Lorenzo Caminiti 02 Jul '12

02 Jul '12

Hello all, I'm thinking to expand Boost.Contract to support C++11-like auto-functions for C++03. The following macro: CONTRACT_FUNCTION( // f template( typename Left, typename Right ) auto (adding_func) ( (Left const&) left, (Right const&) right ) return(BOOT_TYPEOF_TPL(left + right)) ) { return left + right; } Would expand to something like the code below (but the main of course): #include <boost/typeof/typeof.hpp> #include <iostream> template< typename Left, typename Right > // TPARAMS(f) struct adding_func_result_123 { Left const& left; // PARAMS(f) Right const& right; // PARAMS(f) typedef BOOST_TYPEOF_TPL(left + right) // RESULT_TYPE(f) type ; }; template< typename Left, typename Right > typename adding_func_result_123<Left, Right>::type // TPARAMS(f) adding_func ( Left const& left, Right const& right ) { return left + right; } int main ( void ) { std::cout << adding_func(1, 2) << std::endl; return 0; } I got a ticket for it: https://sourceforge.net/apps/trac/contractpp/ticket/59 But I might implement it only after the Boost review... (Are C++11 auto-function really useful?) Thanks. --Lorenzo

3 2

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

Message-ID: <loom.20120702T032954-809(a)post.gmane.org> Hi Andrew, Would you be able to provide a short summary of the advantages, disadvantages or significant differences of your proposal versus the boost multi-precision library or the C++ std decimal proposal? Regards, Josh. The std decimal proposal seems to centre *IEEE 754-2008 * *hardware or slow software. My proposal is simple to make accounting safer to similar to SQL (NUMERIC and DECIMAL) using all hardware (including * *IEEE 754-2008 for IBM) but also in embedded processors.* * * *I *terminal brain cancer so I want to keep these out 'there'. http://ajrobb.livejournal.com/6918.html "I have expressive dyspepsia caused by terminal grade 4 glioblastoma mutiforme brain cancer" so writing and talking are difficult. Regards, Andrew Robb

1 0

[thread/exception] trivial compile fix
by Tim Blechmann 02 Jul '12

02 Jul '12

the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1]. as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it? tim [1] https://svn.boost.org/trac/boost/changeset/75902

4 13

thread & 1.50 issues
by Tim Blechmann 02 Jul '12

02 Jul '12

i came across two issues of boost.thread in 1.50. the first is a minor issue: the 1.50 tarball contains a libs/thread/src/shared_mutex.cpp source file, which includes boost/thread/v2/shared_mutex.hpp, which does not exist. by default it is not built, so it is not a big problem, but it is not really clean, either. the second issue is a bit more severe, as it is an undocumented API change: boost::TIME_UTC has been renamed to boost::TIME_UTC_ ... not sure what's the reason for it, but it breaks code that used the old symbol. this includes the boost-style threadpool library [1] ... so i wonder, is this change really needed? tim [1] http://threadpool.sourceforge.net

2 2

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

I am proposing a Boost library for exact decimal numbers https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…<https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…> Message-ID: <33DFA071B6DD6D4FB44851BDE4A7259317128A(a)xchmbbal503.ds.susq.com> Andrew Robb wrote: > > Introduction [snip] > Exact Decimal [snip lots of information and reference links] The reason for your post is unclear. Are you proposing a Boost library? Are you asking for an indication of interest?

2 1

[geometry] distance on multiline with spherical coordinates
by Karsten Ahnert 01 Jul '12

01 Jul '12

Hi, the following code produces some strange results: typedef cs::spherical_equatorial< boost::geometry::degree > cs_type; typedef model::point< double , 2, cs_type > point_type; typedef model::linestring< point_type > linestring_type; point_type p( 1.0 , 1.0 ); linestring_type l; l.push_back( point_type( 0.0 , 2.0 ) ); l.push_back( point_type( 2.0 , 2.0 ) ); l.push_back( point_type( 4.0 , 2.0 ) ); cout << "Distance : " << boost::geometry::distance( p , l ) << endl; for( size_t i=1 ; i<l.size() ; ++i ) { linestring_type l_tmp; l_tmp.push_back( l[i-1] ); l_tmp.push_back( l[i] ); cout << "Point distance : " << boost::geometry::distance( p , l_tmp ) << endl; } The output is Distance : 0.0174373 Point distance : 0.0174586 Point distance : 0.0174373 This looks like a bug. The distance to the second segment can not be smaller than that to the first one. If I change the coordinate system to cartesian coordinates everything works as expected. Do I miss some major points?

2 7

boost::locale throw exception std::bad_cast
by Alex Ivanov 01 Jul '12

01 Jul '12

Here is code sample: boost::locale::generator gen; std::string text="To be or not to be, that is the question." ssegment_index map(word,text.begin(),text.end(),gen("en_US.UTF-8")); last line throw exception std::bad_cast The tests was made on tthe hosts: Darwin mac-os 10.4.0 Darwin Kernel Version 10.4.0 (gcc version 4.2.1) Linux fedora 2.6.34.9-69.fc13.x86_64 (gcc version 4.8.0 ) Linux fedora 2.6.34.7-66.fc13.x86_64 (gcc version 4.4.5) Linux debian 2.6.32-5-amd64 (gcc version 4.7.0) with boost_1_50_0_beta1 How can I handle this? -- реклама ----------------------------------------------------------- Распродажа % модной одежды. Скидки до 70%. Количество ограниченно! Подробнее на сайте Bonprix http://goo.gl/1qLK1

2 1