November 2011 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

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

5 8

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

06 May '15

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

9 10

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

29 Apr '14

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

9 16

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

21 Oct '13

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

4 6

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

29 Jul '13

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

6 11

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

[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

[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

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

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

07 Jun '12

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

4 7

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

04 May '12

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

5 45

[range] adaptors and member functions pointers
by Yanchenko Maxim 17 Mar '12

17 Mar '12

Hi, While transforming and filtering sequences, it's pretty common to call the elements' member functions, so I think it's worth adding some syntactic sugar for range adaptors in order to achieve cleaner syntax. E.g. if we have a class struct Foo { std::string description() const; }; and we want to get all non-empty descriptions, we could just write this clean code: foo_list | transformed(&Foo::description) | filtered(&std::string::size) To enable this syntax, the attached patch should be applied to boost/range/adaptor/argument_fwd.hpp (diff against 1.47.0). Is there any interest to add this to Boost.Range? Thanks, Maxim

7 9

Determining interest: Pure imaginary number library
by Matthieu Schaller 29 Feb '12

29 Feb '12

Dear all, I have recently been playing a lot on numerical analysis problems containing complex numbers and functions. I have been using the SL std::complex<> library and could observe that some of the algorithms weren't optimized in cases where complex numbers have to be multiplied by pure imaginary numbers (i.e. x*sqrt(-1)). I have implemented a class to represent these numbers and overloaded all relevant operators in a more optimized fashion thanks to the knowledge that the real part of these complex numbers is 0. I could observe an important speed-up in some calculations. As an example, this piece of code (1D Schroedinger equation using finite differences): for(size_t i(0); i<nbPoints; ++i) { Psi_new[i] = Psi_old[i] + ii * hbar * deltaT / (12.*m*deltaX*deltaX) * (-Psi_cur[i-2] + 16.*Psi_cur[i-1] - 30.*Psi_cur[i] + 16.*Psi_cur[i+1] - Psi_cur[i+2]) - 2. * ii * V(x[i]) / hbar * deltaT * Psi_cur[i]; } is more than 2 times faster (g++ 4.6.1 core i7 2820QM) when the imaginary unit (constant) variable ii is defined to be Imaginary<double> ii(1.); than when it is defined as std::complex<double> ii(0.,1.); Some other expressions also benefit from this improvement and can run faster. Expressions including square roots or exponentials of pure imaginary numbers are improved a lot. The range of application of such a class is quite narrow but it may be helpful to speed-up some simple numerical problems. The source code as well as a working example is available here: http://code.google.com/p/cpp-imaginary-numbers/ Thanks, Matthieu

8 21

vsix - template_profiler extension
by Brandon Kohn 27 Feb '12

27 Feb '12

Hello, I've put together a Visual Studio 2010 extension package which wraps the functionality of Steven Watanabe and Domagoj Saric's template_profiler to create a template profile tool. It also adds a command to profile the build time of a project or a single C++ file. Both functions are accessed from the context menu in the solution explorer tree-view. It's still fairly young and could use some kicking about. Are there any VC10 users here that would be interested in giving it a try? Cheers, Brandon

5 16

[move] new rvalue reference emulation
by Jeffrey Lee Hellrung, Jr. 19 Feb '12

19 Feb '12

I've recently discovered (well, probably rediscovered) an alternate rvalue reference emulation, one which allows rvalues ***of any arbitrary (move-emulation-enabled) type*** to be captured in C++03 and identified as rvalues, rather than references-to-const (there is a drawback, though, which I'll get to below; as usual, there's no "free lunch"). This is in contrast to the current move emulation framework Ion has created in Boost.Move which, at best, allows you to capture rvalues of specific types. That is, if you can enumerate the types for which you want to enable rvalue capture, then you're good. For example, if you want to create a generic unary function some_fn, and you know you want to at least capture rvalues of type X, you could do: template< class T > void some_fn(T&); // captures (lvalue) references-to-non-const, explicitly created emulated rvalue references, *and* (lvalue) references-to-(X const) template< class T > typename boost::disable_if< boost::is_same<T,X> >::type void some_fn(T const &); // captures (lvalue) references-to-const *except* (lvalue) references-to-(X const) void some_fn(rv<X>&); // captures rvalues of X as emulated rvalue references However, if Y is any type other than X, the above overloads will capture an rvalue of Y as an (lvalue) reference-to-(Y const). This is one of the shortcomings of using the emulated rvalue reference rv<T>& as a function argument: it can't bind to rvalues in a context where the template parameter T is deduced. Now I don't know if the following proposition is a good idea or not, but I think it is worth considering. Again, we would like the emulated rvalue reference rv<T>& to bind to rvalues, but the problem is the deduction of the T template parameter. Instead of using rv<T>& to capture arbitrary rvalues, I'll use a kind of type-erased emulated rvalue reference, generic_rv<...> (for lack of a better name at the moment), which will just store a void pointer to the original, pre-type-erased object. Of course, we need some way to recover the object back from the void pointer, and that's what the "..." template parameters are for. This is where the (unfortunate) runtime overhead comes in, as some dispatching mechanism (e.g., function pointers) needs to be used to effect the recovery of the original, pre-type-erased object. The important difference between rv<T> and generic_rv<...> is that there's no T in the template parameter list "..." of generic_rv; more to the point, its template parameters are not deduced within the context of binding function arguments of some_fn, hence the compiler will be allowed to look for conversions from arbitrary rvalues to generic_rv<...>. Hopefully that gives enough of an introduction to the idea. Further details are probably best left to a code snippet. Comments? Specifically, should this be considered as an addition to Boost.Move's current emulation framework? Has anyone seen this technique before? ---------------- #include <iostream> #include <boost/type_traits/is_convertible.hpp> #include <boost/utility/enable_if.hpp> // rv<T>& emulates T&& template< class T > class rv : public T { rv(); rv(rv const &); rv& operator=(rv const &); }; template< class T > struct has_move_emulation : boost::is_convertible< T, rv<T>& > { }; // *** NEW EMULATED RVALUE REFERENCE *** // generic_rv< F, Result > also emulates an rvalue reference, but in a kind of // type-erased way. The actual object referred to is referenced by a void // pointer. To be able to cast the void pointer back to a pointer-to-object, we // need to package the void pointer together with some kind of dispatching // mechanism. We use a function pointer to an instantiation of cast_forward<T>. template< class F, class Result = void > struct generic_rv { typedef Result (*p_cast_forward_type)(F, void*); generic_rv(p_cast_forward_type p_cast_forward, void* p) : mp_cast_forward(p_cast_forward), m_p(p) { } Result cast_forward(F f) const { return (*mp_cast_forward)(f, m_p); } template< class T > static Result cast_forward(F f, void* const p) { return f(static_cast< rv<T>& >(*static_cast< T* >(p))); } private: p_cast_forward_type mp_cast_forward; void* m_p; }; // X is just a typical move-emulation-enabled class. struct X { X() { std::cout << "X::X()" << std::endl; } X(X const &) { std::cout << "X::X(X const &)" << std::endl; } X(rv<X>&) { std::cout << "X::X(rv<X>&)" << std::endl; } X& operator=(X) { std::cout << "X::operator=(X)" << std::endl; return *this; } X& operator=(rv<X>&) { std::cout << "X::operator=(rv<X>&)" << std::endl; return *this; } operator rv<X>&() { std::cout << "X::operator rv<X>&()" << std::endl; return *static_cast< rv<X>* >(this); } operator rv<X> const &() const { std::cout << "X::operator rv<X> const &() const" << std::endl; return *static_cast< rv<X> const * >(this); } // *** NEW CONVERSION OPERATOR *** // X provides an implicit conversion to generic_rv. template< class F, class Result > operator generic_rv< F, Result >() { std::cout << "X::operator generic_rv< F, Result >()" << std::endl; return generic_rv< F, Result >( &generic_rv< F, Result >::template cast_forward<X>, static_cast< void* >(this) ); } }; struct some_fn { template< class T > void operator()(T&) const { std::cout << "some_fn::operator()(T&) const" << std::endl; } template< class T > typename boost::disable_if< has_move_emulation<T> >::type operator()(T const &) const { std::cout << "some_fn::operator()(T const &) const" << std::endl; } // Notice that this overload requires template parameter deduction, hence // the compiler cannot apply an implicit conversion to rv<T>& from rvalues // of move-emulation-enabled types. In other words, this overload can only // bind to *explicitly* created emulated rvalue references, not to "real" // rvalues :( template< class T > void operator()(rv<T>&) const { std::cout << "some_fn::operator()(rv<T>&) const" << std::endl; } // *** NEW FUNCTION OVERLOAD TO CAPTURE RVALUES *** // Since this overload requires no template parameter deduction, the // compiler *can* apply an implicit conversion to generic_rv<...> from // rvalues of move-emulation-enabled types. Yes, there will be some runtime // overhead from the function pointer dispatching, but that will often be // preferable to copying x! void operator()(generic_rv< some_fn > const x) const { std::cout << "some_fn::operator()(generic_rv< some_fn >) const" << std::endl; return x.cast_forward(*this); } }; template< class T > T make() { return T(); } int main(int argc, char* argv[]) { int a = 0; int const b = 0; some_fn()(a); // some_fn::operator()(T&) const some_fn()(b); // some_fn::operator()(T const &) const some_fn()(make< int >()); // some_fn::operator()(T const &) const X x; // X::X() X const y; // X::X() some_fn()(x); // some_fn::operator()(T&) const some_fn()(y); // some_fn::operator()(T&) const some_fn()(make<X>()); // X::X() // X::operator generic_rv< F, Result >() // some_fn::operator()(generic_rv< some_fn >) const // some_fn::operator()(rv<T>&) const return 0; } ---------------- - Jeff

10 33

Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
by Matthew Chambers 26 Jan '12

26 Jan '12

On Oct 13, 2011 Michel Morin wrote: > lexical_cast made optimizations for some types (such as `std::string`) > to achieve better performance. But, from my experience, > it seems that lexical_cast does not make any optimization for > `boost::iterator_range<std::string::iterator>`. > > Is there any plan to add optimization for such iterator ranges? > Currently, > - `lexical_cast<int>(std::string(iter_rng.begin(), iter_rng.end()))` > is faster > than `lexical_cast<int>(iter_rng)`. > - Assuming it is safe to use `std::atoi`, > `std::atoi(&iter_rng.front())` is faster > than both of the above two methods. > (`iter_rng` is an instance of `boost::iterator_range<std::string::iterator>`.) > > Regards, > Michel This post was on the boost users list but never got a reply. I figure it might be a better fit on the developer list. I too would like to see optimized conversions work on string ranges; what's the point in doing a fast conversion if you have to do a string copy first? :) -Matt

8 16

[quickbook] changing paths
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, How can I change the paths were Boost.QuickBook looks for the following files? 1) CSS and icon images by default from BOOST_ROOT/doc. 2) Navigation bar by default from BOOST_ROOT/tools/boostbook/xls. Essentially, I'd like to put the CSS, icon images, and navbar into a different path. Also, I'd like to change the navbar to one of my own. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-changing-paths-tp3925967… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 4

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

Is there any interest in command line interpreter class templates?
by alexey.tsoy 29 Dec '11

29 Dec '11

Hello everybody, The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation. The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent. The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it. Regards Alexey -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[concept_check] Some issues
by Robert Kawulak 23 Dec '11

23 Dec '11

Hi, I've spotted some problems when playing with BCCL: - The implementation of assignable_archetype defines private default and copy constructors, so for example assignable_archetype<copy_constructible_archetype<>> will not actually be copy constructible. The same for convertible_to_archetype and convertible_from_archetype, but additionally with copy assignment. Is this by purpose? - copy_constructible_archetype defines public default constructor - again, am I overlooking something or it should not be there? - Function and predicate archetypes also seem to provide too wide interface (they are copy constructible and assignable). Additionally, they don't allow for archetypes chaining since they lack the Base parameter (with the only exception of binary_predicate_archetype - why the inconsistency?) - Apart from the provided function object concepts and archetypes it seems it would be useful to have a general Callable concept and the corresponding callable_archetype, parameterised with the types of arguments and return value. Wouldn't it be valuable to add them? - There's boost/concept_check directory in the trunk - are the files in it actually used anywhere? I've found no reference to them in Boost headers, documentation doesn't mention them too. Best regards, Robert

3 10

boost and google search
by Edward Rankin 23 Dec '11

23 Dec '11

Hi, I am sure it is pretty common for users of boost to use google to search for documentation/tutorials on their favorite library in boost. I have found that the top hits are typically not the latest documents. For example I just searched for boost,foreach and a documentation from 1.35 was the first hit. It would be great if there is a way to tell google to update their links to the latest version. Anyone knows whether this is possible, and how to make it happen? This problem probably applies to any search engine but I can only comment on google search. Thanks, Edward

11 23

[1.48.0] Beta 1 release candidates available
by Beman Dawes 20 Dec '11

20 Dec '11

Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

21 44

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 18 Dec '11

18 Dec '11

On 24 Nov 2011 09:11:19 Joel de Guzman wrote: >Man! Of course you should use the examples in 1.45. Those examples >are for 1.48 and uses new features implemented in 1.48! Sheesh! I fully understand that. The point is that the Phoenix interface is evolving much more quickly than that of probably any other Boost library. Even apart from the fact that there already have been two bottom-up rewrites, there are enough significant changes between point releases that even small example programs are tied to a particular version of the library. Why is the optimal way to write a small calculator example today so different from the optimal way to write it six months ago? I'm not disputing that you're making forward progress, just highlighting this as another barrier to entry that Local likely won't have. >Double Sheesh! If you've spent even a few seconds looking into the >error (beyond fault-finding), you will see that a simple textual >search of "error" will reveal this: Yes, it's possible to wade through the error messages and figure out what went wrong. And Qi is clearly trying to help out with traceable assertions; that may well be the best we can do. But no reasonable person would claim that hundreds of lines of error message, mostly filled with types that the user never directly constructed, are the most desirable way to report a simple syntax error. This problem is endemic to all ET libraries and compilers, and it would be very, very hard to do much better. Again, though, I think you're underselling this as a barrier to entry. How many people would ever learn C++ if all libraries did this? >Now having said that, and before I leave this thread, let me remind >everyone that **you can also have statement syntax in Phoenix** if you >have a complex statement and you fear writing complex phoenix lambda >expressions. It's called phoenix::functions. The important issue here isn't just statement /syntax/, it's that we have options available that don't turn what looks like an ordinary C++ statement into a massive AST with its own mini-compiler behind the scenes.

18 38

Standard library Technical Report 2 proposals for Boost libraries
by Beman Dawes 17 Dec '11

17 Dec '11

The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman

7 18

[local] "true" lambdas without C++11 but only on GCC
by Lorenzo Caminiti 17 Dec '11

17 Dec '11

Hello all, A curiosity: On GCC compilers (but _only_ on GCC compilers) it is possible to combine Boost.Local and the non-standard GCC "expression statements" feature to implement lambda functions. In other words, it is possible to define a Boost.Local closure within a GCC expression statement: std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); This is just a curiosity because it is NOT standard C++03 and it will ONLY work with GCC compilers. #include <boost/local/function.hpp> #include <vector> #include <algorithm> #include <iostream> // WARNING: This macros only work on GCC!!! #define LAMBDA_WITH_RESULT(result_type, ...) \ ({ /* open GCC statement expression */ \ result_type BOOST_LOCAL_FUNCTION_PARAMS(__VA_ARGS__) #define LAMBDA(...) \ LAMBDA_WITH_RESULT(void, __VA_ARGS__) #define LAMBDA_END \ BOOST_LOCAL_FUNCTION_NAME(BOOST_PP_CAT(lambda, __LINE__)) \ BOOST_PP_CAT(lambda, __LINE__); \ }) /* close GCC statement expression */ int main() { std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); return 0; } I might mention this code example as a curiosity in Boost.Local docs, currently it's not mentioned there. Thanks. --Lorenzo

2 3

New libraries implementing C++11 features in C++03
by Jeffrey Lee Hellrung, Jr. 17 Dec '11

17 Dec '11

Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut: > Ok. However this raises a more serious question. Should we as the > Boost community still encourage solutions and libraries solely for > portability with ancient compilers? I'd say no, but YMMV. Boost will > be still around 2, 5, or 10 years from now. What's the utility of > adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff

20 45

[chrono] i/o to locale or not to locale
by Vicente J. Botet Escriba 10 Dec '11

10 Dec '11

Hi all, currently Chrono provides a limited localization interface for duration and time_point I/O that is not satisfactory. The current implementation Boost.Chrono V1.2 (Boost 1.48) is based on the alternative A1 (see below) in which the hour,minute,second and the epoch can be localized. This could give the impression that chrono i/o is localized, but as Aryton as signaled it is not enough. I'm working on redesigning the chrono i/o in order to make a proposal with Howard Hinnant to the C++ committee. Two main alternatives A1- follow the formatting of recognized international body as ISO. A2- Add localization of specific units and epoch to the preceding format. It seems that the localized alternative seems to have less chances to be adopted, as no other library in the standard is providing these kind of facilities, and locale message facility is not completely satisfying. Things could change if we had a concrete proposal for improving the standard locale library (in which Aryton seems to be working IUC). More detail on the two alternatives: A1- Provide formatted i/o following the ISO 80000 http://en.wikipedia.org/wiki/ISO/IEC_80000, http://en.wikipedia.org/wiki/ISO_31-1, The format for duration could be <value> <unit> With unit been day, hour, minute, second, decisecond, centisecond, ..., decasecond, hectosecond, ... Note that the unit is always in singular form and in English. Next follows several valid inputs for duration 3 day 9 hour 1 second 0 second -1 second 3.77 millisecond 34 [1/30]second time_points could be formatted as <duration> <since epoch> where <since epoch> is a string that identifies the starting point of the epoch's clock, e.g. since boot, since process startup, .... The string associated to each clock are fixed and configurable specializing the trait clock_string Next follows several valid inputs for time_point. 123456 second since boot A1.a We can also consider ISO 8601. IMO, an acceptable format for durations could be a variation of the extended format independently of the date. <hours>:<minutes>:<seconds>[.fractional_seconds] Note that <hours> here is not limited to 24, and gives the total number of hours. A1.b An additional alternative could be to represent a duration as following a variant of the period representation: P[n]Y[n]M[n]DT[n]H[n]M[n]S in which the year and month are represented by days. E.g. P[n]DT[n]H[n]M[n]S[n]F P1234DT12H30M5S555F A2 - Make durations and time point i/o locale dependent. Based on the previous alternative, add the possibility to add specific locale facets that could format a duration following the pattern <value> <unit> <unit> <value> <hours><:><minutes><:><seconds>[<.>fractional_seconds] Here <value> and <unit> will be formatted following the specific locale and in this case the unit could have specific plural forms. For example in French the user could specialize the facets so that she could get 1 jour 3 jours 9 heures 1 seconde 0 secondes -1 seconde 3.77 milliseconds 34 [1/30] de seconde and in Spanish 1 segundo 0 segundo -1 segundo Add the possibility to add specific locale facets that could format a time_point following the pattern <duration> <epoch> <epoch> <duration> system_clock::time_point is a special case that should be formatted as a localized date, relative to the epoch 1900/01/01. A3 - Add on top of A2 some _byname facets. The fist alternative is in line with the money standard locale category that uses standard symbols, as $ or USD. It has the drawback that the <value> could be localized while the <unit> is not, e.g. 1,234 second Note the use of ','. The third alternative is IMO closer to the user expectations, but needs a better locale messages/by_name facet. The second alternative is a pragmatic one that left the possibility to build A3 when a satisfying messages/by_name facet is available. Boost.Chrono 2.0 in the trunk is a prototype of A2, that doesn't provides facets by locale name, only a default English implementation. That means that for the time been, the user needs to imbue a locale with her specific facet to get the expected localization (See french.cpp example in the SVN repository) What the Boost community think about this? Towards which alternative should Boost.Chrono move? Should Boost.Chrono wait until a concrete standard proposal is accepted? Thanks in advance, Vicente

2 6

[msm] deferral stack overfolw
by Richard Szabo 08 Dec '11

08 Dec '11

Hi Christophe just playing around with event deferral I have found a problem which leads to a stack overflow it ends in an infinite loop if I want to defer 2 events in the same state. see attached example it somehow similar to the problem we had earlier but that was fixed ... I have ran this test on MSM trunk version from yesterday. Cheers Richie

2 8

[stl_ext_adv] ] Interest in advanced data structures
by Vadim Stadnik 08 Dec '11

08 Dec '11

Hi all, Advanced data structures (ADS) offer useful STL extensions that are not possible or not efficient with basic data structures, such as arrays, linked lists and red-black trees. The project https://github.com/vstadnik/stl_ext_adv http://dl.dropbox.com/u/51041088/stl_ext_adv_doc/index.html focuses mainly on a generalized and unified computer representation of sequences using the augmented B+ trees. It provides the following STL extensions: - The sequence container supports random access iterators and a union of interfaces of STL containers: vector, list and deque. This sequence offers the advantage of efficient update operations with logarithmic running time compared with linear running time of the same operations of std::vector. - The associative containers (set, multiset, map and multimap) with random access iterators. - The enhanced random access iterators effectively address the fundamental problem of the iterator invalidation. - The function accumulate() with logarithmic computational complexity can significantly improve performance of many practically important algorithms and applications, such as the numerical integration, the statistics, the data analysis etc. The examples demonstrate how to improve the computational complexity from O(N) to O(log N) in the following applications and problems: - numerical integration. - calculation of mean value and standard deviation; - calculation of weighted mean value; - testing if any number of consecutive elements are equal; - counting intersections of one interval with sequence intervals; Is there an interest in this project and implemented STL extensions? Interest in potentially useful, but not yet implemented algorithms and specialized containers: 1. The function accumulate() with constant computational cost. With this function some user algorithms, such as the numerical integration, can come close to the absolute theoretical limit of the computational cost. The function can be implemented through iterators enhanced with functionality of accumulators. For more details, see the section “Random access iterators” in the documentation. 2. The functions sequence::splice() with logarithmic running time in the worst case. Note that functions std::list::splice() provide in many cases constant computational cost, however, in the worst case the cost is linear. 3. Any other potentially useful specialized containers, iterators or algorithms? Augmented B+ trees are versatile and powerful data structures. They can be designed to maximize efficiency of particular algorithms and programming solutions. The limitation of specialized containers is that the computational cost of some other operations may increase. About augmented red black trees. The augmented red black trees can also support various STL extensions. The red black trees are yet out of the scope of this project for the reasons explained in the documentation. However, historically augmented red-black trees are probably the first ADS that could extend STL, since the method of augmenting red black trees was described as early as in 1990 [T.H. Cormen, C.E. Leiserson and R.L. Rivest.” Introduction to Algorithms” (1st ed.). MIT Press and McGraw-Hill, 1990]. This means, in particular, that the very first version of STL could provide associative containers with random access iterators. Also, as I understand the previously submitted project https://github.com/boost-vault/Containers/blob/master/countertree.zipimplem… containers based on the augmented red black trees. It is hardly possible to make an exact prediction, but without a doubt future versions of STL will benefit from advanced data structures. Regards, Vadim Stadnik

11 29

[chrono] steady_clock efficiency
by Kenneth Porter 06 Dec '11

06 Dec '11

I expect most people will use boost::chrono::steady_clock to measure performance. I've been considering switching from my raw calls to the Windows peformance counter APIs to the steady_clock. I'm a little worried about the overhead of what should be a non-intrusive facility. In examing the source, I see that steady_clock::now() reads the performance counter and then multiplies it by the reciprocal of the counter's frequency (acquired on first use of the clock) to return the time in nanoseconds. How expensive is this 64 bit multiply on a 32 bit system? How hard would it be to have now() return a time_point that stores the raw tick value and only converts it to nanoseconds when a calculation in real units is required? (Comparison to another time_point could still be done in performance counter ticks, saving the multiply.) Is it worth the extra complexity to demand-convert ticks to nanoseconds? Source is in boost_1_48_0\boost\chrono\detail\inlined\win\chrono.cpp

5 15

[units] - learning to use
by Janek Kozicki 05 Dec '11

05 Dec '11

Hi, I wrote a short function that integrates Huyghens spherical wave for diffraction. (This is a single slit experiment btw). I have some questions, marked with (*) double integral( const quantity<length> x // x - position where light intensity is calculated , const quantity<length> R // R - distance from slit to screen , const quantity<length> D // D - slit width , const quantity<length> lambda // lambda - wavelength , double steps // steps - number of integration steps // (*) ) { complex<double> i(0,1); complex<double> a(0); static const double pi = 3.14159265358979323846; // (**) quantity<wavenumber,complex<double> > k=2*pi/lambda; quantity<length> d=-0.5*D; // d - position on the slit quantity<length> dd=D/steps; // dd - width of integral step // integrate from -d to d: exp(i*k*r)/r for( ; d<= 0.5*D ; d+=dd ) { quantity<length> r=sqrt(pow<2>(R)+pow<2>(x-d)); a += (dd*exp(i*k*r)/r).value(); // (***) } return pow<2>(abs(a)); } (*) it should be `int steps` but if I write it this way I get a compilation error here: quantity<length> dd=D/steps; // dd - width of integral step That looks like a conversion problem. (**) why do I need to define pi ? I expected to find it somewhere, but I couldn't. (***) it seems strange that I need to take .value() here. The result is dimensionless, why can't it directly convert to complex<double> ? There is a risk that .value() would be expressed in millimeters or angstroms or whatever (maybe depending on dd), and then .value() would return a wrongly scaled number? Another question, why this works: quantity<length> wavelength ( 632.8 *nano*meters); and this does not? quantity<length> wavelength = 632.8 *nano*meters; Of course I know about extra copying, and waste of CPU resources on execution, when compiler isn't able to optimize this away (and usually it is able to do that). But why the heck this simple assignment can't work? PS: I am attaching a short test version of this program, it's in polish, but I hope you don't mind. best regards and thanks in advance for your help -- Janek Kozicki http://janek.kozicki.pl/ |

5 22

[1.49.0] New libraries?
by Beman Dawes 03 Dec '11

03 Dec '11

What new libraries are ready for 1.49.0? What is that state of any new libraries that want to go in 1.49.0? Are they in trunk and do the developers think they are ready to be merged into release? The release managers would like to have a four week beta period of 1.49.0. That means we have to get going on new libraries right way if we are going meet our early February release schedule. --The release team

6 12

[thread] patch to allow custom stack size.
by Brett Lentz 03 Dec '11

03 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch and (very) rudimentary usage example is attached. A couple months ago, I sent mail to the list looking to see if there's interest in getting some patches merged from Phusion Passenger. (See: http://marc.info/?t=131722868200003&r=1&w=2 ) So, here's the first patch I'd like to try to get committed. On pthread-based systems, it allows for the user to request a custom stack size. This is useful in Passenger's case where they want to reduce the VM size without requiring the user to hassle with ulimit settings. Passenger spawns many threads rather than using a thread pool for performance reasons. As a result of this design decision, they also need the ability to tune the stack size. Ticket #5956 already exists for this patch. I've verified that the patch works against the current (1.49) codebase out of SVN. What next steps need to be taken before this is committed? - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1lZEAAoJEEAzW/nB31+3fx4H/iulwAM7vGlZW56xsuezTXPC 6SSuYzUlkyVeCngpireVyD0+Um/ACFBM8FSf76cRnewX5449T01IycmX3fUe+z7g DjjUCQAHJ/9pdfrqEHz0d7wZcZbeBHUm2zggdDGcn703JQSagg2Q5d5mz48RU8/J ixTe/oAOAaXk5TQo/92fHrAmtpwfQON4tPsS7Om0kJ5vcv3PbIqQ0Q4eBKRJCVHI /CFfc3xXwSaR1xUkwhPHtjydlIWAMo0+bdKgJE5HGnn6fQSU5jlZ+ihDyajOmM88 ueaIcWi7pa3OZwLzrUNG0xIH4m7wtk0ga8edym4+ZvuovUi4vYRA1k4dIzBOtvg= =0dQJ -----END PGP SIGNATURE-----

6 14

[thread] [rfc] patch to change condition_variable and mutex error checks
by Brett Lentz 02 Dec '11

02 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch is attached. I'd like to get some comments about this patch. Does it seem reasonable enough to accept? Is there a better way to handle it? BOOST_VERIFY aborts on EINTR, but EINTR is usually not fatal, it just means you need to try later. So, the attached patch makes it so that the condition_variable and mutex error checks retry on EINTR, but will still fail on any other error. This issue was uncovered on one of Phusion Passenger's customers' production systems. - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1pVQAAoJEEAzW/nB31+3CgMIAMPYRMvuuYWdHbmWF7qWt13i pKRLGDjT5fT75SzVdcmwFNJLlboaP5tNi8g89Kw+iS+jjghEbyZr2Zx6BdCL67ne +XtA1DqlmNHD3GZiLMlQDdPqbV7qliqj4d7+8xXqXnivxULYPwQMzW1XXY8Cs4Ys uHBK/NrvZM+/LL2umHSCOLbKz7AEli6tSzuUyw557ubp42UPnE+gc+mUb7QYmcgW BKzizZ03s+V4qJA/B+N4Ux8RvvhWgNLXnYoC958mzvnTwaTbdGfEmzVkKaWucI50 jsEzfejn/Gru2BNeC2MwVmecxmkHugoXxvVUYIH4PaDET96BM3ihHWV+4SLg7ik= =xkyz -----END PGP SIGNATURE-----

3 6

Local and Phoenix idiosyncrasy
by Thomas Heller 02 Dec '11

02 Dec '11

Hi list, Can we please put an end to this insane idiosyncrasy going on here lately? It doesn't lead to anywhere! Ok, we get it ... people want to write local functions in the usual way. Here is what I have to propose: Why not combine Boost.Local and Boost.Phoenix and keep everybody happy? If the macros provided by Boost.Local would emit some instance of a phoenix::function. It would be great if this could be done completely polymorphic, maybe some tricks with boost::any? That way we gain these advantages: 1) We can get rid of the need to capture variables in scope by the macro. 2) People who don't want to put their functions in global/namespace/class scope and are afraid of writing a phoenix expression don't have to 3) The resulting lazy function will be composable in the usual phoenix way and will be far more useful! 4) We can put an end to this useless Phoenix vs. Local discussion In peace, Thomas

7 12

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 01 Dec '11

01 Dec '11

On 23 Nov 2011 10:21:50 Joel de Guzman wrote: >a good approximation of lambda is already existing in Boost. Namely: bind, >lambda and phoenix. I posted a Spirit example of lambda in action using >Phoenix: > >http://tinyurl.com/7w2h2r9 > >Try as hard as you can, but you cannot ever come close to the clarity of >he syntax presented there. Proponents of locals have cited error-messages >generated by the compiler as a justification for Locals. Locals is probably >a good workaround. But hear me out... First of all, this "trivial" example didn't even compile on the first machine I tried it on, which had Boost 1.45 (which doesn't expose qi:_val_type or qi:_1_type). This is a pretty good reminder of the fact that Phoenix remains a fast moving target (1.45 is less than a year old) and still appears unnecessarily baroque to new users (why are typenames that need to be cited in even a basic tutorial prefixed with an underscore?) Local/Closure, on the other hand, seems to have a pretty stable interface at this point. On a machine with 1.48, the example compiles just fine. If you were to pass std::string::iterators instead of const_iterators to phrase_parse(), though ( a pretty common class of mistake in the real world), you get this error message (GCC 4.4.4): /usr/include/boost/spirit/home/qi/reference.hpp: In member function 'bool boost::spirit::qi::reference<Subject>::parse(Iterator&, const Iterator&, Context&, const Skipper&, Attribute&) const [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Context = boost::spirit::context<boost::fusion::cons<int&, boost::fusion::nil>, boost::spirit::locals<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >, Skipper = boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, boost::spirit::qi::skip_flag::enum_type, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = client::calculator<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, Skipper = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, Attr = int]::skipper_type, Attribute = int, Subject = const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>]': /usr/include/boost/spirit/home/qi/parse.hpp:164: instantiated from 'bool boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, boost::spirit::qi::skip_flag::enum_type, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = client::calculator<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, Skipper = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, Attr = int]' /usr/include/boost/spirit/home/qi/parse.hpp:197: instantiated from 'bool boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = main()::calculator, Skipper = boost::spirit::ascii::space_type, Attr = int]' calc3.cpp:101: instantiated from here /usr/include/boost/spirit/home/qi/reference.hpp:43: error: no matching function for call to 'boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>::parse(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, boost::spirit::context<boost::fusion::cons<int&, boost::fusion::nil>, boost::spirit::locals<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >&, const boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >&, int&) const' But that's nothing; if you omit the '>>' from the expression or term definition you get the 33 kilochar beauty copied at the bottom of this email. There have been several postings to this list in the past about trivial errors (substituting the wrong type or omitting a forward declaration and so forth) that generate hundreds of kilobytes of compiler barf with no apparent relation to what is actually wrong with the source. Yes, the compiler is also largely to blame (although GCC does not seem any worse here than the other mainstream options) and perhaps someday this will finally get better, but I think you grossly underestimate the deterrent effect this has on new users and on wider adoption of Phoenix and similar libraries. Phoenix is great when you really need it, but there's also quite a lot to be said for alternatives (including Boost.Local) that don't build massive, fragile scaffolds of parametric types and in some sense keep what the compiler 'sees' on a given line of source similar to what the programmer sees in a text editor. Don't get me wrong; I think Phoenix is an amazing piece of work, and for someone who needs late binding and lazy evaluation in an expression (or a small DSEL without depending on an external parser generator) it's a godsend. I just happen to believe that you could say the same things about Boost.Local--- if this is what you need, it's *exactly* what you need. Many Boost users may never need local functions, but you could again say the same thing about the vast majority of the 113 official components of 1.48. If you want to keep Boost limited to the bare essentials, it's already far too late. The bar for entry should be that the library is well designed, well documented, well implemented, serves a need that a nontrivial number of users have, and isn't likely to interfere with the implementation of other future language or Boost features, not that it will be used just as frequently as enable_if<> or optional<>. >Keep in mind that Boost has been at the forefront of C++ library development. >It is because of these libraries that push the limits of C++ that we see the >advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda Hey, that's great. I just think that we all need to recognize that very little C++ software is written with "push the limits of the language" as one of the goals in mind. The participants on this particular list have self-selected for interest in developing state-of-the-art libraries, but most also have day jobs where they're just trying to maintain an existing codebase with minimal hassle for their colleagues and customers, as well as side projects where getting something running quickly and correctly is more important (if not always more interesting) than figuring out just how far we can push overload resolution rules. And probably 99% of Boost users and 99.9% of potential Boost users aren't the kind of programmers on this list and have no interest at all in "pushing the envelope"--- they just want tools with simple, stable syntax and easy debugging, both of which Local offers. Furthermore, no matter how slick your personal environment is, it's a simple fact that there are thousands and thousands of important projects that will never have the benefit of a C++11 compiler for a variety of reasons. I *really* don't understand the criticism from several people about using macros to implement the library. Part of the power of C++ is that its syntax is extensible, and the preprocessor and operator overloading are the two mechanisms that enable that. The preprocessor is part of the language specification, arguably even more so than the standard library since a (nonconforming) implementation that ships with only 10% of the standard library implemented is far more useful in practice than an implementation that ships with only 10% of the preprocessor implemented. Yes, macros can be abused, as can operator overloading (as many would criticize Phoenix), but often they're the most appropriate choice. There should be only two questions here: are there a nontrivial number of users who desire or would benefit from local functions, and is there a better way to provide them than what Lorenzo has chosen? ------------------- Horrific error messages follow --------------------- /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp: In static member function 'static void boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]': /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:220: instantiated from 'boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>& boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::operator=(const Expr&) [with Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]' calc3.cpp:49: instantiated from 'client::calculator<Iterator>::calculator() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]' calc3.cpp:90: instantiated from here /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:176: error: no matching function for call to 'assertion_failed(mpl_::failed************ (boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]::error_invalid_expression::************)(boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>))' /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp: In static member function 'static void boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]': /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:220: instantiated from 'boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>& boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::operator=(const Expr&) [with Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]' calc3.cpp:56: instantiated from 'client::calculator<Iterator>::calculator() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]' calc3.cpp:90: instantiated from here /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:176: error: no matching function for call to 'assertion_failed(mpl_::failed************ (boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]::error_invalid_expression::************)(boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>))'

18 82

Library categories
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, I was wondering if we can add other categories to the library catalog (http://www.boost.org/users/history/version_1_47_0.html) Here is a proposal Best, Vicente Domain Specific crc - Cyclic Redundancy Code, from Daryle Walker. units - Zero-overhead dimensional analysis and unit/quantity manipulation and conversion, from Matthias Schabel and Steven Watanabe. uuid - A universally unique identifier, from Andy Tompkins. Idioms base-from-member - Idiom to initialize a base class with a member, from Daryle Walker. compressed_pair - Empty member optimization, from John Maddock, Howard Hinnant, et al. Language Emulation: these are libraries are emulating a missing language feature exception - A library for transporting of arbitrary data in exception objects, and transporting of exceptions between threads (N2179), from Emil Dotchevski. move - Portable move semantics for C++03 and C++1 compilers, from Ion Gaztañaga scope_exit - Execute arbitrary code at scope exit, from Alexander Nasonov. typeof - Typeof operator emulation, from Arkadiy Vertleyb and Peder Holt. Patterns: libraries that implement a known pattern flyweight - Design pattern to manage large quantities of highly redundant objects, from Joaquín M López Muñoz. signals - managed signals & slots callback implementation, from Doug Gregor. signals2 - managed signals & slots callback implementation (thread-safe version 2), from Frank Mori Hess. State Machines meta state machine - High-performance expressive UML 2.0 finite state machines, from Christophe Henry. statechart - Arbitrarily complex finite state machines can be implemented in easily readable and maintainable C++ code, from Andreas Huber. System: libraries that are close to the underlying system chrono - Useful time utilities, from Howard Hinnant, Beman Dawes, Vicente J. Botet Escribá. date_time - Date-Time library from Jeff Garland. filesystem - Portable paths, iteration over directories, and other useful filesystem operations, from Beman Dawes. system - Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. I would add also the following to exixting categories Data structures optional - Discriminated-union wrapper for optional values, from Fernando Cacciola. tribool - 3-state boolean type library, from Doug Gregor. I have no suggestion for the following, so we can maintain them in Miscellaneous conversion - Polymorphic and lexical casts, from Dave Abrahams and Kevlin Henney. swap - Enhanced generic swap function, from Joseph Gauterin. timer - Event timer, progress timer, and progress display classes, from Beman Dawes. TR1 - An implementation of the Technical Report on C++ Library Extensions, using other Boost libraries as a basis, from John Maddock. utility - Class noncopyable plus checked_delete(), checked_array_delete(), next(), prior() function templates, plus base-from-member idiom, from Dave Abrahams and others. value_initialized - Wrapper for uniform-syntax value initialization, from Fernando Cacciola, based on the original idea of David Abrahams. The following libraries are already in another category lexical_cast - General literal text conversions, such as an int represented as a string, or vice-versa, from Kevlin Henney. numeric/conversion - Optimized Policy-based Numeric Conversions, from Fernando Cacciola. program_options - Access to configuration data given on command line, in config files and other sources, from Vladimir Prus.

7 18

[rfc] lockfree API/naming suggestions
by Tim Blechmann 30 Nov '11

30 Nov '11

hi all, i am preparing boost.lockfree so that it can be merged to trunk. however i'd request some suggestions, concerning interface and names: ringbuffer naming: there is a fixed-sized single-producer/single-consumer wait-free queue, which is implemented as ringbuffer. the linux kernel uses the name `kfifo', the jack-audio-connection-kit refers to it as `ringbuffer', herlihy/shavit discuss it under the name `BoundedQueue'. the boost.lockfree implementation is currently named `ringbuffer', but i could rename it before merging it into trunk. suggestions: ringbuffer waitfree_queue spsc_queue bounded_queue personally i'd be in favor of `ringbuffer' (because i have been using this name for years) or `spsc_queue' (because it makes clear that it doesn't support multiple produces/consumers). but i'd be curious, what other people suggest. fifo/queue bounded push: fifo and queue can be configured to use a dynamically growing freelist for memory management. in this case, the `push' operations may block if the freelist is exhausted and a new node has to be allocated from the OS. currently this can be avoided by a per-class policy. however it would be reasonable to move this policy from a per-class to a per- call policy. so instead of: queue<T, boost::lockfree::bounded<true> > q; T t; q.push(t); one could write: queue<T> q; T t; q.push_nonblocking(t); however this would imply 3 flavors of `push' * push, which may block during memory allocation * push_unsafe, which is not thread-safe (but faster) * push_nonblocking, which is guaranteed not to hit the memory allocator. so i am not sure, whether this introduces too much complexity into the API. any thoughts/comments? thanks, tim

5 8

installing 1.48 on debian squeeze
by Janek Kozicki 30 Nov '11

30 Nov '11

Hi, does anybody here know some not too complex way to install boost 1.48 on debian squeeze? Preferably using a .deb package. manual install is also acceptable, but in a way where it will not conflict with native installed boost 1.42. looking forward for your help -- Janek Kozicki http://janek.kozicki.pl/ |

2 1

[spirit] scan_keyword: scan an InputIterator for a keyword.
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, for chrono input I'm using a scan_keyword function that adapted from libc++ library (you can find the code in[1]). Next follows the interface: // scan_keyword // Scans [b, e) until a match is found in the basic_strings range // [kb, ke) or until it can be shown that there is no match in [kb, ke). // b will be incremented (visibly), consuming CharT until a match is found // or proved to not exist. A keyword may be "", in which will match anything. // If one keyword is a prefix of another, and the next CharT in the input // might match another keyword, the algorithm will attempt to find the longest // matching keyword. If the longer matching keyword ends up not matching, then // no keyword match is found. If no keyword match is found, ke is returned // and failbit is set in err. // Else an iterator pointing to the matching keyword is found. If more than // one keyword matches, an iterator to the first matching keyword is returned. // If on exit b == e, eofbit is set in err. // Examples: // Keywords: "a", "abb" // If the input is "a", the first keyword matches and eofbit is set. // If the input is "abc", no match is found and "ab" are consumed. template <class InputIterator, class ForwardIterator> ForwardIterator scan_keyword(InputIterator& b, InputIterator e, ForwardIterator kb, ForwardIterator ke, std::ios_base::iostate& err ); What is the better way to do that (or something similar) with Spirit/Lexer? Can we hope that the Spirit solution could perform much better? What about if the strings to parse are know at compile-time? [1] https://svn.boost.org/svn/boost/trunk/boost/chrono/detail/scan_keyword.hpp Best, Vicente

2 3

temp_ptr<> - preventing use as a member
by Gottlob Frege 29 Nov '11

29 Nov '11

I'm trying to see if I can replace all raw pointers with suitable smart pointers that clearly describe the pointer's lifetime, sharing, etc. For example, a pointer passed into a function, that is only valid for the lifetime of the function call. A temp_ptr or callstack_ptr or ... some better name. So this pointer would need a copy constructor so it can be passed along into a function (I don't think requiring a ref to the pointer would be good; I'd rather pass by value). It would also need construction from a raw pointer, but to avoid having a temp_ptr being kept beyond the function call, it would not have assignment (from another temp_ptr). To prevent constructing one via the copy constructor that will be kept around, I can define a custom new operator but keep it private. The only thing, I think, that I can't prevent, is construction of a new wrapper struct that has a temp_ptr as a member (which is copy constructed in wrapper's constructor). Can anyone think of a way to prevent that? I think anyone that goes out of their way to make a wrapper struct gets what they deserve, so I don't really *need* to prevent all bad uses. But I can aslo imagine someone just using it improperly inside their class due to misunderstanding or whatever. And thoughts on the goal of specific smart pointers for all occasions? Tony

6 11

[trac] please add component
by Akira Takahashi 29 Nov '11

29 Nov '11

Hi, I seems to so that the 1.48.0 library component is not registered in Trac(container, move, and locale). Please add component.

2 2

[optional] std::tr2::optional
by Andrzej Krzemienski 29 Nov '11

29 Nov '11

Hi, I use boost::optional quite often, find it very useful, and cannot imagine that it could not get into TR2. I am considering writing a proposal for adding it myself (if it is possible to propose things without attending the committee meetings), but I would first want to know how boost::optional could be improved given the new features in C++11. I provide a list of modifications that I could think of. What is your opinion? * Conversion explicit conversion to bool should be declared as explicit. * Should exception safety guarantees for assignment operations be enforced? In boost::optional they only provide a basic guarantee. One option is to provide strong guarantee for types T which implement operator= with strong guarantee, and give basic guarantee for other cases Other option (not sure if it is possible) is to provide strong guarantee for all cases at the cost of run-time performance (heap allocation). * Add move operations optional<T> & operator=( optional<T> && ) noexcept( nothrow_move_constructible<T>::value ); optional<T> & operator=( T && ) noexcept( nothrow_move_constructible<T>::value ); * move operations for optional references? But I am not sure what optional references are for... * What are optional references for anyway? * it could add an rvalue reference overload for stored object access: T&& operator*( ) && However using this overload implies that the user is not checking if an optional has been initialized, so it may encourage a bad practice. * Are in-place factories necessary if we have perfect forwarding? Instead, we can provide a reset function and a "variadic constructor": template< typename ... Args > void reset( Args&& ...args ); template< typename ... Args > optional( Args&& ...args ); The constructor will clash with another optional constructor: optional<T>::optional( bool cond, const T& val ); but perhaps it is not needed if we have std::optional<T> std::make_optional( bool cond,const T& val ); and move construction of optionals? * noexcept default construction and destroy operations * constexpr default ctor * Use nullptr instead of boost::none? - this will make some uses of optional pointers harder, but will make usage more clear in other cases. Regards, &rzej

7 7