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

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

[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

[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

[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

[#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

[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

[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

[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

[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

[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

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

[Locale] VC11 Regressions
by Joshua Boyce 18 Jun '12

18 Jun '12

I am currently porting some code to the VC11 compiler beta, and as part of that process I ran the unit tests on the libraries I use and noticed some failures in Boost.Locale under VC11 that are not present under VC10. Ones of the tests (test_winapi_collate) actually crashes (showing the WER dialog etc). Logs for comparison (tests were run on trunk): http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc10-20120330-2143… http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc11-20120330-2143… Has anyone else observed this or is it a configuration issue on my end?

4 11

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[fusion] Trouble using BOOST_FUSION_ADAPT_ADT with boost::fusion::operator<
by GOODHART, TAYLOR 17 May '12

17 May '12

Hi all, I'm attempting to adapt a third-party struct into a fusion sequence using BOOST_FUSION_ADAPT_ADT to get access to a nice operator<. Unfortunately compilation fails and I'm not sure if it's a bug or me using the library incorrectly. As best I can read the error message, it looks like the code is attempting to compare adt_attribute_proxy structs instead of the values represented by these. Below is some code that demonstrates the problem. Can anybody help me out? Thanks, Taylor #include <boost/fusion/adapted/adt/adapt_adt.hpp> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/adapted/struct/adapt_struct.hpp> #include <set> #include <string> #include <boost/fusion/sequence/comparison/less.hpp> struct test1 { std::string s; const std::string & getS() const { return s; } void setS( const std::string & s_) { s = s_; } }; BOOST_FUSION_ADAPT_ADT( test1, (const std::string &, const std::string &, obj.getS(), obj.setS(val)) ) BOOST_FUSION_DEFINE_STRUCT( , test2, (std::string, s) (int, a) ) struct test3 { std::string s; }; BOOST_FUSION_ADAPT_STRUCT( test3, (std::string, s) ) using boost::fusion::operator<; int main( int argc, char * argv[]) { //Fails /*std::set<test1> destinations1; destinations1.insert(test1());*/ std::set<test2> destinations2; destinations2.insert(test2()); std::set<test3> destinations3; destinations3.insert(test3()); return 0; }

3 7

[config] 4 new C++11 macros added
by John Maddock 14 May '12

14 May '12

A long time back I was asked for a bunch of new config macros which have finally now been added: BOOST_NO_CXX11_ALLOCATOR The standard library does not provide a C++11 version of `std::allocator` in <memory>. BOOST_NO_CXX11_ATOMIC_SP The standard library <memory> does not support atomic smart pointer operations. BOOST_NO_CXX11_HDR_FUNCTIONAL The standard library does not provide a C++11 compatible version of <functional>. BOOST_NO_CXX11_SMART_PTR The standard library header <memory> has no shared_ptr and unique_ptr. Enjoy, John.

6 11

[complex] Feedback and Potential Review Manager
by Christopher Kormanyos 13 May '12

13 May '12

Hi Matthieu, I would like to provide a detailed feedback on the proposed Boost.Complex. I am terribly sorry about the late response on this, as I was not doing well in winter when this topic was more active. First of all, great work with this, Matthieu. I believe the community desperately requires this facility. Boost.Complex appears to have two main goals: A) Provide acceleration for pure imaginary numbers. B) Allow complex to be used with user-defined types. For goal B), I have briefly tested parts of the Boost.Complex code with the cpp_dec_float multiprecision data type proposed for Boost.Multiprecision by John Maddock. My Tests include: * Test some elementary transcendental functions. * Test the overall package via computation of orthogonal polynomials.* My test file (complex.cpp) is included in this e-mail. * Visual Studio 2010, SP1. * Proposed Boost.Multiprecision and boost trunk. Remarks: 1) Various functions use macros like M_PI_2. These macros do not provide enough precision for a multiprecision type. And they will be inefficient for some fixed-point types. Perhaps you need to "bite the bullet" and use boost::math::constants. (Is M_PI_2 even part of C++, or is it only lurking around in <math.h> of GCC?) 2) Ditto for the LN_10 and LN_2 constants. Does boost::math::constants support ln_ten()? I do know that it has ln_two(). 3) I disagree with explicit complex(const T& re = T(0.), const T& im = T(0.)) I believe this constructor should be non-explicit. See ISO/IEC 14882:2011, Section 26.4.2. 4) I would really like to see global operators for seamless interaction of complex<T> with integer PODs. The proposed code of boost::complex forces explicit construction from integer "all the way" to boost::complex<T> just to, for example, multiply with 2. This is extremely costly as most multiprecision or fixed-point types have specially optimized routines for multiplication with integer PODs. Perhaps something like this would be good template<typename T> complex<T> operator*(const complex<T>& z, int n) { T re(z.real()); T im(z.imag()); re *= n; im *= n; return complex<T>(re, im); } 5) In the exp() function, polar() can not be resolved without explicit template parameter. Instead of this: template<typename T> inline complex<T> exp(const complex<T>& x) { return polar(exp(x.real()), x.imag()); } I needed this: template<typename T> inline complex<T> exp(const complex<T>& x) { return polar<T>(exp(x.real()), x.imag()); } I don't know who's right here, your code or the compiler. 6) The tanh() function and some other functions compute the exponent twice. By that I mean both exp(x) as well as exp(-x). I believe that division would be faster if exp(-x) were computed with (1 / exp(x)). Or is there an issue with branch cuts that mandates the potentially redundant calculation? 7) I hope to find time to test this code further with a tiny fixed-point class. But I might be too busy for that extra work. REVIEW PROGRESS: I may potentially be qualified for review manager. I do know the math and the code. I am also well-versed with all aspects of software review, assessment and audit situations. BUTTT!!! I'm not as good at C++ as some of you folks and I'm a real beginner at boost. Nonetheless, If nobody better steps forward, I could potentially manage the review of Boost.Complex. Best regards, Chris.

8 33

[hash] Turn on BOOST_HASH_NO_IMPLICIT_CASTS by default
by Daniel James 12 May '12

12 May '12

Hello everyone, There have been occasional issues where Boost.Hash will incorrectly hash an object that doesn't have a hash function but is convertible to bool. I added an extra templated overload of hash_value which contains a static assert. The idea is that it's a better match than the implicit cast, so it will cause a compile error in this case. This is currently only activated when a macro is defined, as it could break otherwise valid code. I was a bit worried about making any interface changes because at this stage, Boost.Hash should be very stable from release to release. The problem turned up again yesterday, so I'm starting to think it's enough of a problem that it's worth activating this be default. A different solution might be to change the implement of Boost.Hash for bools, so that the bool overload isn't required. But that would be treating the sympton, as other implicit casts could cause problems. An example of valid code that will now break is something like: struct base; std::size_t hash_value(base const&); struct derived : base { void some_method_but_no_extra_state(); }; boost::hash<derived> derived_hash; Currently that will automatically use base's hash_value, with this change it will be a compile error. Although that might be a good thing, as sometime it is an error to use the base's hash function. Of course, there will be a macro to keep the old behaviour. Any objections to this change?

3 5

Re: [boost] [Review Request] Multiprecision Arithmetic Library
by Christopher Kormanyos 11 May '12

11 May '12

Sorry, John my file was too big and admin rejected post. The candidate file is now 7-zip and should make it through. <snip> >> I experimented with FFTs. We need your inputs if we *really* >> want to make very high-precision available at this stage. <snip> >> maybe about 30 lines of code. > Nice, had no idea it could be implemented in such a small space! Ooops, my bad. It was 100 lines. I guess I was in a daze by then. <snip> > So my gut feeling is to hold off for now, and maybe do things > properly later (dynamic allocation, better std lib support etc)? I agree. We should pull the reigns on it for now. We won't get the reliability we need if we try to do something fast. I could go on indefinitely with big-numbs, but we have to get that first version potentially reviewed. I should really get back to my book project soon. But I'm definitely in on any relevant review issues. > I think the existing ones work out quite nicely now thanks, > I could use some ideas for integer and maybe rational number examples, > but that's a whole other ball game ;-) I'm not an integer guy. Maybe someone could help us out here. But what springs to my mind is: * Prime factorization * Greatest common denominator (GCD) * Primality testing for Mersenne Primes (has an exceptionally simple algo) * MD5, SHA-1, 2, etc. (but cool std::uint32_t reference apps already exist)<snip> >> I resolved the excessive guard digit issue and reduced the guard digits >> to the necessary amount (and provide rationale in a code comment). <snip> > Sure, or mail me a patch and I'll run the full tests > (or you can - just cd into libs/multiprecision/test and > do a "bjam --enable-specfun" and then wait for a long time!) > Thanks, John. OK. I attached my proposed version in /big_number/multiprecision/cpp_dec_float.hpp. The diffs include the removal of some non-needed constants, the trimming of max_digits10 and a minor improvement to the multiplication. Thanks, Chris.

4 29

[reference_wrapper] add operator()(Args...) to reference_wrapper
by Philipp Moeller 10 May '12

10 May '12

Given that Boost now has perfect forwarding emulation through Boost.Move and a better result_of, would it be possible to enable reference_wrapper to forward the function call operator? The current behavior is somewhat surprising and makes a few of the most promising applications of reference_wrapper (reference wrap polymorphic boost::function objects) impossible with code that is no prepared to work with reference_wrapper. It would also be more consistent with reference_wrapper of the stdlib. I can file a corresponding bug report and add a patch, if there is interest. Cheers, Philipp Moeller

2 5

[coroutine] request for review manager
by Oliver Kowalke 10 May '12

10 May '12

Hi, I want to ask who wants to be the review manager for boost.coroutine? The documentation is updated and available at: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html best regards, Oliver

2 4

Iterator Range and operator==
by Olaf van der Spek 08 May '12

08 May '12

Hi, What do you expect this code to do? Is b true or false? And why? Is this expected behaviour? #include <boost/range/iterator_range.hpp> #include <string> int main() { std::string s = "Olaf"; boost::iterator_range<std::string::iterator> r(s); bool a = r == s; bool b = r == "Olaf"; assert(a); assert(b); return 0; } -- Olaf

9 17

Latest version and status of lockfree
by Julien Nitard 06 May '12

06 May '12

Hi All, Where can I find the latest version of boost.lockfree ? There's nothing in the sandbox or the vault (it seems). The latest commit on Tim's public git repo was done more than 6 month ago. Now that atomic has been accepted, are there any roadblocks to have boost.lockfree released ? Many thanks, Julien

4 9

[contract] syntax redesign
by Lorenzo Caminiti 04 May '12

04 May '12

Hello all, After a long time of inactivity for Boost.Contract, I am considering how to re-design its macro syntax to make it simpler. I can eliminate a large number of extra parenthesis based on a few pp tricks I've learned in processing Boost.Local's `const bind(type)& var`. Plus, I can provide (optional) support for variadics macros so to use comma-separated pp tuplets instead of parenthesized pp sequences on preprocessors with variadics. For example, I _think_ (but I've not implemented this yet) that I can simplify the syntax like this: #include <contract.hpp> #include <vector> #include "myvector/pushable.hpp" // Wrapper class that adds contracts to std::vector. CONTRACT_CLASS( template( typename T ) class (myvector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT( empty() == (size() == 0) // More invariants here (comma separated)... ) CONTRACT_FUNCTION( public void (push_back)( (const T&) element ) precondition( size() < max_size() // More preconditions here (comma separated)... ) postcondition( auto old_size = CONTRACT_OLDOF(size()), // Old value. size() == old_size + 1 // More postconditions here (comma separated)... ) ) { vector_.push_back(element); // Implementation. } // Rest of the class here (with more contracts if needed)... public: typedef typename std::vector<T>::size_type size_type; size_type size(void) const { return vector_.size(); } size_type max_size(void) const { return vector_.max_size(); } bool empty(void) const { return vector_.empty(); } const T& back(void) const { return vector_.back(); } private: std::vector<T> vector_; }; For a side-by-side comparison with N1962 syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/inde… For a comparison of the entire std::vector (plus Boost.ConceptCheck concepts): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… For a comparison for all Boost.Contract features (plus Boost.ConceptCheck concepts and Boost.Parameter named parameters): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… (Don't pay attention to the rest of the docs that are way out of date.) A few notes: * Extra parenthesis are still needed around class and function names. * Extra parenthesis are still needed around types (like for the parameter `(T) element`) but only if the type is not a C++ keyword (no parenthesis needed aournd int, double, void, etc) or it contains a symbol (parenthesis needed if & or * are used `(int&) x`, etc). * In postconditions, the `auto old_size = CONTRACT_OLDOF(size())` only copies the vector size (and not the entire vector :)) ). Similarly, `auto result = return` can be used to access the return value for non-void functions. (The `auto ...` is parsed by the pp and it's implemented using Boost.Typeof so no C++0x is required.) * Template declaration (but not instantiation) angular parenthesis <> are replaced by round parenthesis (). All of this _should_ be implementable in pure ISO C++. What do you think? Based on the discontent that the previous "parenthesized" syntax generated among Boosters, the key question is: Would you consider this new syntax usable?? Thanks, --Lorenzo

5 45

[Countertree + Suballocator] New Version
by Francisco José Tapia 03 May '12

03 May '12

Hi this message is to announce the new version of the [countertree + suballocator] library. You can find the zip file with the code and the documentation in https://docs.google.com/file/d/0B9lWJ1Nhb_RhRXVHSS14aGxUZjJjWFdRVC0xZ2czZw/… or if you want a quick look , you can see in my web page http://fjtapia.webs.com/works/countertree/index.html *COUNTERTREE * This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . With this tree we have vectors (cntree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. With ordered information, we have in the cntree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) For to show the utility of this, imagine a large unordered file with the information about the employees of a big company. You have indexes implemented with multimaps, with pairs [value, position], and use the upper_bound and lower_bound functions. You need to select the employees in a range of age and weight. With the boost:multimap you can know the number of elements of the selection. In the weight query we found 100 elements and in the age query 10000 elements. To travel the elements of the weight query asking for the age, is faster than the opposite. *SUBALLOCATOR * A very hard test for the allocators are the data structures which need a very high number (several millions) of elements of the same size, like the STL list, set, multiset, map or multimap. When the number of elements grow, many allocators begin to have speed problems. The solution proposed for this problem are the custom allocators. These allocators are very fast, but many of them present additional problems related with the memory consumption. And they don't work well when they must manage many types of data. When the allocators receive the request from the program, they request memory to the Operating System, and the memory consumed by the program grows up. When the program return to the allocators the request, many allocators have problems for to return the memory freed to the Operating System (The std::allocator of GCC 4.6 don't return well the memory, and the std::allocator of Visual C++, return, but it is slower than the GCC allocator) If you use only one allocator, you have a bad management or in the speed of equal size elements, or with a wide variety of elements. If you use two allocators, the memory freed by an allocator can't be used by the other, and the memory consumption is very high, and when decrease the number of elements to manage, the memory don't decrease. These problems are specially important in two environments : a) When you have a limited resources, as occurs in the mobile phones, pads ... b) When the programs must run continuously in a multitask environment The solution is the suballocator. It is a mechanism for to manage in a fast way a greater number (hundred millions) of elements with the same size. The suballocator is a layer over the allocator (any allocator with the STL interface). The suballocator receives an allocator as template parameter. When the suballocator needs memory, request memory from the allocator, and when the memory is not used, is returned to the allocator. The suballocator present the same interface than the STL allocator. Form the view point of the data structures, the suballocator is other allocator The suballocator always return the first element free. This improve the cache performance and the speed of the data structures. This simple memory schema permit to the allocators return memory to the Operating System and decrease the memory used by the program, as demonstrate the programs in the benchmarks, and you can see in the benchmark point. With the suballocator a) We have a very *fast allocation* (3 times faster than GCC 4.6 std::allocator, 3.5 times faster than Visual Studio 10 std::allocator ) b) Return memory to the allocator, for to be used by others types of data. Many allocators, return this memory to the Operating System, and *decrease the memory used by the program * c) You *can use with any allocator* if according with the STL definition. The suballocator provides speed and memory management to any allocator. d) In the insertion in a std::set<uint64_t> , the time spent by the allocator is around 1%, but the suballocator save around 35% of time . The suballocator always provide the first position free, This provide us a very compact data are, which *improve the cache performance* All the information showed here is explained and detailed in the point Suballocator. All the information is extracted from the programs in the benchmarks folder. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace cntree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC 4.6 (32 and 64) , CLANG/LLVM 3.0 and Visual Studio 1010 (32 and 64). If you find any error or problem in the code , the documentation or in any other part ( as friendly do Mr Rene Rivera in the first version). Please mail me ( fjtapia(a)gmail.com) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. If you have some idea, or have any comment, please mail me, always two legs run more than only one in the pursuit of the goal, to be useful to the community of programmers in the same way than our predecessors had been useful to us. Sincerely yours Francisco Tapia fjtapia(a)gmail.com

7 19

[release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
by lcaminiti 02 May '12

02 May '12

Hello release managers, I've been working in the trunk on a few libraries which are almost ready to be released: a) When is the release date? b) What do I have to do to merge into release? (This will be my 1st release merge :) ). 1) ScopeExit (improved) I'm waiting on MVSC 9 and 10 tests to cycle to make sure they all pass. Other compilers OK. 2) Utility/IdentityType (new) Should be ready to be merged into release. 3) Functional/OverloadedFunction (new) Should be ready to be merged into release. 4) LocalFunction (new) I'm making final fixes for some tests on some of compilers. Hopefully, I'll be done in 2 weeks max. For all of those, I've followed the checklist so I've run the code inspection tool, updated all docs, librariers.htm, and maintainers.txt. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

[uuids] On boost::uuids::uuid operator == performance.
by Michael Kochetkov 02 May '12

02 May '12

Hello. I would like to discuss a performance issue with boost::uuids::uuid operator ==. Let us consider the following program: --------------------------------------------------- #include <boost/uuid/uuid.hpp> #include <boost/uuid/uuid_generators.hpp> int main() { boost::uuids::uuid id1((boost::uuids::random_generator()())), id2((boost::uuids::random_generator()())); return id1 == id2; // we will consider this line } --------------------------------------------------- That is compiled with maximum optimizations the following way with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86: cl -EHsc -Ox -GL -Ob2 -Oi -Fa -I..\3dparty\boost_1_48_0 m051.cpp boost uses the following comparison operator: inline bool operator==(uuid const& lhs, uuid const& rhs) /* throw() */ { return std::equal(lhs.begin(), lhs.end(), rhs.begin()); } which end up with the following code: lea edx, DWORD PTR _id2$[esp+92] lea ecx, DWORD PTR _id1$[esp+108] lea eax, DWORD PTR _id1$[esp+92] call ?_Equal@std@@YA_NPBE00@Z ; std::_Equal The whole story looks the following way (the code above plus std::_Equal call expansion): 0117C6AB lea edx,[esp+24h] 0117C6AF lea ecx,[esp+48h] 0117C6B3 lea eax,[esp+38h] 0117C6B7 call 01171000 01171000 push esi 01171001 mov esi,eax 01171003 sub ecx,esi 01171005 push edi 01171006 cmp ecx,4 01171009 jb 01171024 0117100B jmp 01171010 0117100D lea ecx,[ecx] 01171010 mov eax,dword ptr [esi] 01171012 cmp eax,dword ptr [edx] 01171014 jne 01171028 01171016 sub ecx,4 01171019 add edx,4 0117101C add esi,4 0117101F cmp ecx,4 01171022 jae 01171010 01171024 test ecx,ecx 01171026 je 01171073 01171028 movzx eax,byte ptr [esi] 0117102B movzx edi,byte ptr [edx] 0117102E sub eax,edi 01171030 jne 01171063 01171032 cmp ecx,1 01171035 jbe 01171073 01171037 movzx eax,byte ptr [esi+1] 0117103B movzx edi,byte ptr [edx+1] 0117103F sub eax,edi 01171041 jne 01171063 01171043 cmp ecx,2 01171046 jbe 01171073 01171048 movzx eax,byte ptr [esi+2] 0117104C movzx edi,byte ptr [edx+2] 01171050 sub eax,edi 01171052 jne 01171063 01171054 cmp ecx,3 01171057 jbe 01171073 01171059 movzx eax,byte ptr [esi+3] 0117105D movzx ecx,byte ptr [edx+3] 01171061 sub eax,ecx 01171063 sar eax,1Fh 01171066 or eax,1 01171069 xor edx,edx 0117106B test eax,eax 0117106D pop edi 0117106E sete al 01171071 pop esi 01171072 ret 01171073 xor eax,eax 01171075 xor edx,edx 01171077 test eax,eax 01171079 pop edi 0117107A sete al 0117107D pop esi 0117107E ret I do understand that the boost::uuids::uuid implementation is conceptually correct and inoculate the best programming practices. But the following equivalent is too much faster (you may probably want to ensure a proper alignment for some processor architectures or even get even faster 64-bit version): inline bool comp(const boost::uuids::uuid& l, const boost::uuids::uuid& r) { return *reinterpret_cast<const uint32_t*>(l.data) == *reinterpret_cast<const uint32_t*>(r.data) && *reinterpret_cast<const uint32_t*>(l.data+4) == *reinterpret_cast<const uint32_t*>(r.data+4) && *reinterpret_cast<const uint32_t*>(l.data+8) == *reinterpret_cast<const uint32_t*>(r.data+8) && *reinterpret_cast<const uint32_t*>(l.data+12) == *reinterpret_cast<const uint32_t*>(r.data+12); } the assembler output is: mov ecx, DWORD PTR _id1$[esp+92] cmp ecx, DWORD PTR _id2$[esp+92] jne SHORT $LN37@main mov edx, DWORD PTR _id1$[esp+96] cmp edx, DWORD PTR _id2$[esp+96] jne SHORT $LN37@main mov eax, DWORD PTR _id1$[esp+100] cmp eax, DWORD PTR _id2$[esp+100] jne SHORT $LN37@main mov ecx, DWORD PTR _id1$[esp+104] cmp ecx, DWORD PTR _id2$[esp+104] jne SHORT $LN37@main mov eax, 1 jmp SHORT $LN40@main $LN37@main: xor eax, eax $LN40@main: movzx eax, al that the question comes: is boost supposed to be used in commercial applications or it is just a testing area for some concepts? You have probably never thought of the fact that Debug (unoptimized configurations) are sometimes just unusable with such approach on real (big) data. If you are interested you may want to compile the program above this way and see the resulting code: cl -EHsc -Zi -Fa -I..\3dparty\boost_1_48_0 m051.cpp Thank you in advance for your considerations. -- Michael Kochetkov

7 27

[uuid] Unused variable warnings
by Andrey Semashev 02 May '12

02 May '12

Hi, With recent versions of boost I get lots of warnings like the following: /.../boost/uuid/seed_rng.hpp: In member function ‘void boost::uuids::detail::seed_rng::sha1_random_digest_()’: /.../boost/uuid/seed_rng.hpp:157:24: warning: variable ‘not_used’ set but not used [-Wunused-but-set-variable] I'm using GCC 4.6 with -Wall. It's trivial to mask this warning out by attaching __attribute__((unused)) to the variable, which I've done locally. Ok to commit?

2 2

[Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix
by Ivan Erceg 02 May '12

02 May '12

Hi all, Before I switch to using boost::make_shared<> I wanted to test its purported performance advantage. I created a simple benchmark for measuing raw allocation throughput for 3 classes of different sizes with a common base class (constructors and destructors trivial). The number of allocations was set to 40,000,000 as it was roughly giving me 10 seconds running time per test. Unfortunatelly it turns out that on VC++9 (release target with default optimizations) boost::make_shared is significantly slower than simply doing boost::shared_ptr(new). Here's the benchmark output: TestBoostMakeShared 10.577s 3.78179e+006 allocs/s TestBoostSharedPtrNew 8.907s 4.49085e+006 allocs/s As you can see boost::make_shared is over 15% slower than boost::shared_ptr(new) idiom. Having available VC++10 compiler as well I then compared these results with std::shared_ptr and std::make_shared implementations that come with that compiler (but not VC++9). Here are the results: TestBoostMakeShared 9.688s 4.12882e+006 allocs/s TestBoostSharedPtrNew 8.252s 4.84731e+006 allocs/s TestStdMakeShared 5.07s 7.88955e+006 allocs/s TestStdSharedPtrNew 8.159s 4.90256e+006 allocs/s While std::shared_ptr(new) performs about the same as boost::shared_ptr(new), std::make_shared really blows away boost::make_shared and both shared_ptr(new) tests, being almost twice as fast as boost::make_shared. I then profiled the boost::make_shared test to see what's the biggest performance bottleneck when compared to boost::shared_ptr(new) profiler run. The culprit was immediately obvious: boost::make_shared test was spending above 25% of its time in "type_info::operator==(class type_info const &) const" function. This function was being called indirectly from boost::make_shared through boost::get_deleter. After digging some more through the implementation I came to the conclusion that, in this particular case, we are guaranteed to always be requesting deleter for the right class (namely T from boost::make_shared<T>). Since boost::shared_ptr doesn't have a way to retrieve the deleter without using RTTI I decided to add one and use it from an alternative boost::make_shared. So I did the following: 1. I added a virtual function to detail::sp_counted_base (detail\sp_counted_base_w32.hpp): virtual void * get_raw_deleter( ) = 0; 2. I implemented get_raw_deleter() function in sp_counted_impl_p (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return 0; } 3. I implemented get_raw_deleter() function in sp_counted_impl_pd (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( del ); } 4. I implemented get_raw_deleter() function in sp_counted_impl_pda (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( d_ ); } 5. I added the following function to detail::shared_count: void * get_raw_deleter( ) const { return pi_? pi_->get_raw_deleter( ): 0; } 6. I added the following function to shared_ptr<>: void * _internal_get_raw_deleter( ) const { return pn.get_raw_deleter( ); } 7. I made a separate copy of boost::make_shared function and replaced a single line from: boost::detail::sp_ms_deleter< T > * pd = boost::get_deleter< boost::detail::sp_ms_deleter< T > >( pt ); to: boost::detail::sp_ms_deleter< T > * pd = static_cast<boost::detail::sp_ms_deleter< T > *>(pt._internal_get_raw_deleter()); Benchmarking the results afterwards gave me the following results on VC++9: TestBoostSharedPtrNew 9.204s 4.34594e+006 allocs/s TestBoostMakeShared 10.499s 3.80989e+006 allocs/s TestBoostMakeSharedAlt 7.831s 5.1079e+006 allocs/s My changes translated into almost 35% improvement in allocation speed over the current implementation of boost::make_shared. Or to put it differently, they amount to 25+% decrease in running time as we could have supposed from the profiling results. Results on VC++10 are similar: TestBoostSharedPtrNew 8.487s 4.71309e+006 allocs/s TestBoostMakeShared 9.609s 4.16276e+006 allocs/s TestStdSharedPtrNew 8.283s 4.82917e+006 allocs/s TestStdMakeShared 5.039s 7.93808e+006 allocs/s TestBoostMakeSharedAlt 6.802s 5.88062e+006 allocs/s VC++10's std::make_shared is still much faster (almost 35% faster than boost::shared_ptr) and we will be switching to it once we switch to VC++10. But in the meantime it seems to me that boost::make_shared should be fixed to improve the performance. Again, this is only one compiler and other compilers might not have such a severe RTTI performance issue but I still think it would be well worth avoiding unnecessary calls to RTTI during performance-relevant operations such as heap allocations. The testing and changes were done on Boost 1.48.0 but I compared Smart Ptr library sources with Boost 1.49.0 and the above changes should work there equally well. Thanks, Ivan

15 40

Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
by Brian Wood 02 May '12

02 May '12

Paul Mensonides: > As some sort of technological preview? It is not portable enough to be > used within Boost, though perhaps a slew of regression failures will cause > that to change (unlikely). <rant>MS, in particular, is too busy taking it > upon themselves to "ensure C++ is relevant" to prioritize implementing the > language.</rant> Also, one of the principles of Chaos is to have > absolutely zero compiler workarounds, and that would have to stay if it > was ever part of Boost. Given your desire to avoid compiler workarounds, an on line code generator may be helpful. One of the happy results of going on line is kissing compiler workarounds good-bye. I've worked on the distribution of code generated by an on line code generator -- http://webEbenezer.net/build_integration.html . You're welcome to use that as a starting point if you like. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 4

Review request: extended complex number library
by Matthieu Schaller 02 May '12

02 May '12

Dear all, Following the comments from V. Escriba, I formally propose my complex number library for review. The library is an extension of the std::complex class addressing two issues: - The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. - 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) Performance tests show some non-negligible speed-ups compared to std::complex for calculations where pure imaginary numbers are involved. A speed-up of 25% has been observed when solving the Schroedinger equation explicitly on a regular mesh and some comparable figures can be observed when computing the Mandelbrot set (the two examples snippets provided in the archive). Furthermore, the functions (sin(), exp(), log(),...) involving boost::imaginary numbers are more precise than their equivalent using a std::complex with the real part set to 0. The code and (doxygen) documentation is available in the repository http://code.google.com/p/cpp-imaginary-numbers/ A comprehensive zip archive can be found in the "download" and the code can also be checked-out via the SVN repository. The archive contains the class header, two examples, a comprehensive precision test, a brute-force performance test and the documentation. I'd be happy to answer any question from your side and to provide more detailed information if required. Regards, Matthieu -- Matthieu Schaller PhD student - Durham University

8 23

Array in Unordered Map
by Olaf van der Spek 01 May '12

01 May '12

Hi, What's the right way to get an array into an unordered map? This one works on VC10, but GCC appears to look for the hash_value function in namespace std. What's the right way to do this? Olaf #include <array> #include <boost/unordered_map.hpp> namespace boost { template<class T, size_t N> size_t hash_value(const std::array<T, N>& v) { return boost::hash_range(v.begin(), v.end()); } } int main() { boost::unordered_map<std::array<char, 20>, int> c; c[std::array<char, 20>()] = 0; return 0; } -- Olaf

3 6

Re: [boost] [exception] warning about non-virtual destructor - resolution?
by Hite, Christopher 30 Apr '12

30 Apr '12

This is annoying me too: boost_1_49_0/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] A) easy solution /boost_1_49_0/boost/exception/detail/error_info_impl.hpp It's probably easiest to just make ~error_info_base() virtual. It doesn't cost much since there's already a virtual table. B) harder solution The other cooler C++11 alternative is declare error_info final. I tried it on gcc-4.7.0 and it works wonderfully. Since the compiler knows you can not derive a class from that type it knows a that deconstructor is complete. struct base{ virtual void foo(); }; struct derived final : base { }; //struct illegal : derived {}; // error: cannot derive from 'final' base 'derived' in derived type 'illegal' void kill(derived* d){ delete d; // no complaint } I vote for A, because you'd anyway have to detect support for final. Chris

12 48

Re: [boost] [type_traits] has_equal_to< std::vector<T> > always true_
by Frédéric Bron 30 Apr '12

30 Apr '12

> We could use <boost/detail/container_fwd.hpp> here (rather like Boost.Hash > does, which has a similar issue) and get the best of both worlds? My > concern about making it a separate header, is that it runs the risk of ADL > errors if the #includes are inconsistent across translation units. I assume > that only forward declarations are needed for the containers? This looks a very good idea. It is a pity that the standard does not provide such header as it does for iostreams (iosfwd). However, I see that <boost/detail/container_fwd.hpp> has some troubles with many compilers, in particular with g++. // GNU libstdc++ 3 // Disable forwarding for all recent versions, as the library has a // versioned namespace mode, and I don't know how to detect it. This is a major drawback but maybe we can do something for it. I see also that with the new standard, this header is now not exhaustive; we have to include all of these: * <array> - <deque> * <forward_list> - <list> - <vector> - <map> - <set> * <unordered_map> * <unordered_set> - <queue> - <stack> - <string> - <bitset> *: missing headers in <boost/detail/container_fwd.hpp> Frédéric

2 1

Exception visibility and non-GCC compilers
by Mathias Gaunard 30 Apr '12

30 Apr '12

Exceptions types need to be exported so that shared libraries work correctly. Currently, the only code I see that does this is in Boost.Exception : #if defined(__GNUC__) # if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4) # pragma GCC visibility push (default) # endif #endif ... some exception type being declared or defined #if defined(__GNUC__) # if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4) # pragma GCC visibility pop # endif #endif But shouldn't we have macros to make this work with other compilers too? I'm not sure all unix-like compilers pretend to be GCC 4.1+.

2 3

[pool] Definition of a static_pool ?
by DUPUIS Etienne 30 Apr '12

30 Apr '12

Greetings, The Boost.Pool class describes a pool of buffer, pool whose size grows as needed. This is very convenient but there usage cases where the pool should not perform any dynamic memory allocation, i.e. the maximum number of simultaneously required buffers is known at initialization. I have hence defined a simple class 'static_pool' (see below), which (i) allocate all requested buffers at initialization; (ii) fails (returns null) if more buffers are being asked for at runtime. Does such a class has its place within the Boost Pool library ? Regards, Étienne #ifndef BOOST_STATIC_POOL_HPP #define BOOST_STATIC_POOL_HPP #include <boost/pool/pool.hpp> namespace boost { template<typename UserAllocator> class static_pool : protected pool<UserAllocator> { public : // Overridden functions explicit static_pool(const size_type nrequested_size) : pool<UserAllocator>(nrequested_size, nrequested_size) { free(malloc()); } void * malloc() { return store().empty() ? NULL : store().malloc(); } public : // Inherited functions void free(void * const chunk) { return pool<UserAllocator>::free(chunk); } size_type get_requested_size() const { return pool<UserAllocator>::get_requestedSize(); } bool is_from(void * const chunk) const { return pool<UserAllocator>::is_from(chunk); } }; } #endif 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.

7 18

[filesystem] [system] Suddenly, dynamic linking by default
by Lars Viklund 30 Apr '12

30 Apr '12

Hello list. I have a habit of tracking trunk to find out if there's any strangeness or mistakes done on the platforms I target. A while ago I encountered some strange linking errors on some of my projects, which in the end turned out to be because for some reason, Boost.Filesystem and Boost.System now attempt to be dynamically linked by default, both symbol-decoration-wise and auto-link filename-wise. I happened to have some older shared libraries from an older trunk version lying around, so they were suddenly and unexpectedly picked up instead of my fresh static libraries. Even without my library hygiene deficiencies, the decision (which I have yet to see a rationale or announcement about) will cause a lot of problems. Why is it that System/Filesystem suddenly default to dynamic linking? Are there problems about linking statically? Why are there then static libraries built at all? Is this just some personal preference of the author that goes contrary to the general approach of Boost? Such choices have _massive_ impacts on consumers of the code, they should not be made lightly and if there is a really concrete need to do so, why is it not documented and thoroughly explained? Linking dynamically requires you to deploy the Boost DLLs to the end user, which prevents any plugin-like deployment, as they tend to require a single self-contained shared library with no dependencies, which implies linking to a static language runtime of choice. Dynamic linking of Boost means that you need to share a CRT between the project and Boost, which implies that the only CRT choice is the dynamic one, which prevents many deployment scenarios, as you have to deploy _that_ as well to the end user, either as a redistributable install or as a private deployment. This also has an impact on code size, as there is no dead-code elimination possible when the code resides in a DLL, you have to ship _all_ of the library even if you use a few convenience functions. For one of my projects (an extension to a popular music player), this would inflate its size many times for each and every download, as the software is deployed as a single ZIP archive through automatic update services. Additionally, the autolink macros to force symbol decoration and linking for a static link are undocumented in the Boost.Config table [1], which explicitly states that all libraries that can be statically linked will be statically linked. There is no mention of libraries that arbitrarily decide to go dynamic, just that some libraries are only available in dynamic form. For future reference for anyone finding this in archives, the undocumented, and in this case required, macros to force a static link and symbol decoration are: BOOST_<WHATEVER>_STATIC_LINK or BOOST_ALL_STATIC_LINK [1] http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/index.html#boost_… -- Lars Viklund | zao(a)acc.umu.se

5 6

[iostream] tests broken due to dependency on removed filesystem internals
by Jürgen Hunold 30 Apr '12

30 Apr '12

Hi, almost all Boost.Iostreams test fail with: bin.v2/libs/iostreams/test/array_test.test/gcc-4.6/debug/array_test.o In file included from ../array_test.cpp:14:0: ../detail/temp_file.hpp:16:46: fatal error: boost/filesystem/v3/operations.hpp: No such file or directory compilation terminated. The v3/ was removed recently as v2 was finally dropped. Patch to fix this attached. This gets a lot of the tests running. Okay to commit? There are some remaining failures. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu !

3 4

[multiprecision] Looking for a review manager
by John Maddock 29 Apr '12

29 Apr '12

Just a quick line to remind/hassle you all that I'm still looking for a review manager for the multiprecision library: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… All volunteers/victims gratefully accepted ;-) Many thanks in advance, John.

1 0

Re: [boost] Slow Bugs Tracker
by Olaf van der Spek 29 Apr '12

29 Apr '12

Hi, A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell. http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php -- Olaf

7 44

[utility] convention inconsistencies
by lcaminiti 29 Apr '12

29 Apr '12

Hello all, I'm adding IdentityType to Boost.Utility and I have a couple of question about conventions: 1) Is there a reason why utility.hpp does not include all headers in boost/utility/? 2) Is there a reason why in the Documentation the utility sub-libraries are not named Boost.Utility/EnableIf bust just Boost.EnableIf? http://www.boost.org/doc/libs/1_49_0/ In boost/utility/ directory: addressof.hpp base_from_member.hpp binary.hpp compare_pointees.hpp declval.hpp enable_if.hpp identity_type.hpp in_place_factory.hpp result_of.hpp swap.hpp typed_in_place_factory.hpp value_init.hpp But boost/utility.hpp includes only some of those: #ifndef BOOST_UTILITY_HPP #define BOOST_UTILITY_HPP #include <boost/utility/addressof.hpp> #include <boost/utility/base_from_member.hpp> #include <boost/utility/binary.hpp> #include <boost/utility/enable_if.hpp> #include <boost/checked_delete.hpp> #include <boost/next_prior.hpp> #include <boost/noncopyable.hpp> #endif // BOOST_UTILITY_HPP Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-utility-convention-inconsistencies… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[function] The cost of boost::function
by Michael Kochetkov 28 Apr '12

28 Apr '12

Hello, as far as I subscribed to boost mail list for a reason I have decided to share an interesting (at least for me) observation of boost::function facility I have encountered several years ago. The observation is about the cost of the solution and you probably may be interested if you use boost in your production. Let us consider the following code: #include <boost/bind.hpp> #include <boost/function.hpp> inline int g(int i) { return ++i; } int main() { // AAAAA boost::function< int (int) > f1 = boost::bind(&g, _1 ); f1(1); // BBBB boost::_bi::bind_t<int,int (*)(int),boost::_bi::list1<boost::arg<1> > > f2 = boost::bind(&g, _1 ); f2(1); // CCCC auto f3 = boost::bind(&g, _1 ); f3(1); } I have compiled it with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 the following way (maximal optimization): cl -EHsc -Ox -GL -Ob2 -Oi -Fa -IE:\Work\3dparty\boost_1_48_0 m054.cpp The resulting code for AAAA is: ; Line 10 mov eax, OFFSET ?g@@YAHH@Z ; g mov DWORD PTR $T109940[esp+60], eax mov eax, DWORD PTR $T109845[esp+64] lea ecx, DWORD PTR $T109940[esp+60] push ecx mov DWORD PTR $T109940[esp+68], eax call ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target add esp, 4 test al, al jne SHORT $LN20@main mov edx, DWORD PTR $T109940[esp+60] mov eax, DWORD PTR $T109940[esp+64] mov ecx, OFFSET ?stored_vtable@?1???$assign_to@V?$bind_t@HP6AHH@ZV?$list1@U?$arg@$00@boost@@ @_bi@boost@@@_bi@boost@@@?$function1@HH@boost@@AAEXV?$bind_t@HP6AHH@ZV?$list 1@U?$arg@$00@boost@@@_bi@boost@@@_bi@2@@Z@4U?$basic_vtable1@HH@function@deta il@2@B ; `boost::function1<int,int>::assign_to<boost::_bi::bind_t<int,int (__cdecl*)(int),boost::_bi::list1<boost::arg<1> > > >'::`2'::stored_vtable or ecx, 1 mov DWORD PTR _f1$[esp+68], edx mov DWORD PTR _f1$[esp+72], eax mov DWORD PTR _f1$[esp+60], ecx jmp SHORT $LN18@main $LN20@main: mov DWORD PTR _f1$[esp+60], 0 $LN18@main: ; Line 11 lea ecx, DWORD PTR _f1$[esp+60] mov DWORD PTR __$EHRec$[esp+68], 0 call ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() The resulting code for BBBB is: ; Line 15 push 1 call ?g@@YAHH@Z ; g add esp, 4 The resulting code for CCCC is: ; Line 19 push 1 call ?g@@YAHH@Z ; g add esp, 4 I have learned that personally I shall never use boost::function. You probably may want to investigate such a code bloat. Though it is probably the known and expected behavior. And I do agree that CCCC is not quite relevant here. Just for information. -- Michael Kochetkov P.S. The traditional full story for AAAA, that includes intermediate calls. Though it is not really full -- I have given up for three more calls inside the boost::function1<int,int>::operator() function. ; // AAAAA ; boost::function< int (int) > f1 = boost::bind(&g, _1 ); ; f1(1); 002661B9 mov eax,261170h 002661BE mov dword ptr [esp+4],eax 002661C2 mov eax,dword ptr [esp+8] 002661C6 lea ecx,[esp+4] 002661CA push ecx 002661CB mov dword ptr [esp+0Ch],eax 002661CF call 00261160 002661D4 add esp,4 002661D7 test al,al 002661D9 jne 002661F9 002661DB mov edx,dword ptr [esp+4] 002661DF mov eax,dword ptr [esp+8] 002661E3 mov ecx,26A028h 002661E8 or ecx,1 002661EB mov dword ptr [esp+14h],edx 002661EF mov dword ptr [esp+18h],eax 002661F3 mov dword ptr [esp+0Ch],ecx 002661F7 jmp 00266201 002661F9 mov dword ptr [esp+0Ch],0 00266201 lea ecx,[esp+0Ch] 00266205 mov dword ptr [esp+38h],0 0026620D call 002611D0 ; ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target 00DD1160 xor al,al 00DD1162 ret ; ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() 00DD11D0 push 0FFFFFFFFh 00DD11D2 push 0DD7810h 00DD11D7 mov eax,dword ptr fs:[00000000h] 00DD11DD push eax 00DD11DE sub esp,58h 00DD11E1 push esi 00DD11E2 mov eax,dword ptr ds:[00DDB038h] 00DD11E7 xor eax,esp 00DD11E9 push eax 00DD11EA lea eax,[esp+60h] 00DD11EE mov dword ptr fs:[00000000h],eax 00DD11F4 mov eax,dword ptr [ecx] 00DD11F6 test eax,eax 00DD11F8 jne 00DD1248 00DD11FA lea eax,[esp+0Ch] 00DD11FE push eax 00DD11FF lea ecx,[esp+14h] 00DD1203 mov dword ptr [esp+10h],0DDA008h 00DD120B call 00DD187F 00DD1210 mov dword ptr [esp+10h],0DDA058h 00DD1218 lea eax,[esp+10h] 00DD121C lea esi,[esp+1Ch] 00DD1220 mov dword ptr [esp+68h],0 00DD1228 call 00DD1600 00DD122D lea esi,[esp+3Ch] 00DD1231 mov byte ptr [esp+68h],1 00DD1236 call 00DD1640 00DD123B push 0DDA7A8h 00DD1240 mov ecx,esi 00DD1242 push ecx 00DD1243 call 00DD23CA 00DD1248 and eax,0FFFFFFFEh 00DD124B mov edx,dword ptr [eax+4] 00DD124E add ecx,8 00DD1251 push 1 00DD1253 push ecx 00DD1254 call edx 00DD1256 add esp,8 00DD1259 mov ecx,dword ptr [esp+60h] 00DD125D mov dword ptr fs:[0],ecx 00DD1264 pop ecx 00DD1265 pop esi 00DD1266 add esp,64h 00DD1269 ret

6 8

[1.50] Is there a schedule?
by John Maddock 27 Apr '12

27 Apr '12

OK, so it's too soon at present anyway, but should there be some sort of schedule on the calendar so we all know where we are? Cheers, John.

2 1

Boost.Variant known_get
by David Sankel 27 Apr '12

27 Apr '12

I noticed the detail::known_get function in boost variant. Is there any reason this function, which would be useful in high performance scenarios, is not exposed as part of the rest of the interface? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

1 0

Boost.units autoscaling doesn't seem to work with the measurement type.
by Paul A. Bristow 27 Apr '12

27 Apr '12

I have previously used Boost.Units and autoscaled using << engineering_prefix nicely, and this works as expected for quantity of type double. but it seems that code that I believe worked previously does not autoscale when using a *user-defined type*, like the measurement example in kitchen_sink.cpp. To confirm this, I have added after //[kitchen_sink_snippet_8 in kitchen_sink.cpp at line 445 a measurement quantity where the length is long enough to trigger conversion to km, thus quantity<length,measurement<double> > biglen(measurement<double>(12345.0,123.0)*meters); std::cout << "Biglen autoscaled "<< engineering_prefix << biglen << std::endl; but I get a *unscaled* value :-( Biglen autoscaled 12345(+/-123) m rather than the expected conversion to kilometers 12.345(+/- 0.123) km Am I doing something wrong, or has something changed? Thanks Paul PS Using Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel Microsoft .NET Framework Version 4.0.30319 SP1Rel Boost-trunk (Boost.1.49) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 1

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 27 Apr '12

27 Apr '12

As previously mentioned, the plan is to wire up existing (C interface) packages to a C++ std::decimal, raising licensing issues around the 3rd party code. I don't believe there is an issue, the licences are very short and read like plain English to me. Also, gcc includes both of these in it's implementation, and distributes under an open licence. I've copy-pasted below the relevant bits out of the EULAs. If anyone thinks there might be an issue, please let me know. INTEL EULA Copyright (c) 2011, Intel Corp. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, his list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. IBM Licence Copyright (c) 1995-2012 International Business Machines Corporation and others All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.

3 3

Variadic to Head/Tail TMP List
by Fernando Pelliccioni 27 Apr '12

27 Apr '12

Hi, Is this piece of code useful ? http://pastebin.com/tRrqVHTw The purpose is to tranform code like the following: typedef cons<int, cons<float, cons<char, cons<string>>>> t0; // fusion::cons or similar data structures in typedef chain_generator<cons, nil> cons_gen; typedef cons_gen::gen<int, float, char, std::string>::type t1; I don't know if there is something similar in a library. I think it could be useful. Compiler tests: GCC 4.7 -> Compiler Error GCC 4.7.1 & Trunk -> OK http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53108 Clang Trunk -> OK MSVC 11 beta -> has no Variadic Templates Regards, FP.

2 2

Boost.ntree_container (bi_tree, quad_tree, oct_tree, etc ptr containers) Is there any interest in this?
by Dan Walters 27 Apr '12

27 Apr '12

Hi all, I am proposing adding spacial containers for efficiently storing and accessing data of a spacial nature in fixed size trees. n-tree data structures would be useful where data relates to a 1D, 2D or 3D location, providing n-array searching of an n-array volume. N-tree data structures are commonly used in 3d applications, and are rarely particularly specialized. Their use is fundamental however they are frequently written by application programmers, due to a lack of free open source implementations (to the limit of my research). Their sophistication, like any container, is slim but easy to get wrong and beyond the ability and time contraints that should be assumed of the application programmer. It is a flexible and standard enough concept that a single implementation can be expected to meet a majority of requirements. I think there is the opportunity to create a solid implementation of templated n-tree pointer containers. The ntree container would be a tree representing an narray of elements with all dimensions being the same and being a power of two. The tree is memory efficient where areas within the volume are not occupied, and so "branches" and "leaves" are not created. The tree is well suited to geometrical operations such as ray picking or plane culling of the volume. An n-tree structure could be used in the place of any sparely populated n dimensional array where memory saving is the objective. The existing libraries I have found are licensed under GNU licenses. A ntree container should implement: get reset overloaded (array style) operators Optional implementations: views - a subset object representing an area or volume within the tree for accelerated access to a group of leaves that are positioned near to each other raycasting plane culling (getting leaves within a set of planes) etc. Is there interest in such a library? Many thanks, Dan

7 7

[interprocess] ppc compile error
by Tim Blechmann 27 Apr '12

27 Apr '12

hi all, one of my users reported the following compile error when building my application for ppc/osx(10.5): /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5566:Unknown pseudo-op: .subsection /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5566:Rest of line ignored. 1st junk character valued 50 (2). /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5569:Unknown pseudo-op: .previous the specific part of the assembly is: -- 4010 L686: 4011 sync 4012 lwarx r8,0,r11 4013 cmpw r8, r3 4014 bne- 2f 4015 stwcx. r9,0,r11 4016 bne- 2f 4017 addi r2,0,1 4018 1:.subsection 2 4019 2: addi r2,0,0 4020 b 1b 4021 .previous 4022 4023 cmpwi cr7,r2,0 4024 mr r3,r8 4025 beq cr7,L686 4026 stw r8,20(r10) 4027 mulli r3,r8,12 4028 add r3,r3,r10 4029 addi r3,r3,28 4030 bl L__ZNK5boost12interprocess10offset_ptrIfimLm0EE14to_raw_pointerEv$stub 4031 addi r1,r1,96 4032 stw r3,4(r30) 4033 lwz r0,8(r1) 4034 nop 4035 lmw r30,-8(r1) 4036 mtlr r0 4037 blr -- this error occurs with boost-1.49.0 ... is this a known issue or some workaround? thanks, tim

2 2

[OT][RFC] standardized compile-time reflection
by Matus Chochlik 27 Apr '12

27 Apr '12

Dear members of the Boost community, (Sorry for being slightly off-topic here) In the last couple or years I've been working on the design and implementation of portable reflection in C++. I've written several reflection libraries (that are hopefuly gradually improving). For the latest incarnation see the Mirror reflection utilities written in C++11: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ Recently I've learned that the Standardization Committee has issued a call for proposals for additions to the standard to the wider community, so I've decided to write down my own ideas on how compile-time reflection should look like in C++. Afterwards I discussed it with several people including Dean Michael Berris, who is the co-author of n3340 "Rich pointers" and is also interested in adding run-time (and static) reflection to C++. We've decided that we merge the ideas from my paper into his proposal (which has not happened yet and will probably take a while). However, n3340 deals with more than just static reflection, so I would like to start a discussion and ask the members of the Boost community for their opinions about the compile-time-specific parts that are described in the following paper, before writing the final proposal: http://kifri.fri.uniza.sk/~chochlik/jtc1_sc22_wg21/std_cpp_refl.pdf It is a bit lengthy so you can skip sections 1., 2. and probably also section 3., if you are knowledgeable about the domain. The most important parts are: the whole section 4. "Technical specification" and also 5., 6. and 7. Section 7. "Unresolved issues" lists several important things that need to be worked out and 3. has some rationale for the design decisions. Note that the paper has the basic structure of a standard proposal, but is not written in standardese nor is it "polished" (since it will be merged into another paper and probably re-worded). It is my first attempt at a standard proposal and I'm not a member of the Committee so please bear with me :-). Dean and I have also independently decided to write proof-of-concept implementations - compiler extensions for clang and gcc respectivelly. The sources for the gcc plugin are hosted here: https://github.com/matus-chochlik/std_cpp_refl It's in a very early stage, but if someone has some tips or hints they'll be welcome. Thanks in advance for any (negative or positive) feedback. Best regards, Matus Chochlik

6 19

[assign] How to create a container wrapper for tuple_list_of
by Robert Dailey 26 Apr '12

26 Apr '12

I have a vector of boost::tuple objects that is a member variable in a class of mine. I want to be able to create an instance of my wrapper class and construct it off of a tuple_list_of(), and essentially forward those values to the container itself. I haven't seen a way to do this yet. An example is below. Note that my constructor in the class was my attempt to get this working, but instead it will not compile. For some reason boost.assign thinks that the EnumErrorInfo class is the container. template<class T> class EnumErrorInfo { public: typedef boost::tuple<T, char const*, char const*> Tuple; typedef std::vector<Tuple> TupleVector; EnumErrorInfo( TupleVector const& assignment ) : m_errorInfo( assignment ) {} Tuple const& getErrorInfo( T error_code ) { TupleVector::const_iterator it = std::find_if( m_errorInfo.begin(), m_errorInfo.end(), MatchErrorCodePred( error_code ) ); if( it != m_errorInfo.end() ) { return *it; } static Tuple const unknown_info( error_code, "????", "No error info available for this code" ); return unknown_info; } private: class MatchErrorCodePred { public: MatchErrorCodePred( T error_code ) : m_errorCode( error_code ) {} bool operator() ( Tuple const& t ) { return t.get<0>() == m_errorCode; } private: DomInterfaceErrors m_errorCode; }; TupleVector m_errorInfo; }; And here is how I'd like to initialize the class: EnumErrorInfo<DomInterfaceErrors> g_errorInfo = tuple_list_of ( GDE_OK, "GDE_OK", "DBL: Opeartion successfully completed" ) ( GDE_GDD_DIRUSERS, "GDE_GDD_DIRUSERS", "AQX: Unable to get directory users." ) ;

2 1

[interprocess] Sharing shared_memory_object across processes?
by Joseph Van Riper 26 Apr '12

26 Apr '12

I either do not understand what I am seeing, or I may have stumbled upon a bug, at least in a Windows environment. Or, of course, my expectations may be unrealistic. The short of this is that when I create a boost::interprocess::shared_memory_object that isn't removed for the duration of the program's run, the reading program's run can't seem to open the shared_memory_object, despite creating a boost::interprocess::permissions object and calling 'set_unrestricted()'. I get an exception indicating that access is denied. If nothing else, the code I've provided is an interprocess version of the classic read-writer's problem, second version (writers preferred). It may be of use to someone with a little cleaning. Environment: Compiler: MSVC++ 10 OS: Win 7 Pro, 64-bit. Steps to reproduce: 1. In VC++ 10, create an empty command-line project. 2. Replace contents of your .cpp with the code in this e-mail. 3. Compile. 4. Run the executable twice, first with an argument, next without. Expected results: The executable run without arguments indicates how much data was transferred on the same line. Actual results: The executable run without arguments complains that access is denied. NOTE: If you #define BOLD_NEW_TEST and recompile, this program runs according to expectations. This causes the objects to be compiled in a way where the shared_memory_objects only last for as long as it takes to write or read the data. I suspect this shouldn't be necessary, but perhaps I'm wrong. The error is especially peculiar to me, as I can open the file itself with a text editor. It doesn't seem like it should be denied. - Trey

2 3

[result_of] Make `cpp0x_result_of_impl` public
by Michel Morin 26 Apr '12

26 Apr '12

There are two implementations of boost::result_of: a TR1-style implementation and a decltype-based implementation. While the TR1-style implementation has a public interface `boost::tr1_result_of`, decltype-based one doesn't have a public interface. By defining BOOST_RESULT_OF_USE_DECLTYPE, boost::result_of use decltype-based implementation. But this is not always a viable solution, since this breaks some Boost libraries. So how about adding `boost::cxx11_result_of` as public interface of the decltype-based implementation? Attached a patch to add `boost::cxx11_result_of`. (This patch also changes the name of `cpp0x_result_of_impl` to `cxx11_result_of_impl` to reflect the recent discussion on the cpp/cxx naming.) P.S. Is it worth trying to use this `boost::cxx11_result_of` in `boost::transform_iterator` code on trunk? Regards, Michel

7 40

[result_of] Regression: compilation errors on C++03 compilers when defining BOOST_RESULT_OF_USE_DECLTYPE
by Michel Morin 25 Apr '12

25 Apr '12

If we define BOOST_RESULT_OF_USE_DECLTYPE, boost::result_of tries to use decltype-based implementation even on C++03 compilers. This causes compilation errors and it is a regression on C++03 compilers. Is it intentional change? Regards, Michel

5 6

[utility][assert]
by Yechezkel Mett 25 Apr '12

25 Apr '12

I noticed that when BOOST_ENABLE_ASSERT_HANDLER is defined, BOOST_ASSERT calls boost::assertion_failed whether or not NDEBUG is defined, but BOOST_ASSERT_MSG calls boost::assertion_failed_msg only if NDEBUG is not defined. Is there a reason for this difference?

1 0

[exception] applying patch for issue #6349
by David Deakins 24 Apr '12

24 Apr '12

Hi Emil, Since the issue in item #6349 is disrupting the Windows CE test results for many libraries, do you mind if I go ahead and apply the patch attached to that item? Thanks, -Dave

2 1

[Iterator] Fixing the default reference type of transform_iterator (#5127)
by Michel Morin 24 Apr '12

24 Apr '12

The default reference type of transform_iterator should be boost::result_of<const UnaryFunction(Iterator::reference)> rather than boost::result_of<UnaryFunction(Iterator::reference)> since the dereference operator of transform_iterator is a const member function. Ticket #5127 describes this bug https://svn.boost.org/trac/boost/ticket/5127 and the ticket has a patch. Jeff, could you apply the patch, if it looks OK? Regards, Michel

3 7

[contract] assertion requirements as meta-functions or not?
by lcaminiti 24 Apr '12

24 Apr '12

Hello all, Boost.Contract allows to specify "assertion requirements": /assertion-condition/, requires /assertion-requirement/ If the requirement is not met then the assertion condition is neither compiled nor checked at run-time. Question: Shall the assertion-requirement be a nullary boolean meta-function or just a static boolean value? For example: CONTRACT_FUNCTION( template( typename T ) requires( boost::LessThanComparable<T> ) (T const&) (min) ( (T const&) x, (T const&) y ) postcondition( auto result = return, x < y ? result == x : result == y, requires boost::has_equal_to<T>::value // static boolean ) ) { return x < y ? x : y; // OK: T is less than comparable `<`. } For now, the assertion requirement is a static boolean value so it can be more easily manipulated (using !, &&, ||, etc instead of mpl::not, mpl::and, mpl::or, etc). However, is there any strong reason for marking the assertion requirement a nullary boolean meta-function instead like the following code? x < y ? result == x : result == y, requires boost::has_equal_to<T> // meta-function Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-assertion-requirements-as… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 5

[Fusion] Patch: fixing some test failures on clang
by Michel Morin 24 Apr '12

24 Apr '12

The following tests of Boost.Fusion fail on clang trunk in a C++11 mode with libc++. * io.test * deque_construction.test * deque_misc.test * std_tuple_iterator.test * invoke.test Attached a patch for fixing two failures (io.test and std_tuple_iterator.test) of them. Regards, Michel

2 1

Search a vector of tuples?
by Robert Dailey 23 Apr '12

23 Apr '12

Is there a method in the boost library to iterate a vector of boost::tuple objects, comparing the 1st element in the tuple of each tuple to a value that I specify? My tuple is setup like so: typedef boost::tuple<int, int, char const*> Tuple; typedef std::vector<Tuple> ErrorStringMap; ErrorStringMap mystrings = tuple_list_of (10, "10", "ten") (20, "20", "twenty") (30, "30", "thirty") (10, "10", "ten"); I want to search the vector of tuples and do something with every tuple that has the number 10 as the first element in the tuple.

7 15

[concept_check] addable
by lcaminiti 23 Apr '12

23 Apr '12

Hello all, Does this Addable concept definition make sense to you? Is there any error? #include <boost/concept_check.hpp> template<typename T> struct Addable { // User-defined concept. BOOST_CONCEPT_USAGE(Addable) { return_type(x + y); // Check addition `T operator+(T x, T y)`. } private: T x; T y; void return_type(T const&); // Used to check addition returns type `T`. }; It's not making Sun's linker happy: "/opt/sunstudio12.1/bin/CC" -g -library=stlport4 -features=tmplife -features=tmplrefstatic -library=stlport4 -m64 -KPIC -o "/scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq" "/scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq.o" -Bdynamic -lrt -Bstatic -Bdynamic Undefined???first referenced symbol ??? in file void Addable<int>::return_type(const int&) /scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq.o ld: fatal: Symbol referencing errors. No output written to /scratch2/kbelco/boost/results/boost/bin.v2/libs/local_function/test/typeof_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/typeof_seq But the error might also be somewhere else in the program that checks the concept, I'm still debugging... Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-concept-check-addable-tp4572138p45… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 5

[filesystem] #6521 Directory listing using C++11 range-based for loops
by Beman Dawes 23 Apr '12

23 Apr '12

Ticket #6521 requests adding: class directory{ path p_; public: inline directory(path p):p_(p){} directory_iterator begin(){ return directory_iterator(p_); } directory_iterator end(){ return directory_iterator(); } }; so that that a range-based for loop can be used: for (auto itr : directory(".")) { cout << itr.path() << endl; } The above works as expected on GCC 4.6 and VC++ 11 beta. Is that the best way for filesystem directory iteration to support range-based for? Provide a class directory_tree for recursive iteration? --Beman

4 13

1.50 release calendar
by Vicente J. Botet Escriba 23 Apr '12

23 Apr '12

Hi, I would like to know the 1.50 release calendar so that I can plan with Anthony Williams the merge to release of Boost.Thread of version 3. Which is the last day to merge to release a big change? Thanks for all, Vicente

3 3

[range] Question about adapted range safety given C++11 auto
by Beman Dawes 22 Apr '12

22 Apr '12

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html claims: "Boost's range library focuses on defining a set of Range concepts that allow Containers to be Ranges. Because Containers are heavy-weight, this forces Boost to use references for all of their uses of Ranges, including Ranges that are captured by Range Adapters. This worked fine in C++98, where users couldn't name the types of the Range Adapters in order to declare local variables, but with C++11's auto keyword, users can now save adapted ranges. Since Boost's adapted ranges capture references to their arguments, which can be temporaries, this is no longer a safe design." Is this claim correct? If so, what's the real-world impact? --Beman

4 3

[context] [windows] Intel C++ and GCC Support?
by Joshua Boyce 22 Apr '12

22 Apr '12

I notice that Boost.Context only seems to support MSVC under Windows, and attempts to compile it under GCC or Intel C++ will fail because it's not correctly assembling fcontext_i386_ms_pe_masm/fcontext_x86_64_ms_pe_masm. e.g. Under Intel I get: intel-win.compile.asm > C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj '-c' is not recognized as an internal or external command, operable program or batch file. > -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DWINVER=_WIN32_WINNT_VISTA > -D_WIN32_WINNT=_WIN32_WINNT_VISTA -DBOOST_ALL_NO_LIB=1 > -DWINVER=_WIN32_WINNT_VISTA -D_WIN32_WINNT=_WIN32_WINNT_VISTA /Zi /Zd /W3 > -Fo > "C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj" > "C:\Users\Josh\Documents\code\boost-trunk\libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm" > ...failed intel-win.compile.asm > C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\intel-win\debug\address-model-64\architecture-x86\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.obj... Whilst under GCC (via MinGW-w64) I get: Jamfile</C:/Users/Josh/Documents/code/boost-trunk/libs/context/build>.masm64 C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o 'ml64' is not recognized as an internal or external command, operable program or batch file. ml64 /c /Fo"C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o" "C:\Users\Josh\Documents\code\boost-trunk\libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm" ...failed Jamfile</C:/Users/Josh/Documents/code/boost-trunk/libs/context/build>.masm64 C:\Users\Josh\Documents\code\boost-trunk\bin.v2\libs\context\build\gcc-mingw-4.7.0\release\address-model-64\architecture-x86\debug-symbols-on\link-static\runtime-link-static\threading-multi\asm\fcontext_x86_64_ms_pe_masm.o... This occurs for both 64-bit and 32-bit compilation. Is this a known issue with a planned fix? Or is MSVC the only compiler supported under Windows? (I know it's a pain because GCC afaik uses a different assembly syntax... Not sure about Intel.) As an aside, Boost.Context does not yet seem to have an entry in Trac. Thanks.

3 9

[Proto] Errors due to narrowing conversions in matches.hpp
by Michel Morin 22 Apr '12

22 Apr '12

Some tests of Boost.Phoenix fail on clang trunk in a C++11 mode due to narrowing conversions of non-type template arguments, which are prohibited in C++11. Specifically, the narrowing conversions occur at Line 354 and 363 in boost/proto/matches.hpp. They can be simply resolved using `static_cast<bool>(...)`. Regards, Michel

2 3

[thread] Do we need thread_group now?
by Vicente J. Botet Escriba 21 Apr '12

21 Apr '12

Hi, now that we have Boost.Container and Boost.Thread (trunk) uses Boost.Move, boost::thread_group has less sense. I was thinking on replacing it by some generic algorithms as join_all, interrupt_all that work with generic containers so that the user can use the best containers adapted to her own needs. typedef boost::container::vector<boost::thread> thread_vector; { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } join_all(threads); } { thread_vector threads; for (int i = 0; i < 10; ++i) { threads.push_back(boost::thread(&increment_count)); } interrupt_all(threads); } Could boost::thread_group be deprecated once these generic algorithm are released? Or, is there something really useful on the thread_group class that needs to be preserved or even improved? Best, Vicente

7 13

[iterator] iterator-category logic
by Jeffrey Lee Hellrung, Jr. 21 Apr '12

21 Apr '12

I'd like to ask Boosters' opinions on this. boost::iterator_facade determines the iterator_category via the logic outlined in http://www.boost.org/doc/libs/1_49_0/libs/iterator/doc/iterator_facade.html… In particular, if (a) CategoryOrTraversal is a Boost traversal tag; and (b) Reference is not a "real" C++ reference (i.e., a proxy reference); then iterator_category is at best convertible to std::input_iterator_tag. This ends up being surprising to users who use boost::iterator_adaptor (note that, by default, iterator_adaptor passes the Boost traversal tag of the adapted iterator down to iterator_facade) to adapt, say, a pointer, define their adapted iterator to return a proxy reference, and find out that their standard library functions don't recognize their adapted iterator as a random access iterator. The usual workaround tends to be to just override the iterator_facade logic yourself to use a more refined iterator_category and hope your standard library functions don't barf. For better or for worse, the present logic in iterator_facade is strictly (more or less) correct given the C++03 iterator requirements, but I just looked up the N3290 draft of C++11 and it appears that any requirements that *i return a real reference have been dropped, thus allowing for proxy references in all iterator categories. (a) Am I interpreting the C++11 iterator requirements correctly? (b) If so, should iterator_facade's iterator-category logic be reworked to account for the new requirements? (c) If so, how should it be determined when to use the C++03 requirements and when to use the C++11 requirements? Thanks, - Jeff

3 3

[review schedule] Broken link to Coroutine documentation
by Mateusz Loskot 21 Apr '12

21 Apr '12

Hi, There is Coroutine library by Oliver Kowalke proposed for review. The link to Documentation points to...the review schedule at http://www.boost.org/community/review_schedule.html Is there any chance to have it fixed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost.Variant swap performance
by David Sankel 21 Apr '12

21 Apr '12

It seems as though Boost.Variant doesn't take advantage of pointer swaps when it comes to use of recursive variants. In the attached file I declare a simple int list type and include two implementations of a function that adds an int to the front of a list. The first implementation, I would expect to be O(N) on the size of the list and the second implementation to be O(1) on the size of the list. Unfortunately, the output I get is: unoptimized ilPushFront: 129 unoptimized ilPushFront w/ larger list: 363 optimized ilPushFront: 211 optimized ilPushFront w/ larger list: 653 Any ideas why this might be happening? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

2 3

[shared_ptr] [intel] Compile Errors with '#include <atomic>'
by Joshua Boyce 20 Apr '12

20 Apr '12

Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have). The problem is simple to repro: #include <atomic> #include <boost/shared_ptr> int main() { } The problem has been reported previously, but even in the latest version of the compiler (created and released well after the bug report) the problem seems to remain: http://software.intel.com/en-us/forums/showpost.php?p=160114 Here is a patch which I have used locally to successfully work around the problem, but I get the feeling that there is a better solution I'm overlooking... http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-shared_ptr-intel-fix-… Has anyone else run into this problem who has come up with a better solution? Alternatively, if this is as good as it's going to get (maybe using a BOOST_WORKAROUND would be better so it can be disabled when/if the issue is fixed), would anybody be able to apply this to trunk? Thanks.

1 1

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 20 Apr '12

20 Apr '12

> >> I believe that a portable implementation of the proposed std::decimal > >> (eg Decimal Types for C++ would be useful. > Of course this is definitely something Boost needs in its tool chest. > But to 'sell' it to Boost, I think it is important to relate to commercial offerings and > previous proposals to WG21 C++ Standards. > > So say how and why you have done it differently? > > Paul I do not intend to create an implementation - I am simply wiring up the existing DecNumber, Intel Decimal Float implementations (both IEEE compliant) to the std::decimal interface. I believe the associated licences are compatible with boost being able to distribute this, but that would be the first thing to be checked. I have no idea how this differs from any other offering (apart from saying I hope it gives identical results to gcc's standard decimal) apart from pointing out I haven't found any C++ wrappers for the decimal floats that I would use 'off the shelf' in the same way I use boost libraries. I'm working on a somewhat blind assumption that if gcc is implementing this interface, it is probably the closest thing to what will eventually end up in the standard. If there are other implementations that do roughly the same thing, I'd be really interested to take a look, as I've no desire to reinvent the wheel!

2 1

Release branch merge
by Dave Abrahams 20 Apr '12

20 Apr '12

Since we're within the 7-week window, I'm asking permission to patch the release branch per the enclosed: -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[coroutine][context] coroutine_specific_ptr proposal
by Taylor Goodhart 19 Apr '12

19 Apr '12

With the context/coroutine library making great progress, in my mind it is only natural to wonder whether something analogous to thread local storage could be implemented for coroutines. I would propose using the existing thread_specific_ptr as a starting point. As for an initial design proposal, it seems to me like one could have a single static atomic integer in the constructor of coroutine_specific_ptr that is incremented for each new instance. This will allow each instance to know their index, and to also know the total number of pointers. Then when a new coroutine is created, a block of pointers of this size would be created and placed before stack memory. If a coroutine were to try to dereference a coroutine_specific_ptr then the index into this block would be looked up and if NULL, create a new instance on the heap. If not NULL, it would simply return the previously created value. Comments and feedback would be appreciated. If this seems like something people might use I'd be willing to take a crack at implementing it, provided Oliver's blessing. -Taylor Goodhart

1 0

[decimal] Proposed portable implementation of std::decimal
by Josh Quigley 19 Apr '12

19 Apr '12

Hi, I believe that a portable implementation of the proposed std::decimal (eg Decimal Types for C++ <http://tiny.cc/63ovcw> for older draft) would be useful. Since the standard specifies a class, a library should be able to achieve close to full compliance. At the moment I believe only gcc supports this. I'm currently working on this for my own purposes, and if there is sufficient interest (and guidance!) might try to expand it into a draft submission. Roadmap: 1. Implement std::decimal (see gcc version, for example) using Intel FP Decimal, DecNumber, native gcc, (maybe .NET Decimal depending on how close it is to complying with interface) 2. Some preprocessor trickery to make it easy to compile all implementation as separate classes (eg extension::decimal::Intel::decimal64), or a given implementation as the 'one true' class (extension::decimal::decimal64). This means unit tests and performance tests can be written using one implementation against another, and for production code, a given implementation can be used under the hood depending on the architecture. 3. Create performance and standards-compliance benchmarks for implementations. 4. Choose default implementation for each supported architecture, based on benchmarks. The above is a personal roadmap, of which a subset may be of interest to the boost community. Please let me know if you think this would be of value, and in particular if you would like to be involved in creating / testing / using this. Regards, Josh.

4 3

Google Groups
by Mark Snelling 19 Apr '12

19 Apr '12

Hi, Has anyone noticed that the Google Groups feeds of both boost-users and boost-devel have stopped updating? There was this posting to the Boost devel archive on the 18th regarding message bounces https://groups.google.com/forum/?fromgroups#!topic/boost-devel-archive/Ip24… Mark.

1 0

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 19 Apr '12

19 Apr '12

Thanks for link to more recent draft. I've finished a rough implementation using the Intel lib, and am currently working on unit tests to at least cover the std::decimal interface. What is the preferred way to share this (when ready)? Josh.

1 0

[Serialization] How to force an archive to store true_type even if it is this_type?
by nico 18 Apr '12

18 Apr '12

Hello. When we serialize a polymorphic object, an archive stores the information about true_type (i.e. the concrete type of an object) only if it is not equal to this_type (i.e. the type of the serialized object). I.e. : the type of the serialized object is stored only if it is serialized from a base class. How can I force the archive to always store the type? Let's illustrate with a sample, I'm not sure the above text is so obvious...: Let's have 2 classes serializable: class Base { ... }; class Leaf : public Base { ... }; If I do : std::stringstream ios(std::ios_base::binary | std::ios_base::out | std::ios_base::in); * Base** b = new *Leaf*(); boost::archive::text_oarchive ar(ios); ar & b; Then the archive contains: 22 serialization::archive 9 0 4 *Leaf* 1 0 0 0 0 0 0 0 0 It contains the Leaf concrete type information. However if I do : * Leaf** b = new *Leaf*(); boost::archive::text_oarchive ar(ios); ar & b; Then the archive contains: 22 serialization::archive 9 0 1 0 0 0 0 0 0 0 0 It doesn't contain Lef type info. How can I produce an archive WITH the true_type all the type? I search 2 ways: - calling a method of archive type (register_type, save_pointer, ...) unsuccessfully - directly change the boost/archive/detail/oserializer.hpp file: in struct polymorphic, in function template<class T> static void save(Archive &ar, T & t) I comment out if(*this_type == *true_type){ const basic_pointer_oserializer * bpos = register_type(ar, t); ar.save_pointer(vp, bpos); return; } unsuccessfully. Thank you for help. Nicolas. PS : a word about why I'm trying to do that. When the true_type is "registered" (I'm not sure register is the right word), we can deserialize the object to any base class. Exemple: SERIALIZATION: Leaf* leaf = new Leaf(); ar & leaf; SERIALIZATION: Base* b = 0; ar & b; // would work only if Leaf has been saved in the archive as true_type For tools in a multi-team project, it' powerfull : data for tests has been serialized by a team, and the other team can deserialize, let's say an image, to the interface class IImage without asking: what was the true_tyep : an Image3D, an AImage2D, an Image2DRGB, an Image2DRAW, and so on.

2 1

[disjoint_sets] 1.49.0 docs out-of-date? pending?
by Jeffrey Lee Hellrung, Jr. 18 Apr '12

18 Apr '12

I noticed that http://www.boost.org/doc/libs/1_49_0/libs/disjoint_sets/disjoint_sets.html references boost/disjoint_sets.hpp but, AFAICS, no such file exists; however, clicking on the file nonetheless redirects to boost/pending/disjoint_sets.hpp which presumably is the intended reference. So, aside from what looks like a slight error in the present disjoint_sets docs, what is the purpose of this pending directory? I had never noticed it before and I don't remember stumbling upon a reference to it until now. Looks like it contains a hodgepodge of miscellaneous headers... Thanks, - Jeff

4 4

[test] Am I supposed to be able to use std::wstring in BOOST_CHECK_EQUAL?
by Michael Kochetkov 18 Apr '12

18 Apr '12

Hello, Am I supposed to be able to use std::wstring in BOOST_CHECK_EQUAL? I.e. std::wstring s1,s2; BOOST_CHECK_EQUAL(s1,s2); -- Michael Kochetkov

6 7

regression test link broken?
by lcaminiti 18 Apr '12

18 Apr '12

Hello all, Are the regression tests broken? When I go to: http://www.boost.org/development/tests/trunk/developer/summary.html I get: Error extracting file: The specified zipfile was not found. Same for both trunk and release tests. I hope it wasn't me ;) --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-test-link-broken-tp4565… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 6

[type_traits][exception][interlocked][smart_ptr] Intel XE 2011 SP1 compiler warnings
by Beman Dawes 18 Apr '12

18 Apr '12

Compiling libs/test/src/execution_monitor.cpp is producing a lot of warnings from the Intel XE 2011 SP1 compiler for Windows: [type_traits] ..\..\..\boost/type_traits/detail/is_mem_fun_pointer_tester.hpp(74-2608): remark #693: calling convention specified here is ignored yes_type is_mem_fun_pointer_tester(R (__stdcall T::*const volatile*)( ...)); with the error marker under the start of __stdcall. There are about a gazillion lines with the same error. [exception] ..\..\..\boost/exception/exception.hpp(258-260): remark #367: duplicate friend declaration friend struct exception_detail::get_info<throw_function>; [interlocked] ..\..\..\boost/detail/interlocked.hpp(79-83): warning #1879: unimplemented pragma ignored # pragma intrinsic( _InterlockedIncrement ) [smart_ptr] ..\..\..\boost/smart_ptr/detail/yield_k.hpp(33): warning #1879: unimplemented pragma ignored #pragma intrinsic( _mm_pause ) It would be nice to clear these warnings. Thanks, --Beman

1 0

[math] Numeric constants docs out of date?
by Beman Dawes 17 Apr '12

17 Apr '12

The docs for Numeric Constants seems out-of-date compared to the <boost/math/constants/constants.hpp> header. See http://www.boost.org/doc/libs/1_49_0/libs/math/doc/sf_and_dist/html/math_to… For example, the docs list 15 constants, but the header supplies 65 or so constants. Beyond simply missing some functions, the description is so scanty it looks like it may be for a much less capable older version of the header. Am I missing something? --Beman

5 8

Re: [boost] [Boost-commit] svn:boost r78033 - trunk/libs/context/src
by Joshua Boyce 17 Apr '12

17 Apr '12

On Tue, Apr 17, 2012 at 5:31 PM, <oliver.kowalke(a)gmx.de> wrote: > Author: olli > Date: 2012-04-17 03:31:34 EDT (Tue, 17 Apr 2012) > New Revision: 78033 > URL: http://svn.boost.org/trac/boost/changeset/78033 > > Log: > icontext: use snprintf in seh handler > > Text files modified: > trunk/libs/context/src/seh.cpp | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > Modified: trunk/libs/context/src/seh.cpp > > ============================================================================== > --- trunk/libs/context/src/seh.cpp (original) > +++ trunk/libs/context/src/seh.cpp 2012-04-17 03:31:34 EDT (Tue, 17 > Apr 2012) > @@ -26,7 +26,7 @@ > { > const char * accessType = ( info[0]) ? "writing" : "reading"; > const ULONG_PTR address = info[1]; > - _snprintf_s( description, len, _TRUNCATE, "Access violation %s > 0x%08X", accessType, address); > + snprintf( description, len, "Access violation %s 0x%08X", > accessType, address); > return description; > } > case EXCEPTION_DATATYPE_MISALIGNMENT: return "Datatype > misalignment"; > @@ -52,8 +52,7 @@ > case EXCEPTION_INVALID_HANDLE: return "Invalid handle"; > } > > - _snprintf_s( description, len, _TRUNCATE, "Unknown (0x%08X)", code); > - > + snprintf( description, len, "Unknown (0x%08X)", code); > return description; > } > > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit This breaks building under MSVC which does not have 'snprintf', only '_snprintf'. http://msdn.microsoft.com/en-us/library/2ts7cx93.aspx

1 0

Range to boost::array / make_array?
by Olaf van der Spek 16 Apr '12

16 Apr '12

Hi, Is there a convenient function to make an array from a range? I got a map with string keys which I'd like to replace with array<char, 32> keys, but I'm missing said function. -- Olaf

2 2

[Serialization] Is there a way to "stop" a polymorphic serialization at a given class level
by nico 16 Apr '12

16 Apr '12

Hello. I admit the subject is not really understandable, but you'll see it's not so obvious to summarize the question... I use the boost serialization system and its polymorphic base serialization feature. For that, and for serialization code instantiation, I use the registration macros BOOST_CLASS_EXPORT_KEY and BOOST_CLASS_EXPORT_IMPLEMENT. If I have a concrete class A in a inheritance tree like that : C is base of B is base of A ( C <|---B <|---A ) C is not instanciable (it has pure virtual functions) B is instanciable Is there a way to "stop" the serialization of a A object to B level? I mean: If I have this code: C* obj = new A(); // declare boost archive ar to serialize obj ar & obj; Is there a way to tell to boost serialization to serialize only until B. Why ? This obj serialized is deserialized in another application, where only C and B are known and used. A only defines technical stuff, but nothing with data (and serialization), so it will never be used as A*. I try with something like that : template<class Archive> void A::serialize(Archive & ar, const unsigned int version) { B* b = new B(static_cast<B*>(this)); ar & b; delete b; } but is there a more "boost-serialization-system" way ? (I expect no...) What do you recommend ? Thanks for help. Nicolas.

2 1

[thread] Move semantics and deprecation
by Vicente J. Botet Escriba 15 Apr '12

15 Apr '12

Hi, I have updated Boost.Thread to make use of Boost.Move with some significant improvements. Up to now the boost/thread/config.hpp file made use of Boost.Move by default. #if ! defined BOOST_THREAD_DONT_USE_MOVE #define BOOST_THREAD_USES_MOVE #endif After the discussion about deprecated features I think that it would be more convenient to don't change the default for the next release and let the users define this macro. There are some tests that need BOOST_THREAD_USES_MOVE. I will either add it explicitly on the test source code or define it when BOOST_THREAD_VERSION==2. What do you think? BTW, unfortunatly I've considered that the preceding Boost.Thread version was 1, while it was 2 (the first been the original one by William Kempf). Should the breaking changes be included using version BOOST_THREAD_VERSION==3? Anthony? Best, Vicente

1 0

[graph] Disjoint Sets - the secret library
by Daniel James 14 Apr '12

14 Apr '12

I was just comparing the library list on the website to the one in the repo, and I noticed 'disjoint sets' is listed on the website but not in 'libs/libraries.htm'. I think it either needs to added to 'libs/libraries.htm', or removed from the site. The header is in the 'pending' directory, and it doesn't seem to have been reviewed, so it looks like it should be removed from the site. It seems to be mainly used by the graph library, so maybe it could be subsumed by that? Also, the documentation isn't quite right as it says the header is at 'boost/disjoint_sets.hpp': http://www.boost.org/libs/disjoint_sets/ Does anyone have an opinion? (btw. I'm not suggesting removing the header, as that would break things) Daniel

2 2

Support for Boost.Hash in Boost.Array
by Marshall Clow 14 Apr '12

14 Apr '12

(In [77976]) I added support for Boost.Hash to Boost.Array I also added a basic set of tests. Please let me know if you see any problems. -- 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

2 1

[context/coroutine] split into two libs in trunk?!
by Oliver Kowalke 14 Apr '12

14 Apr '12

Hi, unfortunetly Giovanni decided to discontinue its boost.coroutine library and I was ask be several members of the boost community to provide a coroutine implementation using boost.context. I've refactored class context from lib boost.context so that I can provide coroutine<> and generator<> (following Giovannis interface proposal) based on context now. I'd like to split it into two libraries: - boost.context provides only context jumping facility (a.g. struct fcontext_t, start_fcontext()/jump_fcontext()/make_fcontext() and stack helper) - boost.coroutine contains coroutine<> and generator<> Might this be appropriate? regards, Oliver -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

6 19