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

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

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

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

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

5 8

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

06 May '15

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

9 10

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

29 Apr '14

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

9 16

[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

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

09 Sep '12

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

2 1

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

20 Aug '12

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

8 25

[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

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

07 Aug '12

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

16 67

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

30 Jul '12

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

11 18

[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

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

13 Jul '12

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

3 6

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

10 Jul '12

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

3 18

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

09 Jul '12

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

2 5

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

08 Jul '12

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

21 54

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

06 Jul '12

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

7 40

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

05 Jul '12

Release candidate files for 1.50.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

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

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. Features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86

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

04 Jul '12

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

2 3

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

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

9 20

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

03 Jul '12

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

6 8

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

03 Jul '12

Greetings, Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ? If there is no maintainer, can I become the maintainer ? If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs. Regards, Étienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

2 2

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

02 Jul '12

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

3 4

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

02 Jul '12

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

3 2

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

02 Jul '12

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

4 13

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

02 Jul '12

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

2 1

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

01 Jul '12

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

2 7

Formal Review Request: TypeErasure
by Steven Watanabe 30 Jun '12

30 Jun '12

AMDG I'd like to request a formal review of the TypeErasure library that I've posted about several times before here. The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. As an example of basic usage, we can simulate Boost.Any: any<mpl::vector<copy_constructible<>, typeid_<> > > x(10); int i = any_cast<int>(x); // i == 10 The library is available in the Boost Sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure/ You can download archives with pre-built documentation from http://sourceforge.net/projects/steven-watanabe.u/files/ Online documentation can be found here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ In Christ, Steven Watanabe

26 118

[exception] Boost.Exception and the C++11 standard
by Vicente J. Botet Escriba 30 Jun '12

30 Jun '12

Hi, I was wondering how Boost.Exception works on compilers supporting 18.8.5 Exception propagation. Can an exception thrown by a 3pp library by retrieved by boost::current_exception() by another library or application code? BTW, what is the degree of compliance of Boost.Exception respect to 18.8.5 Exception propagation and 18.8.6 nested_exception sections of the standard? Do you have a plan towards been C++11 compliant? Best, Vicente P.S. I know that I can ask myself the same kind of questions respect to Boost.Ratio/Chrono/Thread, but this should be covered on a separate thread ;-)

2 1

Re: [boost] A GUI Library
by jinhao 30 Jun '12

30 Jun '12

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote: > Hi, > > On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao(a)hotmail.com> wrote: > >> Is there any interest in this library? > > > My current understanding is that both Boost and the Standard C++ commitee > are interested in fully C++ library. > > However, the subject is complex and no library until now gathered > enough consensus to even get to the review stage of the boost process > (from memory). > You have to be ready for tons of feedback pointing problems. > > Now, I just read the websites but I have some questions: > > 1. can you write somewhere a big comparison between your library and other > popular GUI C++ libraries? Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all. Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization. > 2. if you want to submit your library to Boost, I think it would need to > be compatible (or maybe just use) boost.thread instead of your own solution I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions. > 3. the STR macro is a big problem, I think it will be a big source of > negative feedback. Now that we have boost.locale, would it be possible to > work with it instead? Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost. > 4. I understand how you can build a GUI application in a way that is > mostly a list of statements. Does it means that you'd better organize your > windows/forms "types" as constructor functions? (ok found this that > partially answer my question: > http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-…) > 5. It is said that Nana is cross-platform, but I don't see any > demonstration of this (nevermind, I just found this: > http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ ) > What are the target platforms? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now. > 6. Should it work in non-graphic contexts like command-line only display? > (I'm thinking about GUI working in bash for example) Yes, like ncurses. But now it is not able to work in such environment. > 7. Is it thought to be easily extendable? For example, can I write myself > a new front-end implementation and plug it in? The library provide a general method to implement a customer widget, and supports external image-processing algorithm implementation (http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-pr…) > 8. do you have an available example of complex application being built > with this library? Yes, but its language is Chinese, it is a stock software, a screenshot at http://sourceforge.net/projects/stdex The status of this library I give is alpha and the so library is not used widely. Best Regards! Jinhao

5 6

Meeting C++ - Call for Papers
by Jens Weller 30 Jun '12

30 Jun '12

Dear C++/boost community! I'm proud to announce the call for papers for the Meeting C++ conference! After having talked to some people in Aspen about the plans for a C++ conference in Germany, I've decided to give it a try. Meeting C++ will take place in November in Germany, as a 2 Day C++ conference. We are looking for speakers and possible talks at our conference in fall! Possible topics could include: * (modern) C++ * C++11 * boost * C++ Frameworks like Qt, wxWidgets, Ogre, ... * other C++ related topics You'll find more information and updates at the webpage http://meetingcpp.com Tickets will be available from July at our website. regards, Jens Weller -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

2 2

[config] request for BOOST_NO_CXX11_HDR_ATOMIC
by Tim Blechmann 30 Jun '12

30 Jun '12

preparing boost.lockfree for trunk, i need a good way to figure out if the <atomic> header is available. would it be possible to add a macro to detect that? BOOST_NO_CXX11_HDR_ATOMIC or the like? thanks, tim

3 6

[smart_ptr] Patch for #6824
by Brent Lewis 30 Jun '12

30 Jun '12

Regarding bug report: https://svn.boost.org/trac/boost/ticket/6824 I've attached a diff file

3 2

[nowide] Updates and Standalone Version
by Artyom Beilis 30 Jun '12

30 Jun '12

Hello all Booster, Boost.Nowide updates: The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. --------------------------------- I had updated the library: - Changed boost::nowide::convert to boost::nowide::widen, boost::nowide::narrow - Changed boost::nowide::args to restore an original values in destructor - Updated the docs. Also I had created a stand-alone version of the nowide library such that it does not require boost and can be build with CMake - the use is the same just change: #include <boost/nowide/foo.hpp> ... boost::nowide::fstream To #include <nowide/foo.hpp> ... nowide::fstream ------------ Looking forward for more comments on a library that I want to submit for a formal review. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Non-Boost: http://cppcms.com/files/nowide/nowide_standalone.zip Git Repo: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[make_shared]
by Yuriy Zubritsky 30 Jun '12

30 Jun '12

Regarding https://svn.boost.org/trac/boost/ticket/6829 (make_shared is slower than shared_ptr(new) in MSVC) Does anyone want to apply it? It contains patch inside. Thanks

1 0

[BGL] How can I measure the memory used by a Boost graph ?
by ShNaYkHs ShNaYkHs 29 Jun '12

29 Jun '12

Hi, I have a graph defined as follow: struct NodeData{ /*...*/ }; struct EdgeData{ /*...*/ }; typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> MyGraph; MyGraph G; This graph is updated iteratively (by adding/deleting some edges/vertices). At each iteration, I want to evaluate the memory space occupied by this graph G. How can I do that ?

2 1

Tickets 6123 an 7023
by Luke Camden 29 Jun '12

29 Jun '12

Hi, Is anyone willing to commit these patches for me? If the process is not too involved I don't mind rtfm & DIY as an answer. Cheers, Luke

2 1

[1.50.0] Boost release 1.50.0 available
by Beman Dawes 29 Jun '12

29 Jun '12

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

3 4

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 29 Jun '12

29 Jun '12

Emil Dotchevski: >On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> Emil Dotchevski: >> >> > >> > There are 3 aspects of boost::throw_exception: >> > >> > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, >> > 2) it enables boost::error_info, and >> > 3) it enables boost::exception_ptr. >> > >> > 1) and 2) have nothing to do with threads; 3) implements >> > std::exception_ptr, which mostly benefits multi-thread programs (until >> > compilers catch up with std::exception_ptr support.) >> > >> > The cost imposed by libraries that use boost::throw_exception to programs >> > that don't use boost::exception_ptr or boost::error_info is that sizeof() >> > the exception object grows a little. >> >> I'd appreciate a way at compile time to let Boost Exception know >> I'm using it in a single threaded application and it wouldn't add stuff >> to the exception object that isn't needed. Also MSDN says, >> "Most applications do not have to transport exceptions between threads." >> > > There are exception_ptr use cases for single threaded programs. I'm not asking for this to be the default even for single threaded programs. I'd like it to be something that a user could opt out of if they want to. (This is all based on the possibilty that Boost Exception could become required. If that doesn't happen, this request wouldn't be very pressing from my perspective.) I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr. "The reason here is that construction/destruction of an exception_ptr are not "cheap"" Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 5

Exact Decimal library
by Andrew Robb 29 Jun '12

29 Jun '12

Introduction C++ needs UTF-8 text (Boost.Locale) and exact decimal types support. Together they allow full processing of modern business text. Normal existing binary exponent types (float, double and long double) are not suitable for exact decimal numbers. The IEEE 754-2008 decimal exponent types should be allowed in binary files. Most processors already use IEEE 754-1985 for binary exponent types. IBM processors already support IEEE 754-2008 decimal exponent types in hardware and can used for optimization for exact decimal. Other processors may use fixed-point exact decimal. Exact Decimal Exact decimal numbers indicate not only the value but also the precision. Thus 0.3 and 0.30 indicate the same value but with different precisions. With rounding, the value 0.3 indicates a value between 0.25 and 0.35 but the value 0.30 indicates a value between 0.295 and 0.305. These are different ranges albeit different around the same centres but must be considered different because of their precisions. Currency values are ‘exact’ as there is no legal or commercial meaning in between the smallest adjacent values defined precision. Even when the GBP went decimal with a halfpenny coin, most banks would only keep values to the penny. A lot of normal commercial exact decimal values can be held in 32-bit with fixed-point decimal to 2 places (USD, EUR and GBP currencies) up to about 20,000.00 - more than enough for weekly groceries. As such, they are as quick as 32-bit integers for addition and subtraction an nearly as fast for multiplying too. Exact decimal processing would not require IEEE 754-2008 decimal exponent types and could use decimal fixed-point indest. Indeed, the range of significand could be more than used by IEEE 754-2008 decimal exponent types (e.g. java.math.BigDecimal). Embedded processors can support fast exact decimal their own way (floating or fixed). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf Extensions to support embedded processors must not give a general range decimal fixed-points. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf Extension for the programming language C to support decimal floating-point arithmetic. Again, from IBM and not for decimal fixed-point type. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf Extension for the programming language C++ to support decimal floating-point arithmetic. Unfortunately the paper looks only at the IEEE 754-2008 hardware implementation rather than using decimal fixed-point implementation. The proposed solution might be enough for high-end database servers but not would helpful for x86 and ARM type embedded processors, where power savings for would be allowed by turning off the binary exponential processor as well as improved accuracy. For existing binary exponent types (float, double and long double), I think there should be new format string type (e.g “-123U-12”). This has a signed integer significand and a signed integer binary exponent. The significand cannot have decimals (no decimal point). Those IEEE 754 formats can indicate “Inf” and “NaN” as well (numeric_limits::is_iec559). There is no conversion error from binary exponent to decimal as is suffered currently. The new decimal types use a opaque arrangement. This allows each platform to use its own hardware to best effect. Each value is defined as a fixed number of decimal points. The significand grows or shrinks opaquely to take any value and can change how it works for each type. The fixed number of decimal points can be over the thousands before or after the decimal point. Thus the range of the decimal fixed points will be the same or more than those for decimal exponent types (-6143..6144). The significand has a least maximum 34 digits, again to match for decimal exponent - probably at least 38.23 for 128-bit significand. The method of keeping the significand can change with size and processor. For instance, 32-bit binary is fast on 32-bit processors (or 64-bit native binary). 30-bit (9 digit) or 10-bit (3 digit) decimal can grow (BigDecimal) for thousands of digits. IEEE 754 2008 decimal exponent types for IBM processors (also 10-bit groups of 3 digits) but slow without hardware support. Much of the work of exact decimal are similar to the SQL-92 types for NUMERIC (variable decimal places) and DECIMAL (fixed-point decimal) differ by variable or fixed decimal point. The NUMERIC type is similar to decimal exponent. The DECIMAL fixed-point decimal can be set by template or constructor. Only run-time decimal places available for NUMERIC. We don’t limit the number of decimal places but the SQL-92 types limit decimal places to 0 and number of digits (MySQL 5.0.3 supports 65 digits for NUMERIC and DECIMAL and DB2 supports 31 digits.) Accumulators There should be _Accum that can opaquely contain several decimal fixed-point accumulators of all different sizes (with the same fixed number of decimal points). Thus small efficient accumulators are used with small values. Whereas a _Decimal has a union defining the value, a _Accum might have a structure with similar members. If a overflow comes, its old accumulator value is added the to a slower bigger accumulator and reset the small accumulator. The small accumulator receives small values again. When the values are accumulated, the small accumulators are combined into the largest used accumulator for the final answer. Such a complicated behaviors arrangement needs compilation rather than C++ coding. For instance, using the overflow flag uses information from to the compiler. Operations We are only interested in (commercial) safe exact decimal operations for the following types: _Numeric: decimal exponent _Decimal: decimal fixed-point _Accum: several sized decimal fixed-point accumulators Multiply The exact decimal can be multiplied by other exact decimals and integers. The resulting decimal places are the sum of the right hand side. lhs = one * two; lhs *= integer; // or 0 decimal place Divide We can only divide by integers (or exact decimal with 0 place). The results have the same number of decimals. A divisor of zero will be thrown (no infinity). lhs = rhs / integer; lhs /= integer; Modulo There will be a remainder from a divide. Again with the same number decimals. lhs = rhs % integer; lhs %= integer; Add and Subtract We can add/subtract with other exact decimals with the same number of decimal places. Mixing values with different decimal places may cause problems for exact values (different truncation for instance). lhs = rhs + val; lhs = rhs - val; lhs += val; lhs -= val; Where values with different decimal places need combining explicitly we use trunc() to match the decimal places first. This can increase as well as decrease decimal places. It also allows tracks of errors. Comparison <, <=, ==, !=, >= and > between exact decimals with the same number of decimal places. Collections Any _Decimal collection can be limited to values with the same decimal fixed-point places. Truncation The binary exponent values float, double and long double have separate approximate values 1.3f, 1.3 or 1.3L for different sizes. I propose another exact decimal value, for example 1.300d for three decimal places. Alternatively use exact decimal exponent 1300e-3d version (using integer significand). Value Approximation 1.3f - 1.2999999523162841796875.. 1.3 - 1.3000000000000000444089209850062616169452.. 1.3L - 1.3000000000000000000000000000000000385185.. 1.300d or 1300e-3d - 1.300 (exact) Where a value is not the precision, we must expand or truncate to required decimals places and should choose a method of truncation (matched to IEEE 754-2008): ceil - the most negative answer not less than the original floor - the most positive answer not greater than the original zero - the answer furthest from zero not further than the original (the usual C method) round - the answer nearest the original choosing the most positive in case of a tie bank# - like round but choosing the even last digit in case of a tie expand - not truncation (zero padding) and the error should be zero As well as tructaton is then required value, there were be a leftover (similar in % value with a /). By keeping a record of truncation we can assess of errors. template <typename T> _Decimal & _Decimal::trunc(TRUNC, T const &source, T *error = 0); This will be a preferred way to convert binary exponent types into a decimal value for printing. Formatting For place 0 decimal format like integer and between places 1 and 9, the format will be decimal and trailing zeros are significant. Otherwise with the default format will be a exponent (matched to the decimal) with a integer significand. They will resemble binary float types, except that they are accurate and avoid decimals in the significand. 123 (0 decimal place so no decimal point) -0.012340 (6 decimal places) -12340e-12 (12 decimal places or decimal exponent -12) Final number formatting will be up to Boost.Locale using Unicode.

2 1

Range notation grammar
by Dave Abrahams 29 Jun '12

29 Jun '12

This ship has undoubtedly sailed, but I'd like to register my displeasure with names like "uniqued," "taken," and "strided" et. al. The effect (subjectively of course) is to take a beautiful, minimal abstract notation that reflects a common practice (seriously, it's "grep," which is a verb, not "grepped") and mess it up with unconventional and awkward linguistic insurance against misunderstanding. this-has-been-a-test-of-the-emergency-nattering-system-ly y'rs, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

date_time bug.
by GAURAV GUPTA 29 Jun '12

29 Jun '12

Hi All, I have reported one bug: Ticket No:7022. (Link is https://svn.boost.org/trac/boost/ticket/7022 ) As I have tracked. the owner (you can see it on ticket information) assigned to my ticket is not active. I have not found any posts by him newer that year 2007. So, could anyone help in verifying my patch for the reported bug?. I found this bug using some tool. Please reffer the ticket No. 7022 -- Regards, Gaurav

2 4

[review] status of Boost.Conversion?
by Nathan Ridge 29 Jun '12

29 Jun '12

Hi, I am wondering, what is the status of the Boost.Conversion library? On the Review Schedule page, it indicates that a review had taken place in August 2011 and the results of the review are "pending". Does anyone when the results will be forthcoming? Thanks, Nate

4 7

JNI library
by Felipe Magno de Almeida 28 Jun '12

28 Jun '12

Hello Boosters, I'm developing a JNI library for writing native code in C++ for Java and calling Java code within C++, using JNI as interface to the JVM. Is there any interest in this library? Regards, -- Felipe Magno de Almeida

3 10

[Survey] utf8_codecvt_facet::do_length parameter
by Marshall Clow 28 Jun '12

28 Jun '12

There's some confusion in boost (and in various standard libraries) as to the declaration of std::codecvt<>::do_length The '03 and '11 standards say: > template <class internT, class externT, class stateT> > class codecvt : public locale::facet, public codecvt_base { > // blah blah blah > virtual int do_length(stateT&, const externT* from, const externT* end, size_t max) const; > }; But some standard libraries (notably older Dinkumware libraries, and Visual C++ before Visual Studio11) say: > virtual int do_length(const stateT&, const externT* from, const externT* end, size_t max) const; (the first parameter is a const reference) There's some preprocessor stuff to deal with this in boost/detail/utf8_codecvt_facet.hpp, but it's wrong: > #if !defined(__MSL_CPP__) && !defined(__LIBCOMO__) \ > && !defined(_LIBCPP_VERSION) > #define BOOST_CODECVT_DO_LENGTH_CONST const > #else > #define BOOST_CODECVT_DO_LENGTH_CONST > #endif > > virtual int do_length( > BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &, > const char * from, > const char * from_end, > std::size_t max_limit > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > ) const throw(); > #else > ) const; > #endif I'm happy to fix this, but I'd like to be sure which systems actually have const parameters. I've checked gcc and libc++, and they match the standard. STL assures me that all versions of Visual Studio before VS11 do not match, but VS11 does. The #defines above suggest to me that LibCOMO has this problem as well. Does anyone have access to such an install? And if anyone's standard library (that I haven't listed) does define the first parameter to std::codecvt<>::do_length as a const reference, please let me know. Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[1.50.0] Release candidate 2 available for testing
by Beman Dawes 28 Jun '12

28 Jun '12

Release candidate 2 files for 1.50.0 are available at http://boost.cowic.de/rc/ RC 2 is supposed to fix the --layout build problems reported for RC 1. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

7 7

[chrono] chrono/config.hpp enforces that time.h defines CLOCK_REALTIME; should it?
by Krzysztof Czainski 28 Jun '12

28 Jun '12

Hello, Suppose I want to use durations, and time_points with a user defined clock. I don't want to use any clocks provided by Boost.Chrono. My compiler provides a <time.h>, which doesn't define CLOCK_REALTIME, which chrono/config.hpp reports as an error. This prevents me from using parts of Chrono, that I believe don't depend on anything from <time.h>. I am able to work around this by simply defining CLOCK_REALTIME. But I would like to ask: Could Boost.Chrono allow using duration.hpp and time_point.hpp in my case? Regards, Kris

2 3

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 27 Jun '12

27 Jun '12

Emil Dotchevski: > On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> Is there a penalty for single threaded applications here? There's >> been discussion of the support for transferring exceptions between >> threads; are there aspects of that support that are unneeded in a >> single threaded context? >> > > There are 3 aspects of boost::throw_exception: > > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, > 2) it enables boost::error_info, and > 3) it enables boost::exception_ptr. > > 1) and 2) have nothing to do with threads; 3) implements > std::exception_ptr, which mostly benefits multi-thread programs (until > compilers catch up with std::exception_ptr support.) > > The cost imposed by libraries that use boost::throw_exception to programs > that don't use boost::exception_ptr or boost::error_info is that sizeof() > the exception object grows a little. I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads." Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
by Leo Goodstadt 27 Jun '12

27 Jun '12

> On 22 June 2012 17:51, Vladimir Prus <ghost(a)cs.msu.su> wrote: > > > On 22.06.2012 11:33, Emil Dotchevski wrote: > > > >> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost(a)cs.msu.su> wrote: > >> > >> On 20.06.2012 07:44, Rowan James wrote: > >>> > >>> On a related note; is there interest in a patch set to use > >>>> BOOST_THROW_EXCEPTION to add this (yes, programmer-oriented) information > >>>> to > >>>> the exceptions thrown by Program Options and/or other Boost libraries? > >>>> > >>>> > >>> Sorry, but I kinda miss context here (and I did read your original post). > >>> What are advantages of > >>> using BOOST_THROW_EXCEPTION and what are drawbacks? Could you summarize > >>> those for me? > >>> > >>> > >> Allow me :- > >> > >> BOOST_THROW_EXCEPTION, being a macro, is able to record the file name, the > >> function name, and the line number of the throw, which is useful when > >> diagnosing unexpected exceptions: > >> > >> catch(...) > >> { > >> std::cerr<< "Unexpected exception caught. Diagnostic information > >> follows.\n"; > >> std::cerr<< boost::current_exception_**diagnostic_information(); > >> } > >> > >> The exception object is examined dynamically for any and all useful > >> information: type, what(), throw location, any stored boost::error_info > >> objects, etc. The location of the throw (if available) is formatted in a > >> way Visual Studio understands: double-clicking shows the throw location, > >> similarly to double-clicking compile errors. > >> > >> The downside is that when templates are involved, BOOST_CURRENT_FUNCTION > >> (invoked by BOOST_THROW_EXCEPTION) can bloat the code. There is a Trac > >> ticket for this. > >> > > > > Emil, > > > > thanks for explaining. Given the above, I am not sure I am interested in > > using > > BOOST_THROW_EXCEPTION for program_options, given that exceptions are used > > there to report > > user mistakes mostly, and so function name or file line is of limited > > interest. > > > > Thanks, > > Volodya > > > Thanks Emil. > > If I can make the case in favour of BOOST_THROW_EXCEPTION, it is for the > very reason that they are reporting user mistakes. The throw location for > an exception is typically accompanied by, or at least close to, the logic > that delineates such a user mistake from acceptable input. As such, it is > a useful remedy in itself; but also gives the user specific information for > finding documentation relevant to fixing the error. Without it, we have at > best the entry point into the library that; and often a lot less if the > exceptions are caught at a higher level. > > Documentation for valid inputs or states to a function can only say so much > about all the possible errors or exceptions that may occur. To elaborate on what Volodya said, program_options is unusual (for Boost) library in its use of exceptions: Most of the time, exceptions are there to inform the programmer of an error in the programme. However, the majority of exceptions in program_options are there to indicate a problem in the construction of the command line by the *end-user* (not the programmer). In other words, the program *is* working exactly as designed. The programmer has no interest in the provenance of these exceptions *except* that they can be used to inform the end-user how they should retype the command line and try again. So, for example, ten times a day, I will type something like ls --colour * and ls will tell me ls: unrecognized option '--colour' and I will know to retype the US spelling... ls --color * If "ls" were using program options, an unrecognised option exception message will be thrown which eventually allows this informative message to be displayed before exiting. It is entirely unhelpful for the end-user to have Exception XXX on line xxx of file yyy.... To make it easier to use program options *in English*, the exception messages have been recently rewritten to be maximally informative to the end-user rather than the programmers. Thus we can take e.what() and write it out to std::cerr without further ado. Of course, for localisation, these error messages have to be reconstructed in the appropriate language. Hopefully, there is enough data in each exception to allow this. Curiously, the current design of exceptions in program_options ended up try to mirror what Emil has done in BOOST_THROW_EXCEPTION. When the exception is thrown deep in the bowels of the command line parsing, it does not have the full context which would allow an informative message to be constructed. The exception has to be propagated up, and then "decorated" before being rethrown. The alternative was to pass the full context down the function call hierarchy to each point at which exceptions can be thrown. This made the code horribly convoluted and ugly, and provoked loud cries of anguish from Volodya. Leo

5 4

Interest in static multidimensional array.
by Brian Smith 27 Jun '12

27 Jun '12

Hi All, Some time ago I uploaded the maps folder, to Boost's sandbox, containing various multidimensional and mathematical arrays. The resulting discussion appeared to indicate some interest in the multidimensional arrays and that the overall design required some reworking. Having now had the opportunity to use a compiler supporting variadic templates, I have rewritten the static multidimensional array class using them. The class, documentation, and some tests are available at, https://github.com/BrianJSmith/Array All feedback would be welcome. Regards Brian -- www.maidsafe.net

2 2

[pool] Objects of varying sizes
by Robert Dailey 27 Jun '12

27 Jun '12

Is it possible to create a pool for polymorphic types? For example: class A; class B : public A; class C : public A; I want to create a pool of type A, but the allocation can be for B or C at any time. Will this work?

7 11

[build] Problem building boost libraries from trunk with layout versioned
by Thomas Heller 27 Jun '12

27 Jun '12

Hi, I am trying to build current trunk with layout versioned. Boost build is currently failing. This looks similar to the problem reported with the 1.50 RC. Here is the error: [heller@faui32m trunk]$ ./b2 toolset=intel --layout=versioned -j2 variant=debug Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>libboost_context-il-mt-d.so error: previous virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } error: created from ./stage-unversioned error: another virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { symlink%symlink.ln-libboost_context-il-mt-d-1_50.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } } error: created from ./stage-unversioned error: added properties: none error: removed properties: none /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:135: in object(file-target)(a)3737.actualize from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build-system.jam:750: in load from module build-system /home/heller/programming/boost/trunk/tools/build/v2/kernel/modules.jam:283: in import from module modules /home/heller/programming/boost/trunk/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /home/heller/programming/boost/trunk/boost-build.jam:17: in module scope from module It seems to work when using --layout=system Anyone knows a fix to this? FWIW, toolset=gcc has the same problem Thanks, Thomas

2 2

program options (consider using BOOST_THROW_EXCEPTION)
by Roger Martin 27 Jun '12

27 Jun '12

Hi boost, At version 1.49.0 In testing command line with known unknowns such as -V a location unknown exception is thrown from inside program_options recommending to use BOOST_THROW_EXCEPTION. I've been trying to find this and apply BOOST_THROW_EXCEPTION to eliminate the verbosity for users: ---- Command line incorrect: Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> > std::exception::what: unknown option -V ---- With this fixed then it'd be closer to: -------- Command line incorrect: unknown option -V -------- Yet I haven't found where. Baffled. Any hint?

6 12

[stl_ext_adv] array based B+ tree
by Vadim Stadnik 27 Jun '12

27 Jun '12

Hi all, First of all, I would like to thank all Boosters for previous useful discussion of dynamically allocated augmented B+ trees. The development of the new array based variant of a B+ tree has been significantly influenced by these comments and suggestions. The problem of the C++ standard sequences based on linear data structures is that every of them has at least one inefficiency, such as linear cost of insert(), erase() functions of std::vector or slow bidrectional iterators of std::list. These inefficiencies create performance bottlenecks and significantly complicate the development of efficient general algorithms based on STL sequences. The new variant of an array based B+ tree offers a solution to these problems of STL sequences by reducing the running time of inefficient operations from linear to logarithmic in the worst case. The array based B+ tree implements a simple partition of an array into a list of sub-arrays connected to a B-tree. Compared to dynamically allocated B+ trees the new tree requires less space and improves locality of reference. In some aspect the array based B+ tree represents an enhanced pool allocator. Performance of the new tree has been optimized for container operations with large numbers of elements. In a number of tests the improvement factor is about 10. A significant advantage of the array based B+ tree over standard sequences is the support of splice() functions with logarithmic running time in the worst case. The high efficiency of these functions extends move semantics for non-intrusive STL sequences, since they allow user algorithms to insert and remove any range of consecutive elements. This high efficiency is not available in standard containers of C++03 and C++11. The splice() function of std::list has linear running time in the worst case. For a discussion of this problem by Boost community, please have a look at this thread: http://boost.2283326.n4.nabble.com/Containers-How-about-a-list-with-O-1-spl… For associative containers the array based B+ tree offers random access iterators and improved efficiency of many container operations against dynamically allocated B+ trees. In the general case associative containers cannot benefit from the splice() functions. Nevertheless, they can be used in algorithms for efficient split operations, since these operations do not change the order of elements in obtained containers. I think that the array based variants of B+ trees are very important, since they offer a number of performance benefits and can be used in many areas from mobile applications to processing huge data sets. The new array based B+ tree is described in this document: http://dl.dropbox.com/u/51041088/stl_ext_adv_doc/doc/array_based_bp_trees.h… The project with source code and tests: https://github.com/vstadnik/stl_ext_adv The new file with implementation of the array based B+ tree: https://github.com/vstadnik/stl_ext_adv/blob/master/container/bp_tree_array… I will appreciate any comments, suggestions and ideas concerning augmented array based B+ trees and STL variants of containers using these data structures. Regards, Vadim Stadnik

1 0

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 26 Jun '12

26 Jun '12

Pete Bartlett: < snip > > Cons for 1) and 2): > - Always paying for the cost of #including <boost/throw_exception.hpp> > - All libraries are dependent on - and therefore become vulnerable to any > future breakages (if any) in - Boost.Exception. Is there a penalty for single threaded applications here? There's been discussion of the support for transferring exceptions between threads; are there aspects of that support that are unneeded in a single threaded context? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] Interest in a "breadth first" algorithm?
by Brian Wood 26 Jun '12

26 Jun '12

Gary Powell: > > A while ago I needed to serialize and de-serialize a std::map and I > realized that the only interface was begin(), end() which of course meant > that re-creating this same map was the least efficient way possible, as all > the elements were added in sorted order. Because I wrote them out using > begin() -> end() So I wrote a breadth first template which takes a > container, a template to use as the core of a queue, a template for the > allocator, the container and a function to apply to the elements. > It doesn't quite do a true breadth first traversal because I don't look at > the inner data structure of the map, (works with sets as well) but instead > does a middle, then right, left push until it's hit all of the nodes. And > it doesn't copy the elements, it pushes the iterators, and calls the > function on that iterator when the length is 1. > It ended up speeding up my map recreation by about 20% (because I start > with a center enough node that it should never have to be rebalanced) at a > cost of about 5% to write it this way (It's more expensive to create the > queue, and traverse the map from center on out), for a roughly 15% gain in > speed. > Is there any interest this for boost? I've got working code but not any > documentation. And rather than spend a huge amount of time on that I'm > looking to see if anyone else has an interest in this. I'm interested. If you like I'll give you an investment in Ebenezer Enterprises [1]. If you post it here or send it to me, I'll probably use it in the archive available here -- http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> . [1] Past performance is not a guarantee of future results. > > "Come gather 'round people wherever you roam. And admit that the waters > around you have grown. And accept it that soon you'll be drenched to the > bone. If your time to you is worth savin'. Ahh you better start swimmin' or > you'll sink like a stone. For the times they are a-changin'" Bob Dylan Huh. Bob Dylan is from the Hibbing/Duluth part of Minnesota. In the days after you posted, that area received a summer's worth of rain in 36 hours. An 8 year old boy nearly died in the flooding when he was swept down a culvert. Thankfully he popped up a mile down the system and has been giving interviews since. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 1

Re: [boost] Boost and exceptions
by Stewart, Robert 26 Jun '12

26 Jun '12

Robert Ramey wrote: > Dave Abrahams wrote: > >> I mean, if there is a problem with boost::throw_exception or > >> any other part of Boost Exception, I'd like to know about > >> it. > > > > It seems clear to me from his posts that Robert wants to > > talk about the process and has forgotten any specifics about > > actual problems. > > > The problem was the gratuitious inclusion of a new dependency. Emil has described repeatedly why the change was not gratuitous. That you fail to recognize the value in the change does not make it gratuitous. I looked at a recent boost/throw_exception.hpp. It includes boost/exception/detail/attribute_noreturn.hpp. That creates a dependency inversion that is unfortunate. That is, a top-level header file depends upon a header file of a library's files. That header is very short and has nothing Boost.Exception specific, so the code could be moved into boost/throw_exception.hpp or boost/detail/attribute_noreturn.hpp, for example. The header also conditionally includes the non-trivial boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions: boost::exception_detail::refcount_ptr boost:: error_info boost::exception boost::exception_detail::error_info_base boost::exception_detail::type_info_ boost::exception_detail::error_info_container boost::exception_detail::get_info boost::exception_detail::get_diagnostic_information() boost::exception_detail::copy_boost_exception() boost::exception_detail::set_info() boost::exception_detail::error_info_injector boost::enable_error_info() boost::exception_detail::clone_base boost::exception_detail::clone_impl boost::enable_current_exception() If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown. This is a non-trivial set of changes to make to the top-level header. I didn't follow the discussion at the time, but I'll presume there was a lot of discussion about the type and extent of these changes and that it was considered a good idea. In hindsight, I agree with Robert's assertion that there should have been a replacement function, boost::exception::throw_exception() or similar, to introduce the new functionality. Whether the existing function needed to be deprecated is a separate issue. The result is that libraries could knowingly choose the new version, and a dependency on Boost.Exception, or, if warranted, stick with the old. As things now stand, if there is good reason to avoid the new version, it can only be done by defining BOOST_EXCEPTION_DISABLE, which affects an entire build. > The extent/nature of any problem it created or didn't create is > not relevant here. Just the injection of a new body of code > which replaced two lines and added no functionality used/needed > by the serialization library makes the any library which used > boost::throw_exception "bigger" for no reason. The issue you're raising, as I understand it, is dependency inversion: the top-level header brings a dependency on Boost.Exception. > It makes the library more "fragil". It means I have I a new > place to look if something needs looking into. etc.etc. As Nevin pointed out, your code will always be subject to the changes in those libraries on which it depends. The more dependencies you introduce, the more fragile your code becomes, but there's a great deal of benefit to reuse, too. The only issue in this case is that one can reasonably expect a top-level header to avoid dependencies on libraries. > So we'll just move on as Vicente suggested. That will be > satisfactory from my standpoint. That is the only way forward, if there is good reason to avoid the now longstanding changes to boost::throw_exception(). However, you should work with Emil to be sure you correctly and fully understand the issues before deciding that you cannot accept boost::throw_exception() as is. (I don't pretend to know what your concerns are. I just don't want to see a new throw_exception() variant if there isn't a compelling reason, and I don't consider your fragility argument compelling in this case.) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

20 91

[contract] relaxing preconditions in subcontracting
by Andrzej Krzemienski 26 Jun '12

26 Jun '12

Hi Lorenzo, I am trying to understand how the feature of relaxing preconditions in overridden functions work or should work. Given the situation, where I call an overridden function via base class reference: *struct Base { virtual void fun(bool b) = 0 precondition{ b == true }; }; struct Deriv : Base { void fun(bool b) override precondition{ true }; }; void test( Base & b ) { b.fun(false); **// broken contract or not?** }* Should this be treated as a broken contract or not? My reading of the documentation says that contract is not broken (because the "logic-or<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…>" logic applies), but I feel that whoever implemented function *test *made a mistake: he cannot assume what type will be implementing "interface" *Base*, so he cannot rely on the precondition being relaxed (even if he gets away with it this time). Regards, &rzej

2 7

boost with cxxflags=-Zc:wchar_t-
by Renato Tegon Forti 25 Jun '12

25 Jun '12

Hi All, I'm mixing QT and boost and noticed problems with wchar_t! I need to compile boost: cxxflags =-Zc: wchar_t- Would like to know what problems I can find! anyone ever had to use 'wchar_t-"? Libs that I am using: boost_mpi boost_serialization boost_system boost_filesystem boost_thread boost_iostreams Thanks

3 2

library dependencies and boost modularization [ was Boost and Exceptions]
by Robert Ramey 25 Jun '12

25 Jun '12

Boost has now close to 100 libraries. In addition there are hundreds of smaller but necessary facilities which aren't technically libraries but they add a lot to the "surface area" that one's brain has to be familiar with to take best advantage of boost facilities. There is also a lot of interconnectedness which makes it an even larger task. This wasn't a big deal when boost was 15 libraries - but now it's different. I would like to propose a classification of boost libraries and guidelines for future libraries. a) Layering of libraries =============== 0) C++ standard library 1) "boost core" libaries 2) "boost utility" libraries 3) "boost user" libraries b) Guidelines ========= 1) a library in a given layer shall include code from libraries in a higher layer 2) boost core libraries are in namespace "boost" 3) boost user libraries are in the name space boost::<name of user library> 4) there is a special user library named "utility" for small libraries which are widely used. 5) boost header directory structures should match namespace structure. example, a library named boost.range should have all it's code in namespace boost::range and in the directory boost/range. 6) exception to 5) above, a user library might have a "convenience header" in directory "boost" which includes all the header directories of that user library. c) Rationale ======== 1) it diminishes the possibility of namespace conflicts as boost/C++ grows 2) it diminishes the possibility of importing a lot more code and depencies than one expected. 3) a library can control its depencies. Often a library will rely only on "boost core". This means that users of the library can know that code is dependent only on that library. 4) It more easily supports the concept of "boost modularization" where by deployment of a subset of boost libraries is can be supported. It's often mentioned how other languages like java, C#, perl have HUGE number of libraries in comparison to C++. I believe these languages have reached their peak and are in fact in decline somwhat. It is possible that this huge number of libraries make them less attractive rather than more? Perhaps a little more formal structure applied to our work might be agood thing. Robert Ramey

1 0

[serialization] Reading newer archives - was throwing unsupported_class_version, now crashes
by Nikolay Mladenov 25 Jun '12

25 Jun '12

Hi Robert, I remember that in the past the serialization library was throwing unsupported_class_version exception when reading of archives with future class versions. This no longer seems to be the case. We had older version of software crash when reading newer archive. The only place that I found to mention unsupported_class_version is commented out and I do not understand the attached note: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // note: we now comment this out. Before we permited archive // version # to be very large. Now we don't. To permit // readers of these old archives, we have to suppress this // code. Perhaps in the future we might re-enable it but // permit its suppression with a runtime switch. #if 0 // trap case where the program cannot handle the current version if(file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); #endif // make sure call is routed through the higest interface that might // be specialized by the user. boost::serialization::serialize_adl( boost::serialization::smart_cast_reference<Archive &>(ar), * static_cast<T *>(x), file_version ); } To allow class to read serialized objects of newer version by default seems very dangerous. I generally requires extra work from the class author and without it will most likely crash. So isn't it better to have an additional trait that a class author needs to define, if a class should be allowed read future versions? something like namespace boost{ namespace serialization { template<class T> struct allow_future_versions : mpl::false_ {}; }} #define BOOST_SERIALIZATION_ALLOW_FUTURE_VERSIONS(T) \ namespace boost{ namespace serialization \ { \ template<> struct allow_future_versions<T> : mpl::true_ {}; \ }} and change the code above to: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // trap case where the program cannot handle the current version if( ! boost::serialization::allow_future_versions<T>::value && file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); ...... Thanks in advance, Nikolay Mladenov Sitius Automation Inc.

3 10

[move] GCC bug and aliasing questions
by Tr3wory 25 Jun '12

25 Jun '12

Hi, Yesterday I started using Boost.Move in my project. On gcc I had the same problem like the guys here: http://lists.boost.org/Archives/boost/2011/07/184263.php Namely, I can't define the move constructor nor the assignment operators outside my class... After some time I managed to create a minimal example (19 lines) and sent a bug report to the gcc guys: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 So far, so good. In the minimizing process I found something interesting: the problem vanishes if I remove the __may_alias__ attribute from the rv<> class. This got me thinking. Do we need this attribute at all? The problematic expression is this: (It's in macros normally placed inside a class, TYPE is the name of this class.) operator ::boost::rv<TYPE>&() { return *static_cast< ::boost::rv<TYPE>*> (this); } But rv<TYPE> is derived from TYPE so to me it looks like the two type is compatible, therefore the code didn't violate the strict aliasing rules, so the attribute is not necessary. (BTW can we violate the strict aliasing rules trough static_cast if we don't do any chained conversion trough void*?) On the other hand, if it's really breaks the rules then we solved the problem for gcc, but we still have undefined behavior on every other compiler. Can we fix this somehow? Cheers, tr3w

3 5

An alternative approach to TypeErasure
by Pyry Jahkola 25 Jun '12

25 Jun '12

Hi all, I was quite impressed by Sean Parent's Friday talk in C++Now! 2012 (see slides in [1], code in [2]) and was left wondering whether the generation of his polymorphic object wrapper could be made simple somehow in C++11. [1]: https://github.com/boostcon/cppnow_presentations_2012/raw/master/fri/value_… [2]: https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value… What I ended up with is tricking ADL into allowing the overloading of arbitrary (specifically crafted) function objects that I call _callables_, and then letting the user define interfaces by specifying sets of ("member") function signatures with a callable. You can find the code, and my rambling introductory README file, in GitHub: https://github.com/pyrtsa/poly Comments are welcome! * * * Here's a somewhat shorter intro: 1) Create a callable F by simply deriving it from poly::callable<F>: struct draw_ : poly::callable<draw_> {}; constexpr draw_ draw = {}; 2) Or use the convenience macro POLY_CALLABLE(name) to do the same: POLY_CALLABLE(to_string); // type `to_string_` and object `to_string` 3) Overload your callables by overloading the function named `call`, with the callable as first argument: template <typename T> void call(draw_, T const & x, std::ostream & out, std::size_t position) { out << std::string(position, ' ') << x << std::endl; } std::string call(to_string_, int i) { return std::to_string(i); } template <typename T> std::string call(to_string_, std::vector<T> const & xs) { std::ostringstream s; s << '['; auto i = begin(xs), e = end(xs); if (i != e) s << *i++; while (i != e) s << ", " << *i++; s << ']'; return s.str(); } Now you can call ::draw(x, o, p) and ::to_string(x) for several different types of x: ::draw(123, std::cout, 2); // prints " 123" to stdout ::to_string(std::vector<int>(1, 2, 3)); // "[1, 2, 3]" But you can likewise extend ::draw and ::to_string further by overloading them for your own types too. 4) Define an interface by specifying the set of function signatures as template arguments to poly::interface: using drawable = poly::interface< void(draw_, poly::self const &, std::ostream &, std::size_t, std::string(to_string_, poly::self const &)>; Now, the following calls got automatically defined, and forwarded to whatever type you successfully construct a `drawable` from: void call(draw_, drawable const &, std::ostream &, std::size_t); std::string call(to_string_, drawable const &); * * * I am aware that Steven Watanabe has put some astonishing work on his proposed Boost.TypeErasure. I'm open for discussion whether and how his or mine is a better approach, or if we could combine these into an eventual Boost.Interface library or such! * * * PS. Like I mention in my GitHub page, this kind of type erasure is common in functional languages like Haskell or Clojure. The problem they are solving there is known as the Expression Problem. IMO it makes very much sense to have the corresponding construct in C++ too, as we're moving towards a more and more functional style with parallelism and such. Best Regards, -- Pyry Jahkola pyry.jahkola(a)iki.fi https://twitter.com/pyrtsa

7 16

Multiprecision Review
by Phil Endecott 25 Jun '12

25 Jun '12

Dear All, Here is my review of the proposed Multiprecision review. First a rant: why have so few people contributed to the discussion or written reviews? I have waited until now before writing this in the hope that others would say something useful, but there has been very little to read. Boost will suffer as a result of this. It has been depressing to see that at the same time the mailing list has been full of other discussions, so the problem is not that people don't have the time to contribute. In particular, the long thread about Boost.Exception makes me want to shout "Why Didn't You Say All This When It Was Reviewed?". My view of the proposed library can be summarised as follows: it doesn't do what I want, but maybe it does enough things that other users would like to justify its acceptance anyway. Except probably it doesn't, because if it did those other users would have said so, which they haven't. In particular, I'd like to be able to implement integers of perhaps 128 or 256 bits that behave like the built-in integers. I can quickly throw together something myself that works OK but: - It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown. - Writing all the operator overloading etc. is tedious. - It's also error prone, as a mistake in e.g. carry propagation might be detected once in very 2^32 operations. It would have been great if this library could have helped with this. Instead, it has produced something worse than my "quick throw-together". It's worse because it has tried to unify this smallish fixed-size type with very large variable-size types, and the compromises necessary to achieve this have sabotaged the performance. It's also worse because it had a subtle bug - which has since been corrected, but I would still not be confident of getting correct answers without verifying against another implementation. Ideally, there would still be some parts of the library that could be useful to me. If the library had been decomposed into data structures vs. algorithms then perhaps I could have applied the algorithms to my simpler data structures. Unfortunately the library has not been organised in this way, and even if it had done the use of sign-magnitude representation might have scuppered any re-use. As far as I can see, the only part of the library that I could re-use would be the expression template front-end, which doesn't seem to improve performance for types of this size anyway. Here are my answers to the standard review questions: What is your evaluation of the design? Not great for my purposes; see above. What is your evaluation of the implementation? I spent half a day chasing down a bug. My observations are that (a) there are subtle bugs, and (b) the code lacks comments or other clues for people like me to quickly pick up what it's all doing. What is your evaluation of the documentation? Satisfactory. What is your evaluation of the potential usefulness of the library? Not useful for me; see above. Did you try to use the library? With what compiler? Did you have any problems? I spent perhaps a day working on a small but real benchmark which was discussed on the mailing list. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About a day-and-a-half in all. I've not looked beyond the areas that I've discussed and I'm aware that there is a lot more to the library i.e. non-integer types. Are you knowledgeable about the problem domain? Not especially. Do you think the library should be accepted as a Boost library? No, because (a) I'm not convinced from this discussion that lots of people are waiting for this functionality (see above). (b) Based on previous experience, I'm sceptical about the possibility of the performance of Boost libraries being improved after acceptance. Despite that, I thank John and Chris for their work which is a considerable leap forward from the last "big number" submission, "xint". Regards, Phil.

5 5

Contribute
by Merve Temizer 25 Jun '12

25 Jun '12

Hello, I am not sure if this is right place to write but, how can i contribute as a newbie programmer? My main intention is learning C++ deeper by contributing to some open source organizations. Sorry for if it is wrong place. Thanks in advance.

2 1

[fusion] for_each on gcc 4.7
by Daniel Larimer 24 Jun '12

24 Jun '12

I recently attempted to update to gcc 4.7 and code that compiled with 4.5.3 broke. It appears that boost::fusion expects boost::fusion::random_access_traversal_tag to implicitly cast to mpl::bool_<false>. Switching the 3rd argument from mpl::bool_<false> to an extra template arg (that was ignored), seems to fix the compilation errors. Compiled with std=c++11 /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: error: no matching function for call to 'for_each(boost::fusion::vector2<double, double>&, const mace::rpc::detail::unpack_sequence<mace::rpc::function_filter<mace::rpc::connection<mace::rpc::json::io> > >&, boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type)' /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: candidate is: In file included from /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:11:0, from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template<class Sequence, class F> void boost::fusion::detail::for_each(Sequence&, const F&, mpl_::false_) /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template argument deduction/substitution failed: In file included from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12:0, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: cannot convert 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type()' (type 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type {aka boost::fusion::random_access_traversal_tag}') to type 'mpl_::false_ {aka mpl_::bool_<false>}'

5 8

Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
by Keith Burton 24 Jun '12

24 Jun '12

Instant reactions on reading though the documentation : 1) Introduction : I would prefer to see e.g. mp::int128_t rather than mp::mp_int128_t, given the stated purpose of the library. 2) cpp_dec_float : Narrowing conversions are truncating. This is a no-no for the usage I have in mind at the moment. 3) Constructing and interconverting : >> // There is a need to be careful with integer types though: >> cpp_int i = 2; >> // Ooops, this really just multiplies by 3: >> i *= 3.14; One of the priorities for my numeric class implementations has always been to protect naive users from equivalent mistakes. What is your evaluation of the design? It is so far beyond anything I have attempted that I cannot usefully comment. The limitations on conversions and mixed precision operations are disappointing but entirely understandable. The ccp_dec_float narrowing conversions being truncating reinforces the my view that the limitations are probably the correct design. What is your evaluation of the implementation? No useful comments. What is your evaluation of the documentation? Good enough to give me confidence to start using the library. I would never expect more than that. What is your evaluation of the potential usefulness of the library? A vital addition to C++ especially for relatively small tasks in commercial software where the Boost backends can be used because performance is not an overriding concern. Did you try to use the library? With what compiler? Did you have any problems? I have started to use the library to embed test code for my special purpose decimal fixed point classes into an application under development. The only issue, using VS2008 /W4 and Boost 1.48, was the need to disable warning 4996. Unfortunately this has been pre-empted by other work. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? More than a quick reading Are you knowledgeable about the problem domain? I have written several numeric classes but all with a narrow scope and protection of naïve users and accuracy as the priority. These were primarily decimal fixed point. Do you think the library should be accepted as a Boost library? Yes

3 2

[multiprecision] Last chance for a review.
by John Maddock 24 Jun '12

24 Jun '12

Just to remind everyone that the multiprecision library review is about to come to an end, so it's time to speak up or shut up ;-) Actually we're a little short on reviews generally, so I'd encourage anyone who hasn't taken a look yet to do so, code is the sandbox under /big_number/, docs are viewable online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… Many thanks, John.

3 2

Trimming Dependencies (was Boost and exceptions)
by Daniel James 24 Jun '12

24 Jun '12

On 24 June 2012 01:55, Dave Abrahams <dave(a)boostpro.com> wrote: > > on Sat Jun 23 2012, Daniel James <dnljms-AT-gmail.com> wrote: > >> >> That's pretty crazy. Do you know if separating test dependencies would >> make much of a difference? > > They're already separated, along with documentation dependencies. You > *really* don't want to see the graph that includes the test dependencies > ;-) OK, I assumed from the dependencies on Test that they were included, but some headers do depend on Test.

2 1

Boost and exceptions
by Dirk Ulrich 24 Jun '12

24 Jun '12

Dear all, when looking at Boost as a whole its obvious that it uses C++ exceptions to report exceptional conditions because its the C++ way of doing it and it has to interact with the C++ standard library. On the other hand it seems also obvious that some libraries (Boost.Units, Boost.MPL, etc.) do probably not use C++ exceptions at all since they are pure compile time libraries or provide services which do not have exceptional cases. I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math. Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)? What would it take to use these libraries as a stand-alone "minimal" Boost library? Thanks

18 71

Boost's on the map
by John Maddock 23 Jun '12

23 Jun '12

Literally in this case: http://softwaremaniacs.org/media/alenacpp/cppmap-2012.png John.

4 3

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

John Maddock: > This actually looks compelling enough to me, that we should probably mandate > use of BOOST_THROW_EXCEPTION. Are you going to take away their library card if an author doesn't want to do this? ;) Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

Fabio Fracassi: > That is how modular development works, you let go of some control in > exchange for synergy effects and free added functionality. > Yes, it creates communication overhead but the win (for the users) is huge. I skipped Boost 1.49 and have been updating these results using Boost 1.50 -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I haven't noticed any performance improvements in the serialization library that's in Boost from 1.48 to the latest version. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Linked map
by Kannan R 23 Jun '12

23 Jun '12

Recently i wrote a json parser. I used stl map to store the json objects. Everything was fine except the order of the objects. Is it worth to build something in boost to have the map which provides an iterator to get the elements in same order? Please advise.

3 2

exception handling in multithreaded applications (was: RE: Boost and exceptions)
by Thomas Klimpel 22 Jun '12

22 Jun '12

Fabio Fracassi wrote: > Yes it is, because in reality boost exception solves problems for the > users of any library that uses it. When using boost exception I can > safely let exceptions escape threads and have them rethrown in the > starting thread, for instance. I would be interested to learn how you do this. With open-mp (and mpi), my current way to add exception handling code really adds much noise: bool cancel = false; #pragma omp parallel shared(cancel) { try { ... the real code } catch (std::exception& r) { cancel = true; store_exception(r); } } if (cancel) { rethrow_exception(); } Regards, Thomas

2 1

emulating concepts in C++11
by lcaminiti 22 Jun '12

22 Jun '12

Hello all, I was not able to find Boost.Generic source code (I asked Matt Calabrese but no reply): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 Are you aware of any trick (e.g., the tricks used by Boost.Generic) to emulate concepts in C++11? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-emulating-concepts-in-C-11-tp46317… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Still a monolithic library? Or a bunch of independent ones?
by hello world 21 Jun '12

21 Jun '12

Hello, It's been a few years since I didn't come around boost.org, and I was just wondering... Is boost still a monolithic library? or Is it a collection of separate libraries now? Or to state it another way: Is it ``easy'' to take only one library's files from the boost distribution and use it. Or do I have to carry everything around even If I'm using just one library? I understand that this must be library specific, but I'm just asking this to know what your general feel overall. Thanks.

3 2

Interest in a "breadth first" algorithm?
by Gary Powell 21 Jun '12

21 Jun '12

A while ago I needed to serialize and de-serialize a std::map and I realized that the only interface was begin(), end() which of course meant that re-creating this same map was the least efficient way possible, as all the elements were added in sorted order. Because I wrote them out using begin() -> end() So I wrote a breadth first template which takes a container, a template to use as the core of a queue, a template for the allocator, the container and a function to apply to the elements. It doesn't quite do a true breadth first traversal because I don't look at the inner data structure of the map, (works with sets as well) but instead does a middle, then right, left push until it's hit all of the nodes. And it doesn't copy the elements, it pushes the iterators, and calls the function on that iterator when the length is 1. It ended up speeding up my map recreation by about 20% (because I start with a center enough node that it should never have to be rebalanced) at a cost of about 5% to write it this way (It's more expensive to create the queue, and traverse the map from center on out), for a roughly 15% gain in speed. Is there any interest this for boost? I've got working code but not any documentation. And rather than spend a huge amount of time on that I'm looking to see if anyone else has an interest in this. -Gary- -- ------------------ powellg(a)gmail.com "Come gather 'round people wherever you roam. And admit that the waters around you have grown. And accept it that soon you'll be drenched to the bone. If your time to you is worth savin'. Ahh you better start swimmin' or you'll sink like a stone. For the times they are a-changin'" Bob Dylan

4 4

Integrating CUDA nvcc into bjam
by jombi01821 21 Jun '12

21 Jun '12

I would like to know how to take an existing project that build with bjam and have it understand how to handle .cu CUDA files -- View this message in context: http://boost.2283326.n4.nabble.com/Integrating-CUDA-nvcc-into-bjam-tp463163… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50] Is it too late for fixes?
by John Maddock 21 Jun '12

21 Jun '12

I have a trivial fix for 1.50 if it's not too late (missing include guards on a header), see https://svn.boost.org/trac/boost/ticket/7001 Is it too late now, suspect it is? Thanks, John.

1 0

[exception] gcc 4.7 non-virtual destructor warning
by Daniel Larimer 21 Jun '12

21 Jun '12

/usr/local/include/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] Is there a reason why the destructor isn't virtual? This only shows up when I compile with -Wall, which I like to do because it catches many important errors. Unfortunately, if I have to filter out boost warnings it makes it less effective.. particularly when the warning is actually about 30 lines long in my console. Dan

3 3

[release] merge request for test fix
by Jürgen Hunold 20 Jun '12

20 Jun '12

Hi, I would like to merge r78972 to the release branch. It fixes some test failures introduced by 78802 which renamed UTC_TIME to UTC_TIME_. Trunk tests have cycled for 2 days and the interprocress results start to turn green. 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 ! Germany

2 2

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

[svn] post commit hooks broken
by Jürgen Hunold 19 Jun '12

19 Jun '12

Hi, the subversion post commit hooks seem to be broken. The last commit mail I got is Author: garcia Date: 2012-06-07 16:20:43 EDT (Thu, 07 Jun 2012) New Revision: 78856 and there habe been numerous commits since. I have also checked in a followoup to r78802 yesterday, which should have triggered an automated trac entry for #6940. But nothing happens. Can someone with enough karma please take a look at this? As a sidenote: The inofficial git mirror seems stalled, too. 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 ! Germany

2 2

[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

Multiprecision vs. xint
by Phil Endecott 18 Jun '12

18 Jun '12

Dear All, I'd like to encourage people who are looking at the proposed Multiprecision library to remind themselves of the xint review last year. See e.g. http://thread.gmane.org/gmane.comp.lib.boost.devel/218624 (result) http://thread.gmane.org/gmane.comp.lib.boost.devel/215968 (my review) etc. etc. To what extent do we believe that this new library addresses the weaknesses of the last proposal? It would be great if Vladimir Prus, review manager for xint, could write a review of Multiprecision. Here's my take on it: Multiprecision addresses many of the problems of xint, and also extends the scope into areas that xint did not address at all. However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me. Furthermore, it doesn't help me to build the int128_t that I want. Although Multiprecision is divided into "front" and "back"-ends, this division is not in the right place to let me substitute my own backend that just provides the 128 bits of storage. In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here. Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms. Regards, Phil.

5 9