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

Proposed Boost.Algorithms Review Ends
by Dave Abrahams 28 Nov '11

28 Nov '11

The review of Marshall Clow's proposed Boost.Algorithms submission officially ended yesterday, but if you get your review in before the end of the weekend, as review manager I'll probably consider it. So far we've had five votes, which is reasonable for something of this scale. Thanks everybody for your time and interest. I'll be posting the review results next week. Regards, Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 3

[msm] guard behavior if guard guards the transition MSM threats event as handled is that correct?
by Michael.Herchel＠rohde-schwarz.com 28 Nov '11

28 Nov '11

Hi Christophe, Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units. I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that. What is your opinion? Am I thinking too short? Thanks, Michael

2 1

Fwd: [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?
by Richard Szabo 28 Nov '11

28 Nov '11

Hi Christophe the attached example I think shows 2 problems. 1st is that the deferral of event3 is not happening. 2nd is that the no_transition function is never called. the output of the run is : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 FwdGuard: returns:0, event: event5 MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 I think it shall be : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 MS1 no_transition event (event4) MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 MS1 no_transition event (event3) So in this example event3 and event4 are never triggered a transition ... the Row < SubRunning , baseEvent , none , ProcessBaseEvent , FwdGuard > was guarded by the FwdGuard for these events. Is my expected behavior wrong ? If guard is executed but the transition actually is triggered because it is guarded out why this event treated as handled event ?. This 2 problems breaks my current nested state machine implementation because I'm using no_transition to forward the event to the outer state machine. I'm confused :(. Cheers Richie

2 6

[spirit] missing boost/endian/integers.hpp
by Jürgen Hunold 28 Nov '11

28 Nov '11

Hi, after the version number bump to 1.49.0 my builds fail with src/devel/boost/boost/spirit/home/support/detail/endian.hpp:24:37: fatal error: boost/endian/integers.hpp: No such file or directory It seems that spirit want to use Boost.Endian from 1.49 which is not merged to trunk yet. Patch attached, ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 1

[preprocessor] Get last token
by Roman Perepelitsa 28 Nov '11

28 Nov '11

Is it possible to extract the last token from a list of space separated tokens? LAST_TOKEN(a b) // expands to b LAST_TOKEN(blah blah b) // expands to b LAST_TOKEN(* & b) // expands to b Roman Perepelitsa.

2 4

Re: [boost] [Boost-commit] svn:boost r75690 - trunk/tools/build/v2/tools
by Steven Watanabe 27 Nov '11

27 Nov '11

AMDG On 11/27/2011 04:50 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > New Revision: 75690 > URL: http://svn.boost.org/trac/boost/changeset/75690 > > Log: > Change deprecated /Op option to its replacement, /fp:precise. This quiets a warning from the Intel compiler, which uses the msvc toolset. > Did you miss my reply on boost-build? Please revert this. It's wrong. > On 11/26/2011 06:03 AM, Beman Dawes wrote: >> > The patch below clears a warning from Intel 12.1, and works fine for >> > MSVC 8, 9, and 10. >> > >> > Unless someone objects, I'll apply it tomorrow. I'm posting advance >> > notice in case any of the math folks want to give it a try beforehand. >> > > I object. This branch is for msvc 6 and 7, which > only have /Op. /fp:precise is for msvc 8 and > up. The real problem is that intel-win is assuming > vc7.1 compatibility. > > Text files modified: > trunk/tools/build/v2/tools/msvc.jam | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Modified: trunk/tools/build/v2/tools/msvc.jam > ============================================================================== > --- trunk/tools/build/v2/tools/msvc.jam (original) > +++ trunk/tools/build/v2/tools/msvc.jam 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > @@ -240,7 +240,7 @@ > > # Improve floating-point accuracy. Otherwise, some of C++ Boost's "math" > # tests will fail. > - toolset.flags $(toolset).compile CFLAGS $(conditions) : /Op ; > + toolset.flags $(toolset).compile CFLAGS $(conditions) : /fp:precise ; > > # 7.1 and below have single-threaded static RTL. > toolset.flags $(toolset).compile CFLAGS $(conditions)/<runtime-debugging>off/<runtime-link>static/<threading>single : /ML ; > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit >

2 1

[local] Any "active Boost library author" in favor of Boost.Local?
by Lorenzo Caminiti 26 Nov '11

26 Nov '11

Hello all, I will be honest: The fact that some of the people arguing for not including Boost.Local are "active Boost library authors" (Thomas, Joel, and Hartmut) seems to make their opinion weight more than the opinion of others that have also submitted a review for the library. Two questions: 1) Should reviews from "active Boost library authors" carry more weight? (This is /not/ a rhetoric question.) 2) Is there any "active Boost library author" out there that is in favor of including Boost.Local? (If so, please say so by replying to this thread.) Thanks a lot :) --Lorenzo

8 18

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

25 Nov '11

On 24 Nov 2011 20:19:17 Joel de Guzman wrote: >The funny thing is that the new feature came from Spirit, not >Phoenix. Phoenix API has been stable for many years now. Triple >sheesh for ya! :-) Then why did V3 require a review earlier this year? Phoenix is great if you want things that are easy in a functional programming language to seem easy in C++, but it does have a learning curve. Local requires a little more typing for short snippets, but is probably far less intimidating, and has far fewer potential "gotchas", for the typical user. I don't think the two are competing with each other at all--- Phoenix provides a far richer set of building blocks for those who want them, and Local offers a stable interface, trivial execution model, and straightforward error messages for those who simply want to use a local function here and there. For a non-guru who just wants to reduce code duplication or port something from Delphi, Local is in many cases the more appealing choice.

2 2

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
by Andrzej Krzemienski 25 Nov '11

25 Nov '11

> Hello all, > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) Hi Lorenzo. I am /not/ an active Boost library author or maintainer. I will only address the first question. I was asking myself the same question recently, and my answer to it is that their opinions should weigh more than others'. Well, "others" is an ambiguous term; I meant someone like me, who is just a Boost user, and says "I want to have this, and this, and that one". My argument is that Boost as an organization has its goals or status, or spirit (no pun intended). I tried to look for something like "what is our goal" on the Boost site, but I did not find a satisfactory answer. The only thing that I found useful is a section in Scott Meyers's "Effective STL". I am not sure if Boost developers will agree, but he says that Boost was founded in part by people who submitted proposals for Standard Library to the C++ committee that were rejected. Boost was supposed to be the place where these libraries were still to be developed, maintained and widely used, which would give them the grater chance to succeed in the next round of standardization. On the other hand, some existing Boost libraries do not appear (at least in my limited view) to meet this criterion (as well as other criteria mentioned recently). I am thinking about the unit testing framework. Do not get me wrong I am not trying to imply that it shouldn't be there, and in fact this is my preferred unit testing framework for many valid reasons. But I was trying to apply the recently risen acceptance criteria to all Boost libraries that I know, and this example appeared the most interesting. Even though it provides a non-macro alternative it encourages using macros for nearly everything in the "automated version": tests, checks, suites, modules. Even thought there are other free libraries for C++ that are known to provide almost the same functionality without a single macro: http://tut-framework.sourceforge.net/. It does not look like a potential candidate for the inclusion into the standard; there are many unit-testing frameworks out there that do not appear to be any worse. It does not appear to encourage some good coding style (apart from the fact that having good unit tests is a good development style).... Given this lack of clear criteria, active Boost library authors and maintainers should be in the better position to assess if the tacit criteria for library admission are met. Some of them have been with boost since its inception (almost 15 years now). If we think otherwise, we are risking the situation where Boost users that just want some library "in the Boost package" will outnumber the few library developers that have a broader goal in mind, and may not even have time to submit a review because they are busy maintaining their libraries or submitting proposals to ISO Committee. I guess that in case of Boost.Local review, this argument would be stronger if the "active Boost library author" reviewers were not the authors of libraries that /somehow/ overlap with Boost.Local. Thus I believe you are bringing the valid point in trying to engage other Boost library authors, and it would be beneficial, also to the entire Boost community, if someone responded to your question. Regards, &rzej

1 0

Formal Review Schedule Queue
by Ben Robinson 25 Nov '11

25 Nov '11

Currently, there are eight library submissions in the queue, none of which have a review manager or a scheduled review period. What is the process to assign review managers? I realize that the Boost.Local review is still in progress (and quite a lively discussion). :) Ben Robinson, Ph.D.

2 1

[Boost.Local] Review
by Hartmut Kaiser 25 Nov '11

25 Nov '11

This is not a full review, mainly because I have not had the time to devote more than a quick glance over the documentation (which is a good read, btw). Upfront my vote: no, please do not include this library into Boost. My reasons are: a) Boost is a library which has quite some visibility not only for library writers but also for application developers. IMHO, Boost not only has the task of finding new ways for using C++, but it plays the role of evangelizing good programming style, great API design, and thoughtful functionality. Using macros as the sole API of a library to be mainly used by application writers (not library authors) is not a good idea because of all those well know problems related to macros: difficult to debug, error messages are even more difficult to interpret than those generated by TMP, macros are type agnostic and have absolutely no knowledge of C++, etc. b) The proposed library does not add any functionality which couldn't be _easily_ replaced by using existing C++ language features or libraries. This is especially true if we talk about C++11 (which we should, IHMO). c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

7 20

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local
by Brian Wood 25 Nov '11

25 Nov '11

Lorenzo Caminiti: > Hello all, > > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) > 2) Is there any "active Boost library author" out there that is in > favor of including Boost.Local? (If so, please say so by replying to > this thread.) I'm in favor of accepting it. Not because I plan to use it, but think Boost could use the help and you have been learning the ropes. Regardless of the outcome of the review, I like the tenacity you've shown. I'm not a Boost library author. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Error in the getting started guide?
by Philip Bennefall 24 Nov '11

24 Nov '11

I was just looking at the getting started guide on Windows for version 1.48.0 and saw this paragraph: The easiest way to get a copy of Boost is to use an installer. The Boost website version of this Getting Started guide will have undated information on installers as they become available, ..." I'm guessing it should be "updated"? It might confuse new users slightly so I thought I'd mention it. If the list is not the right place for this note, then I apologize. Kind regards, Philip Bennefall

2 1

[lexical_cast] Error casting void* to std::string
by GMan 24 Nov '11

24 Nov '11

I did a search on the mailing list and found nothing, but apologies if I missed it. This bug seems to be new to 1.48. Compiling the following code in MSVC2010: #include <boost/lexical_cast.hpp> #include <string> int main() { void* ptr = 0; boost::lexical_cast<std::string>(ptr); } Results in an error, pointing to line 1738 in boost\lexical_cast.hpp, stating: 'removed_ptr_t': illegal sizeof operand. ('removed_ptr_t' is, however, defined a few lines above.) I see nothing wrong with the code from a C++ point-of-view, so I'm guessing this is another MSVC bug. Is this known? I don't see an immediate permanent workaround. A client-side workaround exists by introducing this small class: struct print_ptr { explicit print_ptr(void* ptr) : mPtr(ptr) {} friend std::ostream& operator<<(std::ostream& sink, print_ptr printPtr) { return sink << printPtr.mPtr; } private: void* mPtr; }; And using: boost::lexical_cast<std::string>(print_ptr(ptr)); -- GMan, Nick Gorski

3 3

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

From: Gregory Crosswhite > Perhaps, but could you give us some examples of what you mean to provide a better sense of what you are thinking? Thanks! :-) If a library hasn't had a maintainer for a certain period then it gets removed. If I'm using a library that is close to being removed I'd either have to do something to help maintain it or decide to use another library. I'm OK with it becoming easier to add libraries if it also becomes easier to remove them. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 2

Policy when duplicate code detected
by Ioannis Papadopoulos 24 Nov '11

24 Nov '11

Hi, I was wondering what is the policy when someone finds code that is clearly duplicated or implements the same thing with just different interface? What is the best way to report it? Thanks

2 1

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

Lorenzo Caminiti: >On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> >> So I'm more of the view that we let stuff into boost as long at it meets >> quality standards. ?Then let users decide. > > +1 I guess, but is there any way to remove libraries from Boost? I think it almost needs pruning more than it needs more libs. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] [Boost.Local] Review
by Brent Spillner 24 Nov '11

24 Nov '11

On 23 Nov 2011 10:24:53 Leo Goodstadt wrote: >For "acknowledgment" / "acknowledgement": both spellings started out in the >16th c. but the first form historically was found more in the US. Citations >from the 19th and 20th c show that both variants are found on both sides >of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) >though the long form seems to predominate in the 20c only in U.K. >newspapers. I too appreciate the clarification--- guess I didn't understand this quite as well as I thought. In the US, "acknowledgement" does seem to correlate frequently with a casual attitude toward spelling, but it looks like I need to broaden my horizons a bit.

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 23 Nov '11

23 Nov '11

> > Ok, I am not sure if there are no better ways to write it in each variant, > > and I may be biased. I also didn't try to compile the examples. But it > > should give the potential users an overview of options they have. > > Yep. This highlights the verbosity well: > for_each( vec.begin(), vec.end(), if_(empty(_1)) [_1 = "n/a"] ); > vs: > BOOST_CLOSURE_PARAMS( std::string & n ) { > if( n.empty() ) n = "n/a"; > }BOOST_CLOSURE_NAME(replace_empties); > for_each( vec.begin(), vec.end(), replace_empties ); Honestly, my goal was to show an example where Phoenix has limitations and Local could be considered an attractive alternative. Obviously my example failed to do that. I wanted to see how you can call member functions. I can see Phoenix has nice support for container-like operations. But how about changing the rules a bit, and calling an arbitrary member function? for_each( vec.begin(), vec.end(), if_(bind(&SuperLib::SuperString::IsVulgar, arg1)) [arg1 = "unknown" ] ); vs. BOOST_CLOSURE_PARAMS( SuperLib::SuperString & n ) { if( n.isVulgar() ) n = "unknown"; }BOOST_CLOSURE_NAME(replace_vulgar); for_each( vec.begin(), vec.end(), replace_vulgar ); I realize that one can tweak examples to show whatever one wants. But member access does not appear too unusual. This really happened to me that I used a very complicated bind statement where I had to bind some variables and leave some free, pass some by reference, some by value. I thought "it was the right way because this is Boost way", until I realized no-one else in the team knows what that is suppose to mean. Regards, &rzej

2 1

[parameter] increase BOOST_PARAMETER_MAX_ARITY
by Tim Blechmann 23 Nov '11

23 Nov '11

hi, i've been using boost.parameter extensively with boost.heap and now came to a point, that i need to raise BOOST_PARAMETER_MAX_ARITY to at least 7 in order to be able to compile it. i am planning to merge boost.heap into trunk in the next few days, so i wonder, would it be reasonable to increase the default of this value to e.g. 8 (patch attached)? currently, boost.heap defines BOOST_PARAMETER_MAX_ARITY before including boost/parameter.hpp, but this will break, if boost/parameter.hpp is included before the boost.heap headers. it would be great, if the default would be high enough to compile all boost libraries, or could this cause any issues? thanks, tim

1 0

[local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)
by Lorenzo Caminiti 23 Nov '11

23 Nov '11

Note: I've changed the title of the email because this part of the discussion is not related to Boost for C++11 or C++03. On Wed, Nov 23, 2011 at 6:21 AM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 11/23/2011 5:53 PM, Lorenzo Caminiti wrote: >>> we should do is push the C++ compiler writers to give us library writers >>> > more power to address the problems such as the often cited deluge of >>> > undecipherable error messages. TMP libraries are ubiquitous in modern C++. >>> > Avoiding them because of the problem of error messages is backwards thinking. >>> > What we should do instead is to find better solutions, not hide the problems. >>> > >>> > This is Boost! > >> How is a library like Boost.Algorithm pushing the limit? It's a very > > How did you arrive at that? I said: > > "what we should do is push the C++ compiler writers to give us library > writers more power to address the problems such as the often cited > deluge of undecipherable error messages." > > Please read that again. You've mixed that with what I said earlier: > > "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." > > I never said that all libraries in Boost push the limits of C++. I see, yes that is what you wrote for example here "what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages". I miss read your email, I didn't understand that it was pushing the limits of compilers to give library programmers more control over error detection/reporting. Thanks for the clarification. > All the rest of your reply is irrelevant. Well, no. The following part of my reply is now even more relevant because it repeats that Local is not just about (2) better error messages (your point above about pushing the limit) but also about (1) usual statement syntax for the function body (which every programmer in your team will understand at once). >> the 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... > > Nope, not just a good workaround for error-messages. Proponents of > Locals mentioned two (2) main things as advantages. Please let's cite > both of them correctly: > 1) Use statement syntax for function definition. > 2) Compiler error retain their usual meaning for the function definition. > While these two things are related from an library implementation > prospective, they are two different advantages for the library > end-user. > > The politically correct sentence fro the docs: "[Local functions] can > be defined using C++ statement syntax plus eventual compiler errors > follow the usual format of C++ statement errors". > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… --Lorenzo

1 0

Re: [boost] [Boost.Local] Review
by Leo Goodstadt 23 Nov '11

23 Nov '11

> John Bytheway <jbytheway+boost <at> gmail.com> writes: > > > > On 19/11/11 20:39, Brent Spillner wrote: > > > On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: > > >>> The title is spelt wrong (should be Acknowledgements) > > > Actually, "Acknowledgments" is the traditionally correct spelling. > > > There are some dictionaries that accept "Acknowledgement," but this > > > reads as faddish and less literate. A similar word is "judgment"--- > > > both are frequently misspelled even by native speakers. > > BTW, I grew up spelling both as "acknowledgement" and "judgement". Online > sources seem to indicate that in Britain those spellings are the norm while in > the US the 'e' after 'g' is usually dropped. But I was born and raised here in > the US so what gives? Given that my first name is "Geoff" (English spelling) and > not "Jeff" (American spelling) the confusion is readily apparent? This is where the Oxford English Dictionary with all its historical citations comes in handy. For "acknowledgment" / "acknowledgement": both spellings started out in the 16th c. but the first form historically was found more in the US. Citations from the 19th and 20th c show that both variants are found on both sides of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) though the long form seems to predominate in the 20c only in U.K. newspapers. For "judgement" / "judgment": judgement seems slightly more consistent etymologically (with the Old French/Norman "iugement"?). This may be why it seems to be preferred by the OED. However, both forms are equally old, and >80% of the modern citations have the *short* form not the long form, on both sides of the Atlantic. Conclusion: Spell these words however you want! Hope that clears thing up. Leo

3 2

[local] Review
by John Bytheway 23 Nov '11

23 Nov '11

To begin with, my overall opinion: I say yes, Boost.Local should be accepted. > - What is your evaluation of the design? The design is clearly well thought-out. I admire Lorenzo's dedication to discussing his design decisions as thoroughly as possible on the mailing list. I've watched the development of the library with interest, and have been glad of the opportunity to comment along the way. On one specific pleasant surprise: thank you for providing the inline feature to offer your users the chance to choose their optimization trade-offs for themselves, and I'm glad you found a faster alternative to the virtual function trick. However, I still have a few concerns: I question the choice to bind const variables by const value by default, with (as far as I can see) no means to bind them by non-const value. This runs contrary to my instincts in regard to functions in C++ more generally (although I see C++11 lambdas have similar behaviour...). It's not a serious problem, but I would have chosen differently. On binding this: I vote that this_ is a better name than _this. The name is not a placeholder in the sense the term is used in libraries using the leading underscore convention for placeholders. Also, how do your various choices of syntax behave in the context of nested local functions? Consider: void BOOST_LOCAL_FUNCTION_PARAMS(bind this) { void BOOST_LOCAL_FUNCTION_PARAMS(bind this_) { this_->f(); } BOOST_LOCAL_FUNCTION_NAME(g) } BOOST_LOCAL_FUNCTION_NAME(h) If you change the syntax (as I think you were proposing) so that "this_" appears in the first line here in place of "this", then how would the second line behave? I would want it to bind the this pointer for the outer object, not the inner instance of the class that Boost.Local defines for me. You discuss exception specifications for the various objects that can be defined. If this includes noexcept in C++11 (which I imagine it does) then you should mention that. The ability to write noexcept local blocks (which can easily be made to work in C++03 too) might be another motivating feature for local blocks. Furthermore, you should seriously consider whether BOOST_LOCAL_EXIT's function should be declared noexcept by default where possible, since it is in many ways like a destructor. How feasible would it be to allow overload to be used without declaring all the function types. So, your example: boost::local::function::overload< void (const std::string&) , void (const double&) // Overload 1st param type. , void (const double&, const char*) // Overload giving default param. , int (int, int) // Overload giving 2 params (from function pointer). > print(print_string, print_double, print_double, print_add); might be written instead: auto print = make_overload(print_string, print_double, print_double, print_add); (with suitable use of BOOST_AUTO for C++03). I guess this only works if all the functors passed are monomorphic and expose (or could be made to expose) their argument types, but that covers function pointers, boost::function objects, and Boost.Local functions, which is a fairly wide applicability. Writing the above inspires me to ask: Do Boost.Local functions expose their argument types and return types at compile time? If there is a widely accepted way for monomorphic functors to do so, then they should. If there is no such widely accepted way, then one should be created, but that's probably not a job for you right now :). In a similar vein, as I was pondering potential uses of the overload feature, I wondered whether it could be used to write a visitor for Boost.Variant. I suspect that it could not, because such a visitor must declare its return type in a manner tat the overload object will not. It would be nice if that could be made to work. Can you think of a good way? > - What is your evaluation of the implementation? I have not looked at the implementation, but I have followed the discussions and examined some earlier versions of it. Any problems I noted before have, I think, as far as reasonable, been resolved. However, I would like to ask: on the overloading features: It looks like boost::local::function::overload could be written with variadic templates where available and thereby avoid the maximum arities in the configuration macros (and be much simpler and faster to compile). Have you done so? > - What is your evaluation of the documentation? The documentation is very good. Allow me to praise in particular the detailed rationales. A few niggles: * General You have various examples which write to stdout. I realise it's fairly clear, but it might be nice to drive the point home by explicitly showing what the expected output of these programs is. Alternatively, use asserts instead of writing to stdout. * Introduction "the object this can be bound (eventually by constant value" - I don't understand "eventually". * Tutorial The code "if (size && nums) delete[] nums;" perpetuates the myth that one should not delete NULL pointers. Please don't do that. Go ahead and delete[] nums even if it's NULL. "The maximum number of parameters that can be passed to a local function (excluding eventual bound variables)" - I don't understand "eventual". You have the "Important" warning about registering types with Boost.Typeof. I presume this applies only to compilers without typeof support. If so you should probably make this a little more clear. * Advanced Topics Does the existence of the recursive "keyword" mean that a local function cannot be named recursive? If so, you should mention that in passing. "Compilers have not been observed to be able to inline recursive local function calls (not even when the recursive local function is also declared inlined)." - do you mean "not only when"? "C++03 local classes cannot be templates." - this is also true in C++11, right? * Macro BOOST_LOCAL_FUNCTION_NAME "The local function name can be prefixed by the "keyword" inline to declare the local function inlined or by the "keyword" recursive to declare the local function recursive" - can both "keywords" be used? This wording suggests to me that they cannot. If they can, then I suggest changing "or" to "and/or". If not, this should be made clearer. * Macro BOOST_IDENTITY_TYPE I don't understand the "Warning" at the bottom; can you expand? * Macro BOOST_IDENTITY_VALUE The implementation provided on this page doesn't look like it could possibly work. Surely the type T cannot be deduced in a call to identity_value without template arguments? * Examples Should a chunk of the variadic macro version of the Emulating D's Scope Guards" example be commented out? Surely not... * Appendix: Alternatives In the benchmarking note, you say "For all tested compilers, this function pointer prevents the compiler optimization algorithms from inlining the local function calls.". You might want to mention that it is in theory possible for the compiler to inline it, and some other compilers or future versions may do so. (Or you may not, if you think it sounds too weasely or hypothetical) I don't see any of the benchmarking images. Should I? I'm experiencing some very odd symptoms from my graphics card since I first tried to view them, so it may well be a problem at my end. * Release Notes Why is there a "TODO" at the bottom? * Acknowledgments The title is spelt wrong (should be Acknowledgements) Thanks for the thanks :). > - What is your evaluation of the potential usefulness of the > library? Personally, my C++ development has mostly moved to C++11, and I do not expect to have reason to want this functionality, settling for lambdas instead. However, I might yet be in a situation where I am forced to use C++03, and I'm sure many others will be in just that situation for a while yet. In that context, I think this library has significant potential usefulness. Certainly there have been times when I have wanted something like it. Much as I admire Phoenix, I think there will always be circumstances where Boost.Local will be an easier, more useful and more readable alternative. As part of your struggle to motivate the utility of const binding in local blocks, you might want to mention in the documentation the possibility of using it to assure the behaviour of code received in macro parameters as (I imagine) you are doing in Boost.Contract. > - Did you try to use the library? With what compiler? Did you have > any problems? I did not try to use this version, but I have experimented briefly with previous versions, with gcc, clang, and icc (IIRC). I had no problems serious enough that I recall them. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I read the documentation with moderate care. Also, I have been following the development on the list over recent months. > - Are you knowledgeable about the problem domain? I have faced problems that this library would have solved neatly, and I discussed some implementation details with Lorenzo at times. > Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then > some) as Boost.ScopeExit. Does this duplication of functionality > need to be dealt with, and if so, how? Since I think the Boost.Local version is strictly superior to the Boost.ScopeExit version, I would suggest that the ScopeExit version be deprecated (but not removed, unless it is proving a significant maintenance burden). On the other hand, ScopeExit is a good name for that functionality, and so it is well worth seriously considering upgrading that library and not including the functionality in this new place. Should that be possible to achieve smoothly, it might be a better choice. > - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. Indeed it sounds reasonable to put it there. If so, it should be implemented with due regard for the possibilities of C++11 features (variadic macros, perfect forwarding) as mentioned above. > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. This seems reasonable. > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. I am struggling to see any situation where BOOST_IDENTITY_VALUE is necessary. Can you provide one? When will simply wrapping the expression in parentheses not suffice? Is it because you might be in a preprocessing context that requires an alphanumeric initial character? That's all for my review. Thanks to Lorenzo, Jeffrey, Gregory, and good luck! John Bytheway

2 2

[local] implementation using C++11 lambdas
by Lorenzo Caminiti 22 Nov '11

22 Nov '11

On Tue, Nov 22, 2011 at 3:32 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> wrote: > On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba < >> I think that there is a difference between Boost.Local and Boost.Move. >> Boost.Move provides an emulation of a C++11 feature on compilers that don't >> provides this feature. >> >> Boost.Local provides an emulation of a feature that has not been accepted >> to c++11. >> Note that I'm not saying that Boost.Local should not be accepted, but I'm >> sure that things will be different if Boost.Local provided an emulation for >> c++11 lambdas, that is, if in c++11 compilers the macros could be able to >> generate C++11 lambdas. >> > > Well, named lambdas are basically the same as local functions, no? What I > really mean is, Local provides an imperfect emulation of C++11 lambdas, but > by the same token, Boost.Move provides an imperfect emulation of rvalue > references. > > The question I have for the Boosters that don't like the local function >> approach is if they will accept as a good approximation of the following >> use of a lambda expression >> >> std::sort(x, x + N, [](float a, float b) {return std::abs(a) < >> std::abs(b); }); >> >> the storage on a temporary as in >> >> auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; >> std::sort(x, x + N, cmp); >> >> If Lorenzo would be able to define a macro that could be used to replace >> the named lambda as in >> >> BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < >> std::abs(b); })); Yes, this should be trivial but what would be its value? Note that on C++11 compilers the existing Boost.Local local function implementation has compile and run time performance comparable to the ones of C++11 lambdas: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… Therefore, why would you care if the local function is internally implemented using a C++11 lambda (macro above) or a local struct (macro below) given that there's no significant performance impact? bool BOOST_LOCAL_FUNCTION(float a, float b) { return std::abs(a) < std::abs(b); } BOOST_LOCAL_FUNCTIONS_END(cmp) (Also this has better error messages because the body is out of the macros so the compiler line numbers retain their usual meaning.) In summary, the current Boost.Local implementation already performs as well as C++11 lambdas on C++11 compilers and it also works on C++03 compilers. Therefore the current Boost.Local implementation already allows you to portably program named lambdas (but not lambdas because local functions cannot be defined within expressions) at no performance cost with respect to C++11 lambdas. >> std::sort(x, x + N, cmp); >> >> could you consider that this is promoting good usage of C++11 features on >> compilers that don't provide them and be a good candidate for a Boost >> library? >> > > This is drifting away from my intended thread topic a little bit. But, > nonetheless... Isn't this latter syntax trivial to implement with the > present macros provided by Local? And, as an aside, the significant Yes, it should be trivial. > disadvantage to the above versus splitting the declaration over 2 macro > instantiations is that compiler error messages from the body of the > function would be less informative (essentially missing line numbers). Oh, Yes, all compiler errors would have the same line number (significantly) reducing their informative value. > and I don't know if you can reliably do your BOOST_AUTO_LAMBDA syntax > without variadic macros. That said...it may be convenient to provide > something like that the BOOST_AUTO_LAMBDA macro for simple and small named > lambdas with no unparenthesized commas. HTH, --Lorenzo

1 0

Boost libraries for 'TR2'
by Vicente J. Botet Escriba 22 Nov '11

22 Nov '11

Hi, just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? Who is working on a concrete proposal? Which libraries would you like to be proposed? I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant. Best, Vicente

7 11

Re: [boost] [Boost.Local] Review
by Brent Spillner 22 Nov '11

22 Nov '11

On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: >> "the object this can be bound (eventually by constant value" - I don't >> understand "eventually". > > It means that you can either "bind this" or "const bind this" (the > second binds the object as constant within the local functions even if > the object is non-const in the enclosing member function). I will make > this text more clear. The issue (both places) is the word "eventually." This is a false cognate with Spanish, Dutch, and probably other languages; in English, "eventually" means only "shall happen at some time in the future." In the rewrite, you probably want to use "optionally" or "possibly" instead. >> * Acknowledgments >> >> The title is spelt wrong (should be Acknowledgements) > > OK. Actually, "Acknowledgments" is the traditionally correct spelling. There are some dictionaries that accept "Acknowledgement," but this reads as faddish and less literate. A similar word is "judgment"--- both are frequently misspelled even by native speakers. Isn't English fun?

5 4

Ok to add new folder?
by Antony Polukhin 22 Nov '11

22 Nov '11

There is already a folder trunk/libs/conversion where lies Boost.Lexical_cast tests. I`d love to split lexical_cast.hpp onto multiple files (old deprecated version, modern version, common headers for two versions...) and put those files into trunk/boost/conversion. Ok to add folder trunk/boost/conversion ? Best regards, Antony Polukhin

2 1

[functional] [variant] Hash patch for variant
by Antony Polukhin 22 Nov '11

22 Nov '11

Header and tests in attachments. Passes tests on GCC-4.4 and VC10. OK to commit to trunk and include header file from boost/functional/hash/extensions.hpp ? Best regards, Antony Polukhin

2 3

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 22 Nov '11

22 Nov '11

> boost::optional can be used for many purposes. One of these (and I had to > use optional like that) is to make classes that provide RAII-like interface > (noncopyable, nonmoveable) usable in contexts where I need to use two-phase > initialization or to release the resource before the end of the scope > (subject to some runtime condition) -- all that in order to have a resource > acquired for as short span of time as possible. > I would be forced to do that for std::lock_guard if the library did not > provide a second template std::unique_lock. But not every library provides > two interfaces for almost the same thing, and this is arguably an > unnecessary redundancy for an interface. optional<RAII> as described above > is a generic tool for transforming types that implement 'scoped ownership' > into types that implement 'unique ownership' of a resource. I think I went too far with this story. Although you can implement a two-phase initialization and cleanup, you cannot provide a full 'unique ownership' semantics with boost::optional for 'scoped' types, because there is no way to implement a move constructor for types that do not support either a move constructor or swap. Regards, &rzej

1 0

[local] Review
by Thomas Heller 22 Nov '11

22 Nov '11

Hi all, Following is my Review of the upcoming Boost.Local library. I will as others split my review into the three parts that make up this library: local functions, local blocks, scoped exit. Let me first start with some general comments. I personally find the decision to support two syntaxes not a good path to follow. While I understand the rationale behind it, and the desire to have the variadic macro version, having both might become a maintenance nightmare. Also, reading through the documentation, most of the time is spent on explaining, the difference between the two syntaxes. Why not just stick with one and concentrate on the functionality? Additionally, despite the introductory motivating statement ("Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts.") I can not see that this library solves this appropriately. I personally think that exposing macros as the interface to program with the library does not lead to a nice and clean design of ones code. Boost.Local is very different from other heavily macro based libraries like Boost.Parameter. It is different, because I would consider Boost.Local not as a infrastructure library but as a library for end users. This being said, i would not like to see application code cluttered with overly verbose calls to macros. As boost is trying to not only push the boundaries of C++ it should also try to set examples of best C++ practice. I would not consider Macro calls to interface with a library not good practice. Local Functions: From the tutorial section on Local Functions: "Local functions are defined using the following macros (see the Reference section) from within a declarative context (this is a limitation with respect to C++11 lambda functions which can instead be declared within expressions):" Right, to have the lambdas in a "declarative context" use auto f = [...](...){...} The default parameter syntax is confusing, it looks like it is a completely new parameter, and not belonging to the previous argument. This gets confusing once you have more than one parameter with a default parameter. The WITH_DEFAULT macro should be the default, as it clearly states the relationship of the default value to the parameter. I would consider binding variables from the enclosing scope one of the major weak points of Boost.Local. The need to binding those variables is obvious. However, how it is done clutters the arguments list of the BOOST_LOCAL_FUNCTION_PARAMS to an extend that it is not immediately clear what the arity of the local function is. It would make things clearer to have something like: BOOST_LOCAL_FUNCTION_PARAMS(...) BOOST_LOCAL_FUNCTION_CAPTURE(...) Additionally as binding is probably the right term to use here, it might confuse people with the already existing solutions of the various bind implementations. WRT to your note in the documentation that C++11 can not bind const reference. I suggest the following workaround: int i = 0; auto f = [&](){ auto const & icr = i; ... }; I agree that this and _this should be used always, instead of having both _this and this. On other notes, Lorenzo already clarified the defect in the library that it can't really be used as a closure. This would have been my next point. All in all the documentation is very accurate and in good shape. Additionally i played around with this specific part of the library a little bit in order to see how i can break it. TBH, I didn't (and still don't) trust the macros to do the right thing always, my knowledge of the PP isn't good enough to judge that particular part of the implementation. However, by deliberately trying to break the breaks (putting typos in the variables, omitting commas etc.) the error messages are of course very arcane, and you have to know exactly where and what part of the macros involved failed and why. Of course, these error message can be deciphered very easily once you have enough experience with that library. But i would argue that this is the case for any other (TMP based) library. Which brings me to my next point. I think that Boost.Local does not fulfill its own purpose. While it is of course true that errors in the function bodies are written in "usual C++" the surrounding macros are, IMHO, just cluttering the code. The points Lorenzo makes in the motivational section are not met. I would argue that most of the times, namespaces and classes are good enough, and such a macro syntax should be avoided. For everything else, there already exist a couple of solutions (Boost.Bind, Boost.Lambda and Boost.Phoenix). I would like to see improvements in ease of use in these libraries instead of advertising a completely macro based solutions. Local Blocks: I can't see the value in that one. The example in the documentation doesn't help either, as those things are easily detected by any modern compiler, with the appropriate warning levels (ok, not in the assert case, but for other boolean contexts at least gcc does). Local Exit: Why do we need two libraries doing the exact same thing with neither of the adding any functionality. I suggest to improve ScopedExit instead. In the alternatives section, which version of Phoenix do you use? Now to the usual questions: > - What is your evaluation of the design? I think the design is not what can be considered Modern C++. However, in the context of what the author tried to achieve, he did a good job. > - What is your evaluation of the implementation? The implementation looks solid! > - What is your evaluation of the documentation? The documentation is very good! > - What is your evaluation of the potential usefulness of the library? The potential usefulness of the library is out of question, that is why C++11 now has lambdas, and libraries like Bind, Lambda and Phoenix exist. However, I do not believe that Local adds any value to the existing solution of the described problems. > - Did you try to use the library? With what compiler? Did you have > any problems? Yes. gcc 4.6.2. no problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? Reading of the documentation. Looking briefly at the implementation. > - Are you knowledgeable about the problem domain? Yes. I am the author of Phoenix V3. I vote to not include the library into boost. Regards, Thomas

8 42

Re: [boost] BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

> Hello, > > According to: > > http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… > > [Edge search] requires linear time in the number of edges outgoing from u. > > The purpose of the CSR format is to support highly efficient computation > with minimal memory requirements at the cost of mutability and additional > time in construction. Is there a reason, then, that the adjacencies are > stored unsorted within their vertex ranges? With minimal additional time > during construction, edge access could be reduced to logarithmic time in > the number of edges outgoing from u without sacrificing any functionality > elsewhere that I can determine. > > Can somebody explain this design decision to me? If there is no > explanation, does anybody have plans to adjust the representation? I would > probably be willing to contribute an adjusted representation if nobody else > has plans to do so. The edges from each vertex used to be sorted, but that was changed when linear-time graph construction was introduced. One problem is that the standard sorting routines cannot sort corresponding ranges of elements (such as edge targets and properties); also, sorting edges increases the time complexity of the graph construction algorithm. Note that the CSR constructors that do sorting, except for the in-place versions, apply stable sorts to the edges you input, so you could give it a sorted list of edges and then write a logarithmic-time search routine using out_edges(). -- Jeremiah Willcock Hi, Thanks for your response. I'm sorry to hear about the move away from sorted adjacencies. I'm not sure if this is open for discussion, but I'd like to offer my two cents. The construction cost (of sorting) is minimal, especially in sparse networks for which the compressed sparse row format is specifically targeted where it is essentially asymptotically constant-time unless the degree distribution is highly skewed. On the other hand, certain aspects of link prediction, subgraph counting, and any algorithm that requires neighbor set intersections will benefit greatly from the ordering. I actually rolled exactly the solution you suggested for my own needs. Thank you so much. Ryan Lichtenwalter

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Interesting. It looks like optional can be seen as a special container with > > the maximum size of 1, and then functions like clear() or empty() come as > > natural. On the other hand it can be seen as a pointer-like entity with > > value semantics, and then functions like reset() and literal nullptr come > > as natural. > > Ok, I have no strong preference between reset() or clear() for making the > optional empty. However, a explicit empty() member would be useful anyway. > class MyClass > { > optional< int > m_x; > public: > bool has_x() const { return !m_x.empty(); } > }; > With the current interface I should have written has_x() in a more obscure > way, like !!m_x or m_x.get_ptr() != NULL. > > I withdraw my suggestion to use nullptr. Function reset() would be a better > > choice. I also find reset() preferable to clear() because reset can be > > extended to accept parameters and the name does not become confusing; > > similarly to unique_ptr::reset(). > I think, providing the reset() member with construction semantic is not a good > idea because it would make imposible in-place default construction. There > should be another method that would handle construction. In another post I > suggested assign() but I'm happy if someone comes up with a better name. I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories. template< typename... Args > optional( tr2::in_place_t, Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) the first parameter is a /tag/, much like std::piecewise_construct for pairs. We use it like this: tr2::optional<W> { tr2::in_place, i, str, 1, &g }; The tag indicates that we request an 'in place' initialization of W with remaining arguments.Next functions are more natural: template< typename... Args > void initialize( Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) // for deferred initialization. void uninitialize() noexcept // so that it spells similar to 'initialize' bool is_initialized() const noexcept // as in boost Regards, &rzej

3 2

BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

Hello, According to: http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… [Edge search] requires linear time in the number of edges outgoing from u. The purpose of the CSR format is to support highly efficient computation with minimal memory requirements at the cost of mutability and additional time in construction. Is there a reason, then, that the adjacencies are stored unsorted within their vertex ranges? With minimal additional time during construction, edge access could be reduced to logarithmic time in the number of edges outgoing from u without sacrificing any functionality elsewhere that I can determine. Can somebody explain this design decision to me? If there is no explanation, does anybody have plans to adjust the representation? I would probably be willing to contribute an adjusted representation if nobody else has plans to do so. Thanks! Ryan Lichtenwalter

2 1

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Also, if someone likes the assignment-of-"none" syntax, in C++11 there will > > be a similar syntax available: > > std::tr2::optional<T> op = {}; > > op = {}; > Wouldn't that be confusing with creating a filled optional with the value > constructed with empty initialization list? If there is assignment-of-none > syntax, it should probably be more explicit, pretty much like the current > "none" keyword. I see your point. But note that this confusing syntax will still be available (and is available today on compilers that support the new initialization syntax) even if we have "none" keyword. This is just the new way of requesting value-initialization (default constructor). Personally, I have doubts about introducing entity "none". There would be too many ways of indicating the null-state for different types. You could look at nullptr as a special pointer with special value; but you could also think of it as a keyword for indicating null-state: a stet of not having any meaningful value. Pointers represent addresses: they can either represent a valid address or not-an-address. Now for optionals we will have none for not-a-value, even though it is almost the same concept. I was thinking also about null_value or nullval. But they appear even more confusing than an already familiar "none". I am not English speaker, so I cannot be positive about it, but does "none" fit logically into the context? Is "nothing" or "naught" more suitable, gramatically? Regards, &rzej

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > - What is your evaluation of the design? > The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. Lorenzo, given this comment by Greg, I do have one more suggestion for documentation (or did someone already say it?). Given the heated discussion of whether Boost.Bind, Boost.Lambda and Boost.Phoenix are sufficient to render Boost.Local unnecessary, perhaps it would be worth to provide a comparison of how my code (not too trivial, and not too complex) would look in either case. For instance: With C++11 lambdas: for_each( vec.begin(), vec.end(), []( std::string & n ){ if(n.empty()) n = "n/a";} ); With Boost.Lambda + Boost.Bind: for_each( vec.begin(), vec.end(), if_then(boost::bind(&std::string::empty, _1), _1 = "n/a") ); With Phoenix: using boost::phoenix::arg_names::arg1; using boost::phoenix::if_; using boost::phoenix::bind; // right? for_each( vec.begin(), vec.end(), if_(bind(&std::string::empty, arg1)) [ arg1 = "n/a" ] ); With Boost.Local (Boost.Closure): BOOST_CLOSURE_PARAMS( std::string & n ) { if( n.empty() ) n = "n/a"; }BOOST_CLOSURE_NAME(replace_empties); for_each( vec.begin(), vec.end(), replace_empties ); Ok, I am not sure if there are no better ways to write it in each variant, and I may be biased. I also didn't try to compile the examples. But it should give the potential users an overview of options they have. Regards, &rzej

4 4

Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 21 Nov '11

21 Nov '11

Hi, It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? No response to tickets from the past 3 years. What's the procedure in this case? https://svn.boost.org/trac/boost/ticket/2492 https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… Greetings, -- Olaf

1 3

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> Do you have any preference? > FUNCTION or CLOSURE? > And also a), b1), b2), c) or d)? > (Or something else...) Hi Lorenzo, Now that I have better understood your library, my personal preference goes towards "closure". The reason for that is: 1. "Closure" better reflects the nature of your library: you provide a tool for defining closures: something more than functions, and something less than lambda expressions. 2. This may make the learning of the library easier. If I know I am dealing with closures I already expect binding functionality; there will be less questions like "what is this 'bind' and what does it actually do?" 3. It may be a marketing bonus "closure" sounds (IMO) more attractive than "function". How about Boost.Closure library? "Local" may not even be necessary, because "closure" somehow implies locality. (you do not need a global closure, because global function will do). Regards, &rzej

3 6

Fw: [asio] multicast.
by John Maddock 21 Nov '11

21 Nov '11

Message forwarded from original sender: ~~~~~ Hi I am trying to join multicast group via _VPN_, this means that I cannot see listen-address in ipconfig actually Could I please me explain how should I connect in this case? I am using multicast-reciever sample. http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/example/multicast/… with port 9023, listen 172.20.200.42, multicast 239.192.112.3 #include <iostream> #include <string> #include <boost/asio.hpp> #include "boost/bind.hpp" const short multicast_port = 9023; class receiver { public: receiver(boost::asio::io_service& io_service, const boost::asio::ip::address& listen_address, const boost::asio::ip::address& multicast_address) : socket_(io_service) { try{ // Create the socket so that multiple may be bound to the same address. boost::asio::ip::udp::endpoint listen_endpoint( boost::asio::ip::address::from_string("0.0.0.0"), multicast_port); //boost::asio::ip::udp::endpoint listen_endpoint( // listen_address, multicast_port);//if I use listen_address instead of 0.0.0.0, there is an error in socket_.bind(listen_endpoint); socket_.open(listen_endpoint.protocol()); socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket_.bind(listen_endpoint); // Join the multicast group. socket_.set_option( boost::asio::ip::multicast::join_group(multicast_address)); socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } } void handle_receive_from(const boost::system::error_code& error, size_t bytes_recvd) { if (!error) { std::cout.write(data_, bytes_recvd); std::cout << std::endl; socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } } private: boost::asio::ip::udp::socket socket_; boost::asio::ip::udp::endpoint sender_endpoint_; enum { max_length = 1024 }; char data_[max_length]; }; int main(int argc, char* argv[]) { try { std::string list = "172.20.200.42"; std::string mt = "239.192.112.3"; boost::asio::io_service io_service; receiver r(io_service, boost::asio::ip::address::from_string(list), boost::asio::ip::address::from_string(mt)); io_service.run(); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; } //===================================== But with native c++ I can obtain data: #include <winsock2.h> #include <Ws2tcpip.h> #include <mswsock.h> #include <stdio.h> #include <stdlib.h> #include <iostream> using namespace std; #pragma comment(lib, "Ws2_32.lib") int main(){ WSAData data; WSAStartup( MAKEWORD( 2, 2 ), &data ); int sd = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); sockaddr_in Sender; int SenderAddrSize = sizeof( Sender ); struct sockaddr_in binda; char *arg1 = new char[100]; char *arg2 = new char[100]; char *arg3 = new char[100]; arg1 = "239.192.112.3"; arg2 = "172.20.200.42"; arg3 = "9023"; binda.sin_family = AF_INET; binda.sin_port = htons( atoi(arg3)); binda.sin_addr.s_addr = htonl(INADDR_ANY); bind(sd,(struct sockaddr*)&binda, sizeof(binda)); struct ip_mreq_source imr; imr.imr_multiaddr.s_addr = inet_addr(arg1); imr.imr_sourceaddr.s_addr = inet_addr(arg2); imr.imr_interface.s_addr = INADDR_ANY; setsockopt(sd, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, (char *) &imr, sizeof(imr)); char buf[65536]; while(1) { int res=recvfrom(sd,(char*)buf,sizeof(buf),0, (SOCKADDR *)& Sender, &SenderAddrSize); printf(buf); } //WORKS } //===================================== I cannot realize what is the difference in these two samples, Could you please tell me in which way should I use boost library to obtain data in this case? Thanks in advance, -- С уважением, Василий.

1 0

[local] Review (and resignation from review assistant)
by Gregory Crosswhite 21 Nov '11

21 Nov '11

Hey everyone, The discussion on the mailing list has caused me to realize that I have sufficient passion for the Local library that it is difficult for me to stay neutral, so I will be recusing myself from my position as Review Assistant for this library. (I have learned that should I decide to help out again in the future in this role for another review, I will make sure that it is for a library that I don't feel strongly about either way!) On the other hand, this means that there is no longer any reason not to post a review of this library. I have been a fan of this library for a long time because for me it solved the problem of having a nice way to write (pseudo-)closures in C++03 without having to write and maintain a lot of pointless boilerplate code, and without having to use a completely foreign syntax that I could never seem to get to work. Here is my review of it. > - What is your evaluation of the design? The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. It is also clear reading through the documentation that Lorenzo has put a great deal of thought into possible use cases of his library; there are a great number of features which most users might never need to use but which are available for those times when they are completely necessary --- such as explicitly providing types of bound parameters, and marking functions inline --- and they are provided in such a way that when they aren't needed they introduce no additional overhead to the syntax. > - What is your evaluation of the implementation? I am not familiar enough with preprocessor programming to be able to make a fully qualified statement on this. However, it looks reasonable based on the Implementation appendix. The virtual function call is a shame as, if I recall correctly, it can make Boost.Local slower than Boost.Phoenix when the compiler is not smart enough to optimize it into a direct call, but Lorenzo has put so much time and expertise into the design of this library that I doubt it is possible to improve on this while maintaining compatibility with C++03. For me this part of the overhead is not a big deal because I primarily have been using Boost.Local in test suites where the difference in performance does not matter. > - What is your evaluation of the documentation? The documentation is some of the best well written I have seen for a Boost library. It does a good job both explaining how the library works, providing a reference for remembering how the syntax works, and explaining why the library was designed the way that it does. As I have told Lorenzo in a separate e-mail, I do have a minor criticism of the Tutorial section: the ordering of the first four sections is probably not what typical user reading it the first time would want because it puts the most important and essential feature, variable binding, after two features, default and empty argument features, which are nice to have but are not likely to be needed in typical usage, especially considering that a first-time user is most likely just looking for a convenient way to create a simple (pseudo-)closure in C++03. Thus, I suggest the following ordering: "Local Functions" "Variable Binding" "Default Parameters" "Empty Parameters" This way a typical user, who will only care about writing a function that binds a few local variables, will be able to get started immediately after reading the second section rather than first having to wade through two sections describing features that they are unlikely to care about right away. The rationale for putting "Default Parameters" before "Empty Parameters" is that a typical user is very unlikely to need to know how to call the macro with no arguments because there are few use cases where a typical user won't want to bind *anything* from the local environment (since most of the time this means that they won't be thinking in terms of local functions in the first place), so they are less likely to care about how to do this than they are about how to specify default parameters. > - What is your evaluation of the potential usefulness of the library? This library is very useful for people who want to use much of the functionality of C++11 lambdas on C++03 compilers, as I can say from personal experience in using it. As I have said before, the existence of Boost.Bind, Boost.Lambda and Boost.Phoenix do not reduce the utility of this library. They do have a large advantage over Boost.Local of being succinct, which is why I often prefer them over Boost.Local when it is easy to do so. However, because they require to you learn completely new syntax for *all* of the code in the function body, and because they make use of heavy metatemplate programming that results in absolutely horrendous error message that do not give you a clue where they are wrong, for anything non-trivial Boost.Local is hands-down *far* easier to use because you can use plain C++ statement syntax which results in plain C++ error message when you get something wrong. Put another way, Boost.Bind, Boost.Lambda and Boost.Phoenix are complementary to rather than competitors of Boost.Local. > - Did you try to use the library? With what compiler? Did you have any > problems? I have used the library extensively in my own codes, though most often in test suites. I have used them on OSX with GCC 4.2, and on Linux with (if I recall correctly) GCC 4.3 and 4.4. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I have become accustomed to using the library on a regular basis and hence my evaluation is written based on my personal experience with it. > Please state clearly whether you think this library should be accepted as a Boost library. Definite yes. Cheers, Greg

2 1

[interprocess] Named types ( mutexes, semaphores etc.) and Windows 7
by Edward Diener 20 Nov '11

20 Nov '11

Under Windows 7 fior named types to be global, the name of the type needs to be prefixed by the string "Global\" Is this being done in the interprocess library for Windows 7 ?

2 1

[fusion] view gcc 4.6
by Karsten Ahnert 20 Nov '11

20 Nov '11

Hi, the following code does not compile with gcc 4.6.1: #include <boost/fusion/view.hpp> int main( int argc , char ** argv ) { return 0; } It produces errors like this: $> g++-4.6 -I$BOOST_ROOT test_fusion_view.cpp ... ... In file included from /home/karsten/boost/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:92:0, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:40, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/nview.hpp:105, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview.hpp:12, from /home/karsten/boost/boost_1_47_0/boost/fusion/view.hpp:13, from test_fusion_view.cpp:1: /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: warning: overflow in implicit constant conversion [-Woverflow] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: error: overflow in constant expression [-fpermissive] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: note: in template argument for type ‘int’ Any Ideas? I think the code should compile sincde fusion/view.hpp is a forwarding for the views...

4 6

Reminder! Boost.Local Review officially ends Saturday, Nov 19, 2011
by Jeffrey Lee Hellrung, Jr. 20 Nov '11

20 Nov '11

Just a friendly reminder that the ongoing Boost.Local review is officially set to end tomorrow (Saturday), Nov 19, 2011. Please let me know if you plan on reviewing the library but need more time, possibly into early next week, and I'll either formally extend the review period (subject to the Review Wizards' approval) or simply informally allow late submissions. Copied below is the original review announcement: ---------------- Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function:: overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

3 2

Review of Local Exits
by Alexander Nasonov 20 Nov '11

20 Nov '11

This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit. I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons: - Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development. - For the same reason, const bind& and bind& should be removed from the interface. Regards, Alex

3 4

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Use nullptr instead of boost::none? - this will make some uses of > > optional pointers harder, but will make usage more clear in other cases. > > I don't think nullptr is a good choice here because of the complications you > mentioned. Actually, I would prefer traditional clear() and empty() methods > for clearing and testing for value presence. The operator safe_bool() and > operator!() may also be present in the interface for brevity in conditional > expressions. Interesting. It looks like optional can be seen as a special container with the maximum size of 1, and then functions like clear() or empty() come as natural. On the other hand it can be seen as a pointer-like entity with value semantics, and then functions like reset() and literal nullptr come as natural. I withdraw my suggestion to use nullptr. Function reset() would be a better choice. I also find reset() preferable to clear() because reset can be extended to accept parameters and the name does not become confusing; similarly to unique_ptr::reset(). Also, if someone likes the assignment-of-"none" syntax, in C++11 there will be a similar syntax available: std::tr2::optional<T> op = {}; op = {}; Interestingly, boost::optional did have a reset function (now deprecated) which was replaced with boost::none assignment. I wonder what was the reason for this replacement. Regards, &rzej

2 2

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Conversion explicit conversion to bool should be declared as explicit. > > Doesn't an explicit conversion disallows to use it in a conditional > expression as in > if(opt) {} I believe that the primary motivation for the explicit conversion operators was to provide a simpler alternative for safe-bool idiom, and address cases like this one. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf > > * 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). > Provide the same exception guaranties as the T assignment seems the more > reasonable. My apologies, I wrote this in a hurry an didn't make myself clear. There are three cases to consider (leaving move assignment and no-throw copyable types aside): 1. Our stored type T provides a strong assignment - the choice is obvious: optional<T>'s assignment is also strong 2. T has "basic" assignment - the natural choice is to provide also a basic guarantee for optional<T>'s assignment. 3. T is neither copyable nor moveable -- it is like a scope guard, or boost::scoped_ptr. In this case optional<T> still provides assignment by making a "pseudo destructor call" followed by a call to placement new. -- but this gives only basic guarantee. The question is if for this third variant we should be happy with only basic guarantee or to use a trick boost::variant is using with auxiliary heap-allocated object? (I do not even know if this is applicable though). > > template< typename ... Args> > > optional( Args&& ...args ); > I like them. > > The constructor will clash with another optional constructor: > > optional<T>::optional( bool cond, const T& val ); > > I don't understand why. Currently boost::optional provides this constructor: optional<T>::optional( bool cond, const T& val ); If cond is true the optional is initialized with object val, otherwise it is uninitialized. Now suppose I have a following type: struct MyType { bool on; int m1; int m2; MyType( bool on, MyType const& rhs ) :on{on}, m1{rhs.m1}, m2{rhs.m2} {} }; MyType mt { true, 1, 2 }; boost::optional<MyType> o1{ true, mt }; // optional initialized with mt (copy ctor used) boost::optional<MyType> o2{ boost::in_place(true, mt) }; // uses 2-arg ctor But if std::tr2::optional has "variadic" constructor: std::tr2::optional<MyType> mt{ true, mt }; // uses 2-arg ctor Regards, &rzej

4 5

Boost 1.48.0 Release Notice
by Beman Dawes 19 Nov '11

19 Nov '11

Release 1.48.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains new libraries: Container, Locale, Move. Updated libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For details, including download links, see http://www.boost.org/users/news/version_1_48_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.48.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 5

[ScopeExit] C++0X support
by Alexander Nasonov 19 Nov '11

19 Nov '11

I committed lambda-based implementation of ScopeExit to trunk today. It should be backward compatible with the previous implementation. In addition, if you've fully switched to C++0x, you can use = and & from C++0x and use ; instead of BOOST_SCOPE_EXIT_END. For instance: BOOST_SCOPE_EXIT((&)) {}; Alex

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> This is more of an addition to your list, but I think adding > the | operator for getting the optional value or a default value would be nice. > For example: > optional<double> safe_sqrt(double x) > { > if (x < 0) return none; > else return sqrt(x); > } > double x = safe_sqrt(4) | 0; //x = 4 > double y = safe_sqrt(-1) | 0; //y = 0 > I dont know if this is possible for tr2, but would be really nice > addition in the future. Especially, since a lot of times i just > want a default value if the optional value doesn't exist. Note, that boost::optional already provides a functionality for that, although with a slightly more verbose syntax: double x = safe_sqrt(4).get_value_or(0); std::tr2::optional would also provide this functionality. If this is only about shorthand notation, this item would be controversial. bitwise-or is a better choice that logical-or but it might turn out too confusing and disturbing for programmers that do not want to learn what overloaded operators mean for every type they use. What I mean to say is that liberal use of overloaded operators is a general controversy. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> > 3. T is neither copyable nor moveable -- it is like a scope guard, or > > boost::scoped_ptr. In this case optional<T> still provides assignment by > > making a "pseudo destructor call" followed by a call to placement new. -- > > but this gives only basic guarantee. > The guarantee is strong if the placement delete/new are marked > noexcept, isn't it? What I meant by "a >>pseudo destructor call<< followed by a call to placement new." is a call to destructor w/o releasing the memory and then a call to constructor w/o allocating memory: ob.~T(); new (&ob) T( std::forward<Args>(args)... ); This trick will provide a strong guarantee if destructor and the constructor are nothrow. While destructors usually are non-throwing, it is rather unlikely that constructors would not throw: it is the constructors that we often expect to throw in case of initialization failure. Regards, &rzej

1 0

[inteprocess] Using named_mutex on Windows 7
by Edward Diener 19 Nov '11

19 Nov '11

I wrote a program more than 3 years ago where I used boost::interprocess_named_mutex to protect more than one instance of the same process from running the same sequence of code at the same time. The program appears to run fine under Windows XP and Windows Vista but occasionally locks up waiting for the locked mutex to unlock on Windows 7. The code looks like this: ------------------------------------------------------------------- boost::interprocess::named_mutex cmutex(boost::interprocess::open_or_create_t(),"MyMutexName"); { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> cscoped(cmutex); // Code here which must be run one at a time. } ------------------------------------------------------------------- Under Windows 7 the code occasionally hangs on the scoped_lock instantiation, which of course I can not have. I notice there is a file in the temporary directory ( TMP or TEMP environment variable ) which is being used by interprocess, and after that file is manually deleted, the program no longer hangs on the scoped_lock instantiation. Is there a reason for this problem on Windows 7 ? I know that Windows 7 has global and local named mutexes and only by prefacing a named mutex name with global\ is the mutex truly global. I do not know if this is causing the problem on Windows 7. It does seem as if something in the file in the temporary directory is telling inteprocess that "MyMutexName" is still locked when the hangup occurs, but I would have expected that when acoped_lock goes out of scope, it handles resetting that file to the correct state. I wonder if this has something to do with UAC/file permissions in Windows 7, where the process somehow can no longer write to the file in the temporary directory afte creating it. Is this a known interprocess problem, perhaps fixed in a later release ? I wrote my code before Windows 7 even came out, recompiled it for Windows 7, but did not update the version of Boost I was using for the program ( Boost 1.35 ). Maybe I need to do that ? I would certainly be willing to do that if I knew that this was a problem with interprocess in Boost 1.35 that has subsequently been fixed in a later version of Boost.

1 0

[signals] Compiler error
by "Claas H. Köhler" 18 Nov '11

18 Nov '11

Hi everybody! When compiling boost 1.48.0 using gcc-4.6 and the "--std=c+0x" option, I get the following error message: libs/signals/src/named_slot_map.cpp: In member function ‘void boost::signals::detail::named_slot_map::disconnect(const boost::signals::detail::stored_group&)’: libs/signals/src/named_slot_map.cpp:99:48: error: conversion from ‘std::list<boost::signals::detail::connection_slot_pair>::const_iterator {aka std::_List_const_iterator<boost::signals::detail::connection_slot_pair>}’ to non-scalar type ‘boost::signals::detail::slot_pair_iterator {aka std::_List_iterator<boost::signals::detail::connection_slot_pair>}’ requested The reason seems to be that std::map's erase function expects a std::map::iterator in the old standard (according to cplusplus.com) while c++11 seemingly requires a std::map::const_iterator as argument (see section 23.4.4.1). Thus replacing line 105 OLD groups.erase(group); NEW groups.erase( static_cast<const_group_iterator>(group) ); and line 128 OLD if (empty(g)) groups.erase(g++); NEW if (empty(g)) groups.erase( static_cast<const_group_iterator>(g++); solves the problem for me. Is it intended to have all boost libraries conforming with C++11? Regards Claas

1 0

date_time using CPU performance counter
by Kenneth Porter 18 Nov '11

18 Nov '11

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch). Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

3 3

multi_array and concept check
by Ivan Sorokin 17 Nov '11

17 Nov '11

Hello! Currently it is not possible to pass shape() of one multi_array into constuctor of another: boost::multi_array<float, 2> a; boost::multi_array<float, 2> b(a.shape()); This is because shape() returns size_t const* and multi_array check in constructor that ExtendList satisfy CollectionConcept. size_t const* don't satisfy this concept. I'm going to allow constructor of multi_array to get both size_t const* and size_t const[]. So I'm going to replace extents.begin() with boost::begin(extents). What should I do with concept check?

1 0

Boost.Local Review
by Pierre Morcello 17 Nov '11

17 Nov '11

Hello Boost community, Here is my review of the local function library. - What is your evaluation of the design? The design is clear. Several iterations were done already to come to what it is today. Of course no one is particularly fond of macros, but a huge work was done to reduce the potential problems and on the other hand the library can really help a lot. - What is your evaluation of the implementation? I did not get too much into the current implementation. I dug it almost one year ago, but there were changes since then. The implementation is correct given the features of the library (use of 'this', functor,, name,...). If there were less features, then some optimisations would have been possible (example : not use a virtual function, not use a functor). But the library would in that case have fewer cases of use. I know how the first verion of Lorenzo worked but I did not check the latest. Given the current features, I don't see how to do even better than what Lorenzo did. So I am happy with the implementation. - What is your evaluation of the documentation? I really appreciate the detailled documentation. On a 'merchandising note', the first page is too big. I think this could 'afraid' some new readers. Introduction + an 8-line motivating example should be enough to appeal (or not) the new reader. I am happy to review a submitted library with a complete documentation (that does not always happen). - What is your evaluation of the potential usefulness of the library? This library is filling a few strong needs. Several users including myself needed local function and const block. I am lazy when it comes to functors, I also find this library is pretty nice to make them quick. C++11 will on that last part change it , but const block are a must have in my opinion which are not available in C++11. The local function can greatly reduce the presence of internal functions in ".h", and thus make the interfaces much better in some cases. - Did you try to use the library? With what compiler? Did you have any problems? I use regularly this library on VC9, but mostly for local function. As I don't try to push the limits, I did not come into problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have followed Lorenzo work since his proposition. At the beginning I followed it much more closely, but right now I dont' have the time to redo an in depth study. I use a previous version of Lorenzo library regularly. So for the review, I simply had a glance. But I already read the documentation in detail several month ago. - Are you knowledgeable about the problem domain? I implemented a my own version of local functions for boost almost 2 years ago I think. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? I think it's important to check if the author are ok with merging or not. Obviously Lorenzo is very motivated and gives great feedback on his works with boost. Just make sure this won't hurt his motivation ? Because then there are the question of maintening the libraries which is not always the easiest. I am ok if one replace the other. - Do you vote for the library? Yes, I vote for its admission. I also want to add that I am amazed by the overall results in term of quality that Lorenzo was able to get with this library. Lorenzo is constently gathering the users needs and updating his library in that way. Like a marathonian. Very inspiring! Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Local-Review-tp4078276p4078276.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[context] update
by Oliver Kowalke 17 Nov '11

17 Nov '11

Hi, a new updated version is available. src: http://github.com/olk/boost.context docu: http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html next step mini-review? so long, Oliver

1 0

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 17 Nov '11

17 Nov '11

Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function::overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

7 21

Alternative implementation for BOOST_PP_VARIADIC_SIZE
by Gennadiy Rozental 17 Nov '11

17 Nov '11

Hi, Current implementation of subject macro have a very serious shortcoming - it does not work for empty __VA_ARGS__. After googling around a bit for some ideas I came up with the following alternative: #include <boost/preprocessor/arithmetic/mul.hpp> #include <boost/preprocessor/arithmetic/sub.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #define MY_VA_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63, N, ...) N #define MY_VA_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 #define MY_DO_VA_NARG2(...) MY_VA_ARG_N __VA_ARGS__ #define MY_DO_VA_NARG(...) MY_DO_VA_NARG2(( __VA_ARGS__ )) // this version produces incorrect value (1) for empty __VA_ARGS__ #define MY_VA_NARG_(...) MY_DO_VA_NARG(__VA_ARGS__, MY_VA_RSEQ_N()) // this version fixes it #define MY_VA_NARG(...) BOOST_PP_SUB( BOOST_PP_MUL( MY_VA_NARG_( __VA_ARGS__ ), 2 ), MY_VA_NARG_( BOOST_PP_COMMA __VA_ARGS__ () ) ) This version work for zero sized __VA_ARGS__ and also works for MSVC-9,10 , gcc-4.1 gcc 3.2 (did not test with other compilers). Does it make sense to improve trunk version? Regards, Gennadiy

7 39

[1.48.0] Can't build any PDF docs
by John Maddock 16 Nov '11

16 Nov '11

I'm trying to build the PDF docs for 1.48 but all attempts to build PDF's on both Trunk and release branches fails with errors such as: bjam pdf M:/data/boost/trunk/tools/build/v2/tools\boostbook.jam:649: in object(boostbook-generator)(a)49.run from module object(boostbook-generator)@49 error: Cannot build documentation type 'pdf' M:/data/boost/trunk/tools/build/v2/build\generators.jam:1004: in try-one-generator-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1066: in try-one-generator from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1282: in construct-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1366: in generators.construct from module generators M:/data/boost/trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:1297: in object(typed-target)(a)776.generate from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)782.generate from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)772.generate from module object(project-target)@772 M:/data/boost/trunk/tools/build/v2\build-system.jam:736: in load from module build-system M:\data\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules M:\data\boost\trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module M:\data\boost\trunk\boost-build.jam:17: in module scope from module Nothing has changed in my user-config.jam, and I've updated to the latest bjam executable. Any ideas on what broke? Thanks, John.

2 3

Boost.Random.uniform_01 gives different number sequence in Boost 1.37 and Boost 1.45
by Martin.Sovik＠Emerson.com 16 Nov '11

16 Nov '11

Hi. It seems that uniform_01 generates different number sequences in version 1.37 and 1.45 Is this intentional, or is it a bug? This short program #include <iostream> #include "boost/random/mersenne_twister.hpp" #include "boost/random/uniform_01.hpp" int main() { boost::mt19937 random_generator(4315); boost::uniform_01< boost::mt19937, double > uniform_generator(random_generator); std::cout<<"Generating uniform distribution using Boost 1.45"<<std::endl; for (int i=0; i<10;++i) { std::cout<<uniform_generator()<<std::endl; } return 0; } Compiled with the two versions, gives the respective output: D:\dev\test_bed>uniform_dist_boost_1_37 Generating uniform distribution using Boost 1.37 0.239136 0.920749 0.889477 0.208172 0.169688 0.636659 0.78322 0.915117 0.25697 0.358218 D:\dev\\test_bed>uniform_dist_boost_1_45 Generating uniform distribution using Boost 1.45 0.306389 0.511291 0.496429 0.156168 0.910315 0.644836 0.331514 0.558632 0.723934 0.998796 As far as I can tell, Boost.mt19937 gives the same number sequence in both cases, but the output from Boost.uniform_01 differs. This topic has been briefly touched in the thread [boost] Random numbers question<154235.php> Anant Rao (2009-07-24 18:47:31) Where it seems like Rao got different numbers even between Boost 1.38 and Boost 1.39 We use Boost 1.37 in the previous release of our software, and Boost 1.45 in the current, and we have received a bug report from one of our clients that our current release has different behaviour. Is there any way to fix this, other than use the 1.37 version of Boost.uniform_01? Thanks, Martin Søvik

2 1

Re: [boost] [1.48.0] Release candidates available
by Tom Kent 16 Nov '11

16 Nov '11

> Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ > > md5sum on the originals: > > 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z > d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 > 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz > b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip > > 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 On a windows 7 - 32 bit VM, I built: msvc-8.0 msvc-8.0 - address-model=64 msvc-9.0 msvc-9.0 - address-model=64 msvc-10.0 msvc-10.0 - address-model=64 All builds were successful. I was able to smoothly link and run with the binaries on windows 7 32 or 64 (depending on the library build). Tom Kent

1 0

[program_options] Improving error text in exceptions
by Leo Goodstadt 16 Nov '11

16 Nov '11

On 15 November 2011 09:08, Vladimir Prus <vladimir(a)codesourcery.com wrote: > > Leo Goodstadt wrote: > > I would very much like to make the error messages in program_options > > exceptions more consistent and informative. > > I've looked over the error messages you have proposed, and I think it's > an overall improvement. I would appreciate patch to make this change. > Thanks! Cool. Will do that. The error messages meant for programmers I shall leave alone. This exercise is so tedious that I doubt anyone else is going to do more than tinker with the message text so I am keen to do an exhaustive job. As I mentioned, for command line messages, <option '--foo_bar' is ambiguous> seems much clearer than than <option 'foo_bar' is ambiguous>. However, it would be inappropriate to add "--" to config file and dos style options. The easiest thing would be to add a "prefix" parameter to the set_option_name() functions in errors.hpp These are called inside store() in variables_map.cpp. To add "--" or "/" prefixes as appropriate, is it sufficient to look at basic_option::original_tokens and basic_option::string_key? A) Use no prefix if original_tokens[0] is unprefixed, B) Use the parsed prefix (original_tokens[0]) if basic_option::string_key.length() = 1 C) Prefer "--" for long option names The same logic would apply to 1) exceptions thrown from cmdline::finish_option() in cmdline.cpp 2) options_description::find() (in options_description.cpp) called from store() (in variables_map.cpp) 3) options_description::find_nothrow() (in options_description.cpp) called from cmdline::run(), cmdline::finish_option(), parse_short_option(), and parse_disguised_long_option() (in cmdline.cpp) (Despite its name, find_nothrow() can throw()!) The difficult case is supporting the correct prefix for "required_option" in variables_map::notify() (variables_map.cpp). I propose that where missing options can be specified in both configuration file and on the command line, the command line should take precedence, and "--option_name" displayed in the error message. To support this, "basic_parsed_options" needs an extra prefix field, which would be set appropriately by basic_command_line_parser<charT>::run(). Does this make sense? Thanks, Leo -- Leo Goodstadt University of Oxford, UK

2 1

[1.48.0] Release candidates available
by Beman Dawes 16 Nov '11

16 Nov '11

Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ md5sum on the originals: 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip 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

13 17

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

> > One suggestion for the future, although I am not sure how useful it would > > turn out in practice is to have something like local expression, or even > > not necessarily a local one. This would be a function whose body consists > > of a single expression. The benefit you get is that the programmer does not > > need to specify a return type for it (you can use BOOST_TYPEOF for that), > > or doesn't even have to type keyword 'return', but this may be too much off > > topic. > Can you clarify with an example? In C++11 lambdas do not require specifying the return type, provided that the body of the function is a single return statement: because it is easy to deduce the type from such single return statement. Similarly, for Boost.Local if a function body consists of a single return statement you could (I guess) provide a more simple syntax. Instead of BOOST_TYPEOF(sum) & BOOST_LOCAL_FUNCTION_PARAMS( double num, const bind factor, bind& sum ) { return sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add); I could write: BOOST_LOCAL_EXPRESSION_PARAMS( double num, const bind factor, bind& sum ) BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num ); You save me typing the return type and 'return' keyword. But now that I have written it down I do not think it is particularly useful. > I think in a nutshell the conclusion (which I will detail in the rest > of my comments below) was that Boost.Local is handy but on compilers > with C++11 lambdas you'd just use lambdas. At the same time, > Boost.Local allows you to write local functions that work also on > C++03 compilers and that have the same compile-time and run-time > performances of lambdas on C++11 compilers. So the /main/ audience > would be someone (like myself) that wants to do local function stuff > and expects lambda-like performances on C++11 but also has to deal > with C++03 compilers. There are other benefits like const& binding > which is not supported by C++11 lambdas (so how can I bind by const a > variable that has a very expensive copy constructor using C++11 > lambdas?) and improve scope exit (i.e., local exit) but these other > benefits are probably minor in the general domain (they can be very > important or even essential is a specific and narrow domain like > Contract Programming but not critical in the general case). OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will add a motivation section in the documentation which will stress that the primary motivation of the library is to provide a uniform (in terms of syntax) support for local functions: fast and 'native' for C++11 compilers, and acceptable (using tricks) in older compilers. The library can be used directly or be a foundation for higher level libraries like Boost.Concept. Review Managers, I am not really trading, I vote YES for the Boost.Local and just request the motivation section in the documentation. I think the situation of Boost.Local is similar to that of Boost.Move, and the latter was accepted into Boost. Also, having a library in Boost whose primary purpose is to serve as the foundation for other Boost libraries is not a precedent (I mean Boost.Proto and now Boost.Context). Regards, &rzej

3 2

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Just one more thought. I was not participating in the design discussion for Boost.Local when it was probably a better time to mention this. So I am just mentioning it for reference. Functions that take parameters and bind existing objects are called closures: http://en.wikipedia.org/wiki/Closure_%28computer_science%29.<http://en.wikipedia.org/wiki/Closure_%28computer_science%29> This could have been an alternative name for BOOST_LOCAL_FUNCTION: BOOST_SCOPE_CLOSURE... Regards, &rzej

2 1

[1.48.0] Status?
by Beman Dawes 15 Nov '11

15 Nov '11

Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now. There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC: accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers) See http://beta.boost.org/development/tests/release/developer/summary.html Do we really want to release with this many failures? Worried, --Beman

12 33

[property_tree] Assign and Lua parser
by Renato Florentino Garcia 15 Nov '11

15 Nov '11

In my use of Boost Property Tree library I have coded some extensions, which are in a GitHub repository (http://github.com/renatoGarcia/boost-extensions) I would like to know if there are any interest in make any of then part of Boost Property Tree itself, probably after a suggest improvement. The more useful in my view is a Boost Assign Property Tree alike. Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… For instance, to build in C++ code a ptree like: key1 value1 key2 { key3 12345 { key4 "value4 with spaces" } key5 value5 "" 10 "" 11 "" 12 } Instead the current: ptree pt; pt.add("key1", "value1"); ptree tmpPt1; tmpPt1.add("key3", 12345); ptree tmpPt2; tmpPt2.add("key4", "value4 with spaces"); tmpPt1.push_back(std::make_pair("", tmpPt2)); tmpPt1.add("key5", "value5"); ptree tmpPt3; tmpPt3.put_value(10); tmpPt1.push_back(std::make_pair("", tmpPt3)); ptree tmpPt4; tmpPt4.put_value(11); tmpPt1.push_back(std::make_pair("", tmpPt4)); ptree tmpPt5; tmpPt5.put_value(12); tmpPt1.push_back(std::make_pair("", tmpPt5)); pt.add_child("key2", tmpPt1); Would be a code like: ptree pt = tree() ("key1", "value1") ("key2", tree() ("key3", 12345) (tree() ("key4", "value4 with spaces")) ("key5", "value5") (10)(11)(12)); Another extension is a Lua parser, like the XML or JSON. But in this case I don't think that is desirable include it in the Boost, because of the needed of Lua libraries (at least not in a mandatory way). Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… Regards, Renato Garcia

2 1

Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Hi Lorenzo, I would like to provide some comments on Boost.Local. > Please state clearly whether you think this library should be accepted > as a Boost library. I am unable to give a yes/no answer. This is mostly because I am not clear who is the intended audience of the library. I explain this in detail below. I am impressed with the library documentation. It is very informative with lots of examples, benchmarks, comparisons, rationale, and layered design (overview, and then details). This is how a Boost library's documentation (and every documentation, IMO) should look like. Yet, one thing that I am missing is what practical problems (that are not already solved) this library is trying to solve. I am not saying that it doesn't solve any. I am just saying I cannot figure it out. A typical story for a Boost library is that there is a common problem that many developers face fairly often, and at some point someone decides to fix this problem comprehensively and ultimately. This is the impression that I had, for example, with Boost.Optional. When I read about it I thought "Yes! This is what I was missing for a long time". I cannot see this in Boost.Local. Perhaps I am not the intended audience of the library, but it would help me if it was clear who the audience is. (I provide examples of what I mean below.) Documentation clearly separates three parts: local functions, local scopes and local exits. Also my impression is different on the three parts. This suggests to me that they could be three separate libraries. What do they have in common? The syntax, I guess. And the fact that you declare them inside functions. But is that enough to bundle them together? Consequently, I divide my comments into three parts. LOCAL FUNCTIONS Why would I want to use it? Personally, I have one compiler that does support local classes as template parameters. All my other compilers support lambdas. So I guess local functions are not for me. So who will use them? Someone that does not have too new compiler (because they have superior - in terms of performance - alternatives: lambdas, local classes). Someone that does not have a too old compiler, because we read in the documentation that "The implementation of this library uses preprocessor and template metaprogramming (as supported by Boost.Preprocessor<http://www.boost.org/doc/libs/release/libs/preprocessor/doc/index.html>and Boost.MPL <http://www.boost.org/doc/libs/release/libs/mpl/doc/index.html>), templates with partial specializations and function pointers (similarly to Boost.Function<http://www.boost.org/doc/libs/release/doc/html/function.html>). As a consequence, this library is fairly demanding on compilers' compliance with the C++03 <http://www.open-std.org/JTC1/SC22/WG21/docs/standards>standard." Further someone who does not mind compile-time and run-time performance overhead. And someone,who prefers the new syntax to creating a functor class non-locally. I am not sure how many users that would be? The documentation mentions proposal N2511<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html>, which says that even though with lambdas and local classes we already have a good tool, we still want to have a normal function syntax for local functions. Boost.LocalFunction does not enable a normal function syntax either, so it is no better an alternative than lambdas or local classes. Except for "const binding" which I find hard to appreciate. And except for compilers that don't support C++11 features, but than again, working only with the new compilers I may not be the right person to review the library. Is this supposed to provide a seamless migration of the code from compilers w/o lambdas to those that do support lambdas? I am not comfortable with the syntax: we first specify parameters, then function body and last, we specify the function name. I am not comfortable that the other Lorenzo's library (that I await impatiently) - Boost.Contract - will provide a different function syntax than Local Functions. This will render the situation where every library will require of me to learn different function declaration syntax. On the other hand, the documentation clearly says why this syntax is necessary, so I am not saying "change the syntax". I am suspicious about the local function overloading. While I can imagine writing a local function; writing a bunch of them inside another function would be likely be some error in my design. LOCAL BLOCKS Again, why would I need them? The example with assertion does not convince me. That is, I face the practical tradeoff: additional enforcement on assertions at the cost of slower build, slower execution time and less readable syntax. I will choose not to use the blocks. The only application that I can think of is a "temporary usage" while refactoring. If I work with the code where functions are 1000-line-long, I would like to divide them into blocks and check which parts reference what variables. In this case, as one of the footnotes in documentation suggests, allowing "return;" inside blocks would be a dangerous thing. But again, if I had a luxury of lambdas, I would choose lambdas for that purpose, because they allow specifying the default binding ( [&], [=] ). It looks like local blocks are only a syntax sugar over local functions. Am I right? LOCAL EXITS While exception specifications for locals blocks seam strange, I find allowing exception specifications for local exits an error. Local exits should be subject to the same restrictions as destructors (they are implemented as destructor calls anyways): you must not throw from them. And I expect the library documentation to say it explicitly. I find this "warning" missing from Boost.ScopeExit. So I suggest to disallow (if possible) specifying exceptions in local exit, and adding a section in documentation that warns against potential throws from an exit. I do not see anything against having two libraries for the same purpose. This is pretty much the same what we already have in Boost in case of state machines. But since we have two, it is useful to ask why I would choose local exit over scope exit. My answer is: 1. Local Exit allows me to specify an empty parameter list (I cannot do it with ScopeExit). - this is a practical problem I faced 2. I can bind to "this". I do not find const binding a practical advantage. Typically for short functions it is hardly a real problem that I confuse = with ==. And exits would typically be one-liners in my code. On the other hand there are reasons why I would prefer ScopeExit to LocalExit: it spells shorter. In LocalExit I have to type word 'bind' for every single parameter even though it is obvious I need to bind them all (because scope guards do not accept normal parameters). The same argument goes for blocks, obviously. I also like ScopeExit's potential to be implemented with lambdas, which might result in performance benefits, and allow the 'default binding'. On the other hand LocalExit cannot be implemented with a lambda, if not for any other reason, then due to the const binding. It is really nice that i can bind to variable of the name 'bind'; although I cannot use type 'bind' in local functions. GENERAL THOUGHTS I am really impressed with the usage of macros. It looks like thanks to Lorenzo we are reaching a new level of preprocessor programming. Who knows how far we can go. I do not think they are overused, given the difficult task. On the other hand, error messages that I encountered give me no clue on what I have typed wrong. Decsriptions in the documentation, and the rationale clearly indicates the very detailed knowledge of many C++ aspects. One suggestion for the future, although I am not sure how useful it would turn out in practice is to have something like local expression, or even not necessarily a local one. This would be a function whose body consists of a single expression. The benefit you get is that the programmer does not need to specify a return type for it (you can use BOOST_TYPEOF for that), or doesn't even have to type keyword 'return', but this may be too much off topic. Term 'C99 <http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899> and later compilers' may be a bit of an overuse for C++ compilers. I suggest 'compilers supporting variadic macros'. Also, in reply to particular review questions: > What is your evaluation of the design? It is clear. Some macros are difficult to read, e.g. Function arguments first, function name second, but I guess this is a necessity given the domain. > What is your evaluation of the implementation? The impressive macro magic is beyond my cognitive capabilities > What is your evaluation of the documentation? It is very good. It meets Boost's and my personal criteria for a good documentation. > What is your evaluation of the potential usefulness of the library? > Are you knowledgeable about the problem domain? This is the part where I have problems. I am not sure about the scope and intended audience of the library. > Did you try to use the library? With what compiler? Did you have any problems? I tried to use the library (basic examples) with VC++8 and VC++10 and Boost 1.42. I found that it does not compile if I use compiler option /ZI (Debug Information Format: Program Database for Edit & Continue) on either compiler. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent one evening on reading the documentation and playing with the basic examples. For the last remark, I believe that the criterion for accepting or rejecting a library is that if it addresses a real-life problems and if it is well designed. Boost.Local is well designed, but the intended audience and primary motivation is not clearly stated, so I find it hard to assess if the first criterion is met. All in all, Boost.Local is an impressive piece of work. Regards, &rzej

2 1

Determining interest: C++11 parser generator library
by Gene Bushuyev 15 Nov '11

15 Nov '11

Sorry if it turns out to be a duplicate, it looks my original post was lost in cyberspace, so I'm re-posting this request. I'm trying to determine if there is a sufficient interest for including AXE C++11 recursive descent parser generator library in Boost. The zipped sources and documentation are here: http://www.gbresearch.com/axe/axe.zip - Gene Bushuyev

4 7

[program_options] Improving error text in exceptions
by Leo Goodstadt 15 Nov '11

15 Nov '11

As a long time fan of boost::program_options, I would very much like to make the error messages in program_options exceptions more consistent and informative. Exception text is usually aimed at the developer as a diagnostic for rare errors. If the exception needs to be propagated to the end-user, it can be caught, and a more appropriate message substituted. This is not true for program_options: Exceptions from invalid program arguments are the common (and normal) reason for early program termination. It would be nice if, out of the box, exception text could be clear enough to present to the end user more or less as is. This would allow a single try/catch(exception) in main() cerr << "Error: " << e.what() << "\n"; return 1; >From the attached list of error messages, there are many, many different exception types which are thrown. The usual practice of repackaging / reformatting exceptions to be more user-friendly would be tedious or impractical. I grep-ed "boost::throw_exception" to get a list of all the exceptions and messages. I suggested revisions for all but 5. These I have set them aside at the end. I have modelled some of the proposed text on GNU genparse examples (i.e. the behaviour of "ls" and "cat" etc.). These, by dint of their frequent use / hammering by the huge linux user base, are probably good examples of the sort of friendlier clarity I would hope for. In some cases, I have tried to understand the exception text from the code but might have misunderstood the original intent. If this is useful, I shall painstaking go through the code and submit a patch. Leo Goodstadt P.S. I realise there are pitfalls to do with option prefix styles "--" and "/" but the addition of option prefixes to the exception text makes the message a lot clearer. P.P.S. I have kept the current style of starting the text in lower case even though my own preference would be for a capitalised sentence ending in a full stop. ======================================================= Original (CURRENT) and revised (CHANGED) text resulting from exception.what() ======================================================= CURRENT: <ambiguous option option_name> CHANGED: <option '--option_name' is ambiguous and matches options "--aa"," --b" and "--c".> // abbreviated instead of long/short because // length might imply too many/few letters CURRENT: <style disallows parameters for long options> CHANGED: <arguments are not allowed for unabbreviated option names> CURRENT: <style disallows parameters for short options> CHANGED: <arguments are not allowed for abbreviated option names> CURRENT: <style disallows all characters for short options> CHANGED: <abbreviated option names are not valid> CURRENT: <adjacent parameter is empty> CHANGED: <Invalid command line syntax: each option with an equal sign must be followed immediately by its argument.> CURRENT: <parameters adjacent to long options not allowed> CHANGED: <arguments are not allowed for unabbreviated options> CURRENT: <required parameter is missing in 'option_name'> CHANGED: <option '--option_name' requires an argument> CURRENT: <in option 'option_name': invalid option value> CHANGED: <invalid argument for option '--option_name'> CURRENT: <unrecognised line in 'DODGY LINE'> CHANGED: <options configuration file contained an invalid line: 'DODGY LINE'> CURRENT: <multiple occurrences> CHANGED: <option '--option_name' cannot be specified more than once> CURRENT: <can not read file NON_EXISTENT_FILE_NAME> CHANGED: <cannot read options configuration file 'FILE_NAME'> CURRENT: <missing required option required_option> CHANGED: <option '--option_name' is required> CURRENT: <too many positional options> CHANGED: <too many positional arguments have been specified> CURRENT: <unknown option unknown_option> CHANGED: <unrecognised option 'option_name'> CURRENT: <in option 'invalid_option': invalid bool value> CHANGED: <at least one argument is required for option '--option_name> CURRENT: <in option 'option_name': invalid bool value> CHANGED: <invalid argument for option '--option_name'. Valid arguments are 'on|off', 'yes|no', '1|0' and 'true|false'> CURRENT: <in option 'option_name': multiple values not allowed> CHANGED: <option '--option_name' only takes a single argument> Not sure what these mean and have left them alone. libs/program_options/src/parsers.cpp:112: boost::throw_exception(error("long name required for config file")); libs/program_options/src/config_file.cpp:60: boost::throw_exception(error("bad prefixes")); libs/program_options/src/value_semantic.cpp:102: boost::throw_exception(multiple_values()); libs/program_options/src/convert.cpp:66: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/convert.cpp:74: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/value_semantic.cpp:33: boost::throw_exception(std::runtime_error("UTF-8 conversion not supported.")); -- Dr. Leo Goodstadt University of Oxford United Kingdom

2 1

[Serialization] Proposal for TR2
by Ruediger Berlich 15 Nov '11

15 Nov '11

Dear Robert, dear all. from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ? We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!). Best, Ruediger

3 2

[context] ready
by Oliver Kowalke 14 Nov '11

14 Nov '11

Hi, https://github.com/olk/boost.context.git contains the new version of boost.context (docu at http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html) Any comments are welcome - in the meantime I'm awaiting Giovanni's OK for the mini-review. regards, Oliver

8 15

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
by Krzysztof Czainski 14 Nov '11

14 Nov '11

Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> > Please state clearly whether you think this library should be accepted as a > Boost library. > Yes. Other questions you may want to consider: > > - What is your evaluation of the design? > I like it. > - What is your evaluation of the documentation? > I enjoyed reading it, and I think it gave me a pretty good idea about the library. > - What is your evaluation of the implementation? > >From what I read in the Implementation section of the docs, looks reasonable. > - What is your evaluation of the potential usefulness of the library? > I can imagine it would improve readability of some of my code. > - Did you try to use the library? With what compiler? Did you have any > problems? > No. I intend to, but not until the end of this review. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > In-depth study of the docs. > - Are you knowledgeable about the problem domain? > Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then some) > as Boost.ScopeExit. Does this duplication of functionality need to be > dealt with, and if so, how? I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template? > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm > looking forward to it! > > - Jeffrey Hellrung (Review Manager) > - Gregory Crosswhite (Review Assistant) This was my first review, and I hope it's useful ;-) Regards, Kris

3 3

Need for BOOST_PP_VARIADIC_POP_FRONT
by Gennadiy Rozental 14 Nov '11

14 Nov '11

Hi, I consider using Boost.PP variadic macros support, but I seems to be missing subject macro (with support for zero arguments). Any chance we can one? I'd hate to reinvent the wheel. Regards, Gennadiy

4 16

1.48 is another release without the logger
by Jeff Graham 14 Nov '11

14 Nov '11

Hello, Any progress on the logger?

2 1

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Lorenzo Caminiti 14 Nov '11

14 Nov '11

Hello all, I have received a couple of questions on Boost.Local and I will answer them on the ML. On Mon, Nov 14, 2011 at 4:20 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 1. Can Boost.Local be used to create global functions? No, Boost.Local macros need to be used at local scope. If it were important to use the functionality of Boost.Local at global scope, it _might_ be possible to do so but another set of macros (BOOST_GLOBAL_?) will have to be defined for that. Does anyone see a need to use LOCAL_EXIT, LOCAL_BLOCK, or LOCAL_FUNCTION at global scope? If so, why? > 2. For Local Exits, is it possible not to bind any variable (because I will > only be calling global functions): > > int runCommand() { > ::DisplayWaitCursor(); > BOOST_LOCAL_EXIT( /*nothing*/ ) { > ::DisplayNormalCursor(); > } BOOST_LOCAL_EXIT_END; > > DoALongLastingOperation(); > } Yes, you can do this. However, the most portable syntax is to use void for the empty parameter list: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… For example: #include <boost/local/exit.hpp> #include <iostream> void f() { std::cout << "f" << std::endl; } int main() { ::f(); BOOST_LOCAL_EXIT(void) { ::f(); } BOOST_LOCAL_EXIT_END return 0; }; This compiles and it prints "f" twice (at main entry and exit). HTH, --Lorenzo

1 0

[1.48][flyweight] regression in release branch
by JOAQUIN M. LOPEZ MUÑOZ 13 Nov '11

13 Nov '11

Hi, Sorry for not having tracked this before. There's a trivial regression in Boost.Flyweight due to a change of namespace name in Boost.Interprocess: https://svn.boost.org/trac/boost/changeset/75464 OK to commit to branch? Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 2

[iostreams][io_state_savers] Request for interest in some ios_base basic utilities
by Vicente J. Botet Escriba 12 Nov '11

12 Nov '11

Hi, I'm a beginner of the standard IOStream library. While restructuring Boost.Chrono I/O I have find some classes that could be of general use (if the design is correct, of course). The first one is quite simple, is used to define manipulators with parameters. Instead of defining a class and the correspondent stream inserters and extractors the manip template class do all this at once. It can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; Now mendl can be use to insert n new lines at once as follows cout << mendl(3); The second one is an ios specific smart pointer ios_base_state_ptr (based on the use of ios_base::pword and ios_base::xalloc). The class ios_base_state is a ios_base_state_ptr that can not be null. It can be used like struct MyData { std::string time_fmt; std::string duration_fmt; }; std::string get_time_fmt(std::ios_base & ios) { return ios_base_state<MyData>(ios)->time_fmt; } ios_base_state stores a new MyData in the ios if not already stored and provides an smart pointer interface to it. The 3rd one (ios_base_flags) uses the ios_base::iword and xalloc to provide access to specific ios flags. It can be used as follows: class fmt_masks : ios_base_flags<fmt_masks> { typedef ios_base_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; }; Usage of this class can be duration_style::type get_duration_style(std::ios_base& ios) { return (fmt_masks(ios).flags() & fmt_masks::uses_symbol) ? duration_style::symbol : duration_style::prefix; } The interface and the implementation of these classes is attached. Do you see a design flag on these classes? If not, do you think these kind of utilities could be added to boost? If yes, could these be merged with Boost.io_state_savers or Boost.IOStreams to form a larger io utilities libraries? Best, Vicente

3 14

Are some of the trunk regression tests running in C++0x mode when they shouldn't be?
by Richard Webb 11 Nov '11

11 Nov '11

Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be. for example: Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x" If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them. Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it? Thanks, Richard Webb

7 10

leak in win32 detail::basic_condition_variable
by Kenneth Porter 10 Nov '11

10 Nov '11

I'm finding that an element in the CV's generation_list is left orphaned sometimes when the CV is destroyed. I'm running Visual Leak Detector and it gives this stack dump of the allocation point of the leaked object: c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (172): boost::detail::basic_condition_variable::get_wait_entry c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (211): boost::detail::basic_condition_variable::do_wait<boost::unique_lock <boost::mutex> > + 0xC bytes c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (369): boost::condition_variable_any::wait<boost::unique_lock<boost::mutex> > c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (374): boost::condition_variable_any::wait<boost::unique_lock <boost::mutex>,boost::_bi::bind_t<bool,boost::_mfi::cmf0 <bool,bounded_buffer<Axis::Report> >,boost::_bi::list1<boost::_bi::value <bounded_buffer<Axis: + 0x1B bytes I compared the source file against trunk and it hasn't changed.

1 0

asio ipv6 anycast
by Julian Faude 10 Nov '11

10 Nov '11

Hi, I am working on a project which depends on IPv6 anycast. In linux IPv6 anycast is available through a socket options called IPV6_JOIN_ANYCAST and IPV6_LEAVE_ANYCAST. Like the multicast option it's based on the ipv6_mreq struct. If I'm not mistaken there is no ipv6 anycast socket option in asio. Am I right? Is anybody working on it? Best, Julian

2 1

[Test] Darwin Intel 11.1
by Belcourt, K. Noel 09 Nov '11

09 Nov '11

Hi, I've attached a patch that appears to fix problems with about 20 Boost libraries on trunk that depend on Boost.Test. This patch simply removes an argument to format_report(). The trunk tests (http://www.boost.org/development/tests/trunk/developer/summary.html ) currently reflect this patch. I've added this patch to the nightly trunk testing patch script until such time as we get this committed to trunk. -- Noel

1 0

Fw: [atomic] review results
by Peter Dimov 08 Nov '11

08 Nov '11

-----Original Message----- From: Peter Dimov Sent: Monday, November 07, 2011 22:38 To: Helge Bahmann Subject: Re: [boost] [atomic] review results Helge Bahmann wrote: > yes makes sense -- there was a concern raised by Andrey Semashev that the > spinlock pool as implemented and used by shared_ptr presently may fail on > Windows due to the pool being non-unique (not had a chance to test this > yet), > and I have found a way to produce a similar failure using dlopen, atomics > private to shared libraries and RTLD_LOCAL -- currently I am therefore > leaning on creating a shared library just for the spinlock pool, but since > you wrote the initial implementation maybe you could comment as well? This is a problem in principle, but requiring all users of shared_ptr to link to a shared library is a non-starter. I wouldn't use such a shared_ptr, and I doubt many others will. And I wouldn't be surprised if this sentiment applies to Boost.Atomic as well.

5 35

[parameter] type requirement compiler error
by lcaminiti 08 Nov '11

08 Nov '11

Hello all, The following parameter type requirement: (required (graph, *) ) (optional (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) ) Generates a GCC error: dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope Detailed code and error below. In fact, if I look at the code after pp, I can see that graph_type is define only after the type requirement is checked... why? What am I doing wrong? Thanks a lot! --Lorenzo #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/parameter.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *)) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) (index_map, *, boost::get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(boost::num_vertices(graph), index_map)) ) ) { std::cout << "here\n"; boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } } // namespace graphs template< typename TimeMap > class dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits< TimeMap >::value_type T; public: dfs_time_visitor(TimeMap dmap, TimeMap fmap, T& t) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } TimeMap dmap_; TimeMap fmap_; T& time_; }; using namespace boost; int main ( ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } $ g++ -Wall -I../../../../../boost-trunk.cygwin dfs.05.cpp dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope dfs.05.cpp:40: error: template argument 1 is invalid dfs.05.cpp:40: error: expected `::' before ‘,’ token dfs.05.cpp:40: error: expected identifier before ‘,’ token dfs.05.cpp:40: error: template argument 3 is invalid dfs.05.cpp:40: error: expected `::' before ‘{’ token dfs.05.cpp:40: error: expected class-name before ‘{’ token ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, const dfs_time_visitor<main::size_type*>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ dfs.05.cpp: In function ‘int main()’: dfs.05.cpp:88: error: no matching function for call to ‘depth_first_search(main()::G&, dfs_time_visitor<size_type*>&)’ -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-type-requirement-compile… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 14

[1.48 lexical_cast] Illegal Derefence
by Olaf van der Spek 08 Nov '11

08 Nov '11

Hi, This does an illegal dereference in boost\lexical_cast.hpp(1357): if ( Traits::eq(minus,*start) ) #include <boost/lexical_cast.hpp> #include <boost/range/iterator_range.hpp> int main() { boost::iterator_range<const char*> v; boost::lexical_cast<int>(v); } -- Olaf

3 10

Boost interprocess: Segmentation fault
by thuannv 08 Nov '11

08 Nov '11

Hi everybody, I am beginner to develop with boost library. I am working with shared memory (boost.interprocess). So, I got error in executing and could anyone help me solve this problem? My problem is: - I wrote 2 process named SHMWriter and SHMReader. + SHMWwriter: write a map (int, int) into the SHM. + SHMReader: read the map value from SHM. - I executed the SHMWriter then SHMReader. - SHMWriter successfully executed. But, SHMWriter always executed failed (error: Segmentation fault). - The sources code are listed below: //SHMWriter: -------------------------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { shared_memory_object::remove(segName); managed_shared_memory segment(create_only, segName, 1000); MapAllocator allocator(segment.get_segment_manager()); IntegerMap* pOffsetMap = segment.construct<IntegerMap>(mapName)(std::less<int>(), allocator ); int key = 1; int ivalue = 10; MapValue value(key, ivalue); pOffsetMap->insert(value); return 0; } //SHMReader ----------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { try { managed_shared_memory segment(open_only, "MAPSEGMENT"); IntegerMap* pMap = segment.find_no_lock<IntegerMap>(mapName).first; int key = 1; int value = pMap->at(key); std::cout << value << std::endl; } catch(interprocess_exception& ie) { std::cout << ie.what() << std::endl; } catch(std::exception& stde) { std::cout << stde.what() << std::endl; } return 0; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-interprocess-Segmentation-fault-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Range] Confusing result of iterator_range::size()
by Sergey Voropaev 08 Nov '11

08 Nov '11

Hi, I try use boost::iterator_range as replacement for some standard container in my code. The function iterator_range::size() has non standart declaration: difference_type size() const; but not: size_type size() const When I compile code in VC++ 2010 I have a some warning and error. For example: #include <boost/range.hpp> #include <vector> #include <algorithm> int main() { int aaa[10] ={1,2,3,4,5,6,7,8,9,10}; std::vector<int> bbb(20); boost::iterator_range<int*> arr(aaa); if(bbb.size() > arr.size()) //warning C4018: '>' : signed/unsigned mismatch { } const size_t lng = std::min(bbb.size(), arr.size()); //error C2780: 'const _Ty &std::min(const _Ty &,const _Ty &,_Pr)' : expects 3 arguments - 2 provided //error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' : template parameter '_Ty' is ambiguous // const size_t lng = std::min(bbb.size(), (size_t)arr.size()); //OK for(size_t i = 0; i < lng; ++i) { bbb[i] = arr[i]; } return 0; } I think declaration of boost::iterator_range must be fixed. Or there was some reason for this non standard declaration?

8 29

Boost.Build is broken?
by Gennadiy Rozental 08 Nov '11

08 Nov '11

Hi, Frankly I do not know who supports Boost.Build, but how long it'll stay broken? I can't say when it started, but ever since I started working on Boost.Test changes I experience constant problems. I can't believe I am the only one. 1. When you take boost trunk and go into Boost.Test build or test directory and try building using any toolset it immediately fails with: ..\..\..\libs\test\build\Jamfile.v2:110: in modules.load rule boost-install unknown in module Jamfile</.../trunk/libs/test/build>. .../trunk/tools/build/v2/build\project.jam:314: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in project.load .../trunk/tools/build/v2/build\project.jam:766: in project.use .../trunk/tools/build/v2/build\project.jam:89: in load-used-projects .../trunk/tools/build/v2/build\project.jam:73: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:168: in project.find .../trunk/tools/build/v2\build-system.jam:570: in load .../trunk\tools\build\v2/kernel\modules.jam:283: in import .../trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build .../trunk\boost-build.jam:17: in module scope 2. Once I remove boost-install from Boost.Test Jamfile, I get bun of errors like this: ..\..\..\libs\test\src\compiler_log_formatter.cpp(16) : fatal error C1083: Cannot open include file: 'boost/test/impl/compiler_log_formatter.ipp': No such file or directory Essentially boost home directory is missing from include path. How come? 3. Once I add "<include>../../.." into requirements section I can build with msvc toolsets. Now I am trying to use gcc toolset on Windows. I have latest cygwin installation and I am getting these errors (lots of them): gcc.compile.c++ ..\..\..\libs\test\build\bin\gcc\debug\link-static\compiler_log_formatter.o "g++" ... # compilation line here Access is denied. Apparently g++ is not an executable anymore with cygwin. I am able to workaround this by adding using gcc : 4.5.3 : g++-4.exe ; into user-config.jam, but why Boost.Build can't figure this out and do I need to support this file now myself? 4. After the fix I am able to build dll based tests, but when I attempt to use static library version of Boost.Test I am getting: gcc.archive ..\..\..\libs\test\build\bin\gcc-4.5.3\ debug\link-static\libboost_unit_test_framework.a "/usr/i686-pc-cygwin/bin/ar.exe" rc .... # list of object files here "/usr/i686-pc-cygwin/bin/ranlib.exe" ... # lib here The system cannot find the path specified. The system cannot find the path specified. This one I do not know how to fix. So the situation is that I cannot test any static library based unit tests (as a side note, this inability was the cause of crashes which interrupted trunk testing month ago). I addition whenever I want to check in my local changes to Jamfile (excluding hacks which I actually do not want to check in) it is rather annoying process. Any help would be appreciated, Gennadiy

3 4

[atomic] review results
by Tim Blechmann 07 Nov '11

07 Nov '11

hi all, unfortunately only few reviews of boost.atomic arrived in time, however i count 3 YES and no NO, so i am happy to say: Helge Bahmann's boost.atomic library is ACCEPTED. since the library is an implementation of a c++11 feature for c++03, design, API and semantics are mostly fixed. many comments are going into details of the implementation, so i won't sum them all up ... iac, helge already said he wants to address the raised issues, the main points are summarized below. full implementation of the c++11 interface: the library currently only implements a subset of the c++11 library. it lacks the functional interface for integral atomic types and the ATOMIC_VAR_INIT / ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently have at hand the following two functions are missing as well: template <class T> T kill_dependency(T y); void atomic_signal_fence(memory_order); i encourage helge to provide a full implementation of the interface. documentation: the documentation is currently lacking a good API reference. i would therefore encourage helge to provide a doxygen-generated reference section. there were some concerns that it assumes that readers will have to be familiar with concurrency. maybe it is a good idea to point to some literature/tutorials about concurrent programming and/or to c++11 atomics. the section of real-world examples could probably include a link to shavit/herlihy's book `the art of multiprocessor programming'. it would also be helpful to have a detailed specification, if a platform/compiler combination supports a specific type natively (with run-time dispatching or specific compiler flags) ... maybe in form of a table. shared memory support/multi-module support: in multi-module applications and when using shared memory, the blocking emulation of atomics can cause troubles. for multi-module applications this can be resolved by placing the spinlock pool inside a shared library. shared- memory support could be realized by associating a (spin)lock with each blocking atomic<> instead of using a pool of spinlocks. boost should definitely provide atomics which support shared memory, either by default or by an additional implementation which is placed in the boost::interprocess namespace. i would like to thank helge for implementing boost.atomic and submitting it to boost and everyone who participated in the review. cheers, tim review manager

4 4

[smart_ptr] Please merge 5327
by Steve M. Robbins 07 Nov '11

07 Nov '11

Peter Dimov, When you have a moment, could you merge the patch in ticket https://svn.boost.org/trac/boost/ticket/5327 It should be safe enough; Debian has been using this since August 2009. Thanks, -Steve

2 1

[parameter] named template parameters
by Lorenzo Caminiti 07 Nov '11

07 Nov '11

Hello all (and especially Boost.Parameter's authors), The Boost.Parameter docs suggest to implement parameter-enabled class templates using a series of typedes for the argument pack and the actual argument types. I think it is best to define extra template parameters with default values to old the argument pack Args and named template parameters ClassType, etc as shown below. This allows to use the named template parameters within the class declaration for example in a base class (boost::python::class_<ClassType, ...>) instead that just in the class definition. Do you see any problem in using extra template parameter to define the argument pack and named template parameters? #include <boost/parameter.hpp>#include <boost/python/class.hpp>#include <boost/type_traits/is_class.hpp>#include <boost/type_traits/is_base_and_derived.hpp>#include <boost/mpl/is_sequence.hpp>#include <boost/mpl/placeholders.hpp>#include <boost/mpl/not.hpp>#include <boost/mpl/and.hpp>#include <boost/noncopyable.hpp>#include <boost/shared_ptr.hpp> namespace py { namespace detail { struct bases_tag {}; } template< class B0 = void, class B1 = void, class B2 = void >struct bases : detail::bases_tag {}; BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable) template< typename Arg123X0 , typename Arg123X1 = boost::parameter::void_ , typename Arg123X2 = boost::parameter::void_ , typename Arg123X3 = boost::parameter::void_ , typename Args123 = typename boost::parameter::parameters< // IF(IS_EMPTY(DEFAULT(p)), required, optional) boost::parameter::required< tag::ClassType , boost::is_class<boost::mpl::_> > , boost::parameter::optional< // IF(IS_DEDUCED(p), deduced<tag::NAME(p)>, tag::NAME(p)) boost::parameter::deduced<tag::BaseList> // COMMA_IF(COMPL(IS_EMPTY(REQUIRES(p)))) REQUIRES(p) , boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> > , boost::parameter::optional< boost::parameter::deduced<tag::HeldType> , boost::mpl::not_< boost::mpl::or_< boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> , boost::is_same<boost::noncopyable, boost::mpl::_> > > > , boost::parameter::optional< boost::parameter::deduced<tag::Copyable> , boost::is_same<boost::noncopyable, boost::mpl::_> > >::bind<Arg123X0, Arg123X1, Arg123X2, Arg123X3>::type , typename ClassType = typename boost::parameter::value_type< Args123, tag::ClassType >::type , typename BaseList = typename boost::parameter::value_type< // ... COMMA_IF(COMPL(IS_EMPTY(DEFAULT(p)))) DEFAULT(p) >::type Args123, tag::BaseList, bases<> >::type , typename HeldType = typename boost::parameter::value_type< Args123, tag::HeldType, ClassType >::type , typename Copyable = typename boost::parameter::value_type< Args123, tag::Copyable, void >::type>struct class_ : boost::python::class_<ClassType, BaseList, HeldType, Copyable>{ typedef ClassType class_type; typedef BaseList base_list; typedef HeldType held_type; typedef Copyable copyable;}; } // namespace py struct b { virtual ~b() = 0; }; struct d : b { ~d() {} }; // Named parameters.typedef py::class_< py::ClassType<b>, py::Copyable<boost::noncopyable> > x1;typedef py::class_< d, py::HeldType< boost::shared_ptr<d> >, py::BaseList< py::bases<b> > > x2;// Deduced parameters.typedef py::class_< b, boost::noncopyable > y1;typedef py::class_< d, boost::shared_ptr<d>, py::bases<b> > y2; A couple more things: 1) I thing that BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) macro should define a symbol _ClassType to be used for the named parameter so to be consistent with the BOOST_PARAMETER_NAME(x) which defined _x to be used for the named function parameter. However, ClassType is defined without the leading _. What is the reason for this asymmetry? 2) I'd expect a macro that allows to specify tag and passing argument name for template parameters BOOST_PARAMETER_TEMPLATE_KEYWORD((PassClassType, mytag) ClassType) as for BOOST_PARAMETER_NAME((pass_x, mytag) x) does for function parameters. Why is such a usage of BOOST_PARAMETER_TEMPLATE_KEYWORD not supported? Thanks a lot. --Lorenzo

4 10

[smart_ptr] scoped_array / shared_array (size_t) constructor
by Olaf van der Spek 07 Nov '11

07 Nov '11

Hi, Currently, one has to manually allocate the array and pass the ptr to the constructor of scoped_array / shared_array. boost::scoped_array<unsigned char> A(new unsigned char[100]); boost::shared_array<unsigned char> B(new unsigned char[100]); This requires one to repeat the type and shared_array requires two allocations (one extra for the control block). std::vector has a constructor from size_t and one can write: std::vector<unsigned char> V(100); This avoids the type duplication and it'd allow shared_array to do only a single allocation. A few choices have to be made: 1. Should "new T[sz]" or "new T[sz]()" be used? 2. What should happen when size = 0? Should it call new T[0] or should it just use NULL? https://svn.boost.org/trac/boost/ticket/4637 -- Olaf

10 46

[python] Please apply and merge 2208
by Steve M. Robbins 07 Nov '11

07 Nov '11

Hi, The patch has been used in Debian since August 2008 so it should be safe to apply. Thanks, -Steve

1 0

[units] spatial coordinates, vectors, x, y, z, something like that
by Janek Kozicki 06 Nov '11

06 Nov '11

Hi, I want to use boost::units to calculate diffraction & interference patterns and wave propagation in 3D. I need some way to represent points in spatial 3D space with 'length' dimension. What do you guys use for that? I need them to work with 'frequency' & 'speed' dimensions also. Don't tell me that I need to write my own 'vector' class ? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

2 2

Interest in bounded (Top-Bounded) Range adaptor.
by Fernando Pelliccioni 06 Nov '11

06 Nov '11

Is there interest in adding a Top-Bounded adaptor into Boost.Range ? Example: using namespace boost::adaptors; using namespace boost::assign; std::vector<int> input; input += 1,2,3,4,5,6,7,8,9; boost::copy( input | bounded(0), std::ostream_iterator<int>(std::cout, ",")); // prints nothing boost::copy( input | bounded(1), std::ostream_iterator<int>(std::cout, ",")); // prints 1, boost::copy( input | bounded(2), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2, boost::copy( input | bounded(8), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8, The above example is similar in behavior to ... boost::copy_n( input, 0, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 1, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 2, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 8, std::ostream_iterator<int>(std::cout, ",")); The difference is that *copy_n* algorithm doesn't check for begin(range) != end(range) In the following line, an error occurs at runtime... boost::copy_n( input, 9, std::ostream_iterator<int>(std::cout, ",")); Unlike the following that runs ok... boost::copy( input | bounded(9), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8,9, This behavior could be equated using *sliced(0, X)*, but sliced requires *RandomAccessRange*, unlike bounded that requires *SinglePassRange*. *bounded* code is based on *indexed* adaptor code, I think it is more efficient than *sliced* ( that uses *make_iterator_range* --> std::advance ). I don't know if this behavior can be achieved using other adapters, if so, please let me know. Is there interest in this for Boost? Regards, Fernando.

5 12

[parameter] aux_/void.hpp: potential undefined behavior
by Krzysztof Czainski 05 Nov '11

05 Nov '11

Hello, Here's boost/aux_/void.hpp contents, without include quards and license note, where I marked a line with a comment to refer to it below. [code] namespace boost { namespace parameter { // A placemarker for "no argument passed." // MAINTAINER NOTE: Do not make this into a metafunction struct void_ {}; namespace aux { inline void_& void_reference() { static void_ instance; // (1) return instance; } } // namespace aux }} // namespace boost::parameter [/code] My question is: is it allowed to use an instance of an uninitialized empty struct? The struct void_ is empty. On line (1) a static uninitialized instance of struct void_ is defined, and it is then returned. Does the standard allow this? I can't imagine any real problems with this, but I'm curious if this has defined behavior according to the standard. A natural and simple solution to my concern is of course to change the line (1) to: static void_ instance = {}; I'd be happy to create a ticket with a patch, if my concern is valid. Regards, Kris

3 5

[lockfree] review
by Gordon Woodhull 05 Nov '11

05 Nov '11

Hi Tim, Hopefully I'll have at least a partial review. I only know enough about the subject to be a little dangerous. (One course in concurrent data structures, one successfully implemented lockfree hash table - except for the memory reclamation. Unspecified barriers and ABA problems. :p ) Considering the difficulty of the subject, you seem to have carefully chosen a small set of algorithms where at least there is consensus that the sources you are using have solved the problem correctly. I apologize if this has already been covered, but I don't see anything in the documentation about which platforms and compilers this has been tested on. These algorithms are extremely susceptible to compiler and processor optimizations. Anyway, I thought I would try to run the tests, and maybe try changing the testing methodology a little, but I got a few compiler errors, below. Defining uint fixed most of these, but bench_1.cpp also appears to be out of date? Of course I also have my lack of understanding of boost build library linking to contend with. Hope to try again later. Cheers, Gordon ~/lib/boost_lockfree/libs/lockfree/test ~/src/boost-trunk grodo-mcwoohu:test gordon$ bjam ...found 141 targets... ...updating 21 targets... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o g++: unrecognized option '-no-cpp-precomp' bench_1.cpp: In function 'void test_fifo_pop()': bench_1.cpp:67:23: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue(long int*)' ../../../boost/lockfree/fifo.hpp:214:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_fifo_pop_unsafe()': bench_1.cpp:77:30: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue_unsafe(long int*)' ../../../boost/lockfree/fifo.hpp:255:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop()': bench_1.cpp:87:19: error: no matching function for call to 'boost::lockfree::stack<long int>::pop(long int*)' ../../../boost/lockfree/stack.hpp:179:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop_unsafe()': bench_1.cpp:97:26: error: no matching function for call to 'boost::lockfree::stack<long int>::pop_unsafe(long int*)' ../../../boost/lockfree/stack.hpp:207:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o" "bench_1.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1 for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.run for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o g++: unrecognized option '-no-cpp-precomp' fifo_test.cpp:103:18: error: 'uint' does not name a type fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::add()': fifo_test.cpp:116:14: error: 'uint' was not declared in this scope fifo_test.cpp:116:19: error: expected ';' before 'i' fifo_test.cpp:116:26: error: 'i' was not declared in this scope fifo_test.cpp:116:31: error: 'nodes_per_thread' was not declared in this scope fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::run()': fifo_test.cpp:187:1: error: 'nodes_per_thread' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o" "fifo_test.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.run for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test... darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test ld: library not found for -lboost_thread collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test" "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test.o" -lboost_thread -lboost_unit_test_framework -g ...failed darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test... ...skipped <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test.run for lack of <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/ringbuffer_test.test/darwin-4.5.3/debug/threading-multi/ringbuffer_test.o g++: unrecognized option '-no-cpp-precomp' ringbuffer_test.cpp:209:14: error: 'uint' does not name a type ringbuffer_test.cpp: In member function 'void ringbuffer_tester::add()': ringbuffer_test.cpp:225:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:225:19: error: expected ';' before 'i' ringbuffer_test.cpp:225:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:225:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester::run()': ringbuffer_test.cpp:284:1: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::add()': ringbuffer_test.cpp:315:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:315:19: error: expected ';' before 'i' ringbuffer_test.cpp:315:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:315:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::run()': ringbuffer_test.cpp:386:1: error: 'nodes_per_thread' was not declared in this scope

8 63

Re: [boost] [lockfree] review
by Boehm, Hans 05 Nov '11

05 Nov '11

[Dave Abrahams pointed me at this thread.] Alexander Terekhov <terekhov <at> web.de> writes: > > Dave Abrahams wrote: > > > > on Thu Aug 25 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: > > > > > Ilya Sokolov wrote: > > >> > > >> > > >> AFAIK, in the example above another thread can't observe reordering > > >> without introducing UB. > > > > > > I meant "observed" as in "check the sequence of writes in the generated > > > code". > > > > Do we care about what the generated code looks like? IIUC what counts > > is the sequence of memory states that another another thread can see. > > > > > But int can be simply changed to relaxed atomic<int> so that another > > > thread can observe reordering without UB. > > > > Sure. > > I meant that for the example upthread, with an int instead of relaxed > atomic<int>, another thread's code triggering UB does not prevent us > from observing reordered writes in the writing thread's code (in > generated code), by looking at it. > > Changing int to relaxed atomic<int> simply removes UB but does not > change the relevant code in the writing thread. > > regards, > alexander. > I agree with Alexander and most of the recent postings. If I write mx.lock(); x = 1; mx.unlock(); my.lock(); y = 1; my.unlock(); There is nothing to prevent the stores to x and y from becoming visible out of order at the hardware level. Enforcing ordering here would add needless and substantial cost. But a data-race-free program cannot observe such reordering. (One reference for that is Sarita Adve's and my PLDI 08 paper. Unofficial TR version at http://www.hpl.hp.com/techreports/2008/HPL-2008- 56.html. I believe Mark Batty et al have a much more complete and formal proof.) If we change x and y to be atomic variables, and the stores to be memory_order_relaxed, then an observer can tell the difference. I.e. if x and y are initially zero, and another thread does r1 = y; r2 = x; (or the acquire versions), it can see r1 = 1 and r2 = 0, since there are no synchronizes-with relationships between threads, and thus nothing to enforce ordering. If you use memory_order_relaxed, or even the acquire/release forms, things do get MUCH more complicated. The equivalent rules for other languages are an interesting story. I believe Posix implentors assume the above rules. I have a PPoPP 2007 paper that explains why that's not exactly what Posix actually states. OpenMP 3.0 has stricter rules which are also not consistently obeyed, and are somewhat fixed in OpenMP 3.1. (See my MSPC 11 paper for some details.) Java has arguably the same rules as C++ in this respect. In my mind, the main way in which sequential consistency differs from the cheaper acquire/release semantics that Alexander wants is that a) Dekker's algorithm (which by itself isn't that practically interesting), plus a number of real lock-free algorithms (which do matter) don't work. b) In my mind, acquire/release is a far more difficult model to explain to non- experts than the model for C++ with only sequentially consistent atomics. You can no longer reason about interleaving thread actions, either for purposes of determining the existence of a data-race, nor when defining what data-race- free programs mean. This was extensively discussed in C++ meetings starting in about 2005. The current solution with default-sequentially-consistent atomics, but explicit support for weaker ordering, was the resulting committee compromise. Hans

6 19

Determining interest in Delegates submission
by Jared McKee 05 Nov '11

05 Nov '11

I would like to determine interest in a possible library submission. I have written some code which converts a member function and object pointer combination to a free function for use in C style callbacks. It has some limitations which I will describe shortly. The basic idea is to be able to convert: R (B::*)(T0,T1,…) and B* to R (*)(T0,T1,…) Here's an example usage: class foo { int x; int test(int v) {return x + v;} }; foo* a = new foo; a->x = 3; int (*f)(int) = delegate(a, &foo::inc); cout << f(4) << endl; // outputs "7" When I first attempted this I used a technique where I allocated some executable memory in the heap and dynamically created a free function to call the member function for the instance. It was fun attempting that but, as you can imagine, as soon as I used the optimizer flags on my compiler I would get segment faults :) My second approach was to use templates and the Boost Preprocessor library to create appropriate static arrays of pointers to free functions matching the required signatures and then hand those pointers out each time the delegate() function is called. The two downsides to this are: you can only call delegate() for a certain function signature a limited number of times, and it adds a lot of potentially unused code to your executable. Here's the code (I've stripped out error checking for the sake of illustration): #include <boost/preprocessor.hpp> #ifndef _delegate_h_ #define _delegate_h_ #define MAX_DELEGATES 256 #define DELEGATE_PARAMS 0 #include "delegate_template.hpp" #undef DELEGATE_PARAMS #define DELEGATE_PARAMS 1 #include "delegate_template.hpp" #undef DELEGATE_PARAMS // … #endif // delegate_template.hpp #define DELEGATE_STORE BOOST_PP_CAT(DELEGATE_STORE,**DELEGATE_PARAMS) template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > struct DELEGATE_STORE { typedef B* objectPointer; typedef R (B::*memberFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); typedef R (*freeFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); static int delegateCount; static int delegateMax; static objectPointer delegateObjectPointer[MAX_**DELEGATES]; static memberFunction delegateMemberFunction[MAX_**DELEGATES]; template <int i> static R func( BOOST_PP_ENUM_BINARY_PARAMS(**DELEGATE_PARAMS, T, v) ) { return (delegateObjectPointer[i]->***delegateMemberFunction[i])( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, v) ); } static const freeFunction delegateFreeFunction[MAX_**DELEGATES]; static freeFunction getDelegate(objectPointer o, memberFunction m) { int delegateIndex = delegateCount++; delegateObjectPointer[**delegateIndex] = o; delegateMemberFunction[**delegateIndex] = m; return delegateFreeFunction[**delegateIndex]; } }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateCount = 0; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateMax = MAX_DELEGATES; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::memberFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateMemberFunction[MAX_**DELEGATES] = {0}; > template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::objectPointer DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateObjectPointer[MAX_**DELEGATES] = {0}; > #define FUNC_POINTER(z, n, params) &DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::template func< n >, template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > const typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::freeFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateFreeFunction[MAX_**DELEGATES] = { > BOOST_PP_REPEAT(MAX_DELEGATES, FUNC_POINTER,) }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > R (*delegate( B* b, R (B::*f)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) ))( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) { return DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::getDelegate(b, f); } // end Thankyou very much if you managed to read all the way to here! By the way, this is my first active participation in any open source project :) Jared

3 5

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1

"Best so far" for C level i/o of Unicode text with Windows console
by Alf P. Steinbach 03 Nov '11

03 Nov '11

This may be of interest to developers of Boost libraries that deal with text. I found that the Visual C++ implementation of the C library i/o generally does not support console input of international characters. It can deal with narrow character input from the current codepage, if that codepage is not UTF-8. For example: <code> #include <stdio.h> int main() { printf( "? " ); char buffer[80]; scanf( "%s", buffer ); printf( "%s\n", buffer ); } </code> <result> d:\dev\test> chcp 1252 Active code page: 1252 d:\dev\test> utf8test ? abcæøå abcæøå d:\dev\test> chcp 65001 Active code page: 65001 d:\dev\test> utf8test ? abcæøå ��, d:\dev\test> _ </result> I placed a comment about this at the blog of Microsoft's Unicode guru Michael Kaplan, http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx In particular, with active codepage 65001 (UTF-8), functions such as wscanf just fail outright on non-ASCII characters. The IMO best compromise that I have managed to come up with is a kind of hybrid, where the active input codepage is set to 1252, Windows ANSI Western, because that's a superset of Latin 1 which is a subset of Unicode. Output is converted to UTF-8. Input from e.g. a file accepts UTF-8. This means that e.g. Norwegian text can be input interactively (restricted to Latin 1 character set) or from a pipe or file (as UTF-8) without problems, and can be automatically translated (by the C i/o level) to UTF-16 encoding inside the program. However, I'm guessing that the C level input will garble e.g. Russian text no matter what one does, if one desires some Unicode based encoding inside the program. The Windows and Visual C++ support is just full of bugs -- e.g. as the crash of `more` showed in an earlier thread. Initialization of streams for the compromize scheme: static void msvcCompatibleInit() { struct Fix { static void mode( FILE* f, char const errorText[] ) { int const fileNo = _fileno( f ); bool const isConsoleInput = (f == stdin && _isatty( fileNo )); if( isConsoleInput ) { // Bytes are received as per the active codepage in the console. // Except if that active codepage is 65001, in which case non-ASCII // characters fail. Also, _setmode just causes non-ASCII fail. // // Setting the console codepage to 1252 might be practically helpful, // since cp 1252, Windows ANSI Western, is a superset of Latin 1 // which is a subset of Unicode. However, non-Latin 1 characters will // then be incorrect, just as with web pages in the old days. } else { int const newMode = _setmode( fileNo, _O_U8TEXT ); hopefully( newMode != -1 ) || throwX( errorText ); } } }; Fix::mode( stdin, "_setmode stdin failed" ); Fix::mode( stdout, "_setmode stdout failed" ); Fix::mode( stderr, "_setmode stderr failed" ); } Cheers & hth., - Alf

3 3

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards

1 0

[tree] more questions (was: [tree] associative containers)
by Cromwell Enage 03 Nov '11

03 Nov '11

From: Erik Erlandson > I'm not entirely sure about the relative merits of that versus defining > a parallel zoology of Hierarchical Containers that is basically > isomorphic to the traditional Container hierarchy, and leaving the > cursor definition more lightweight: perhaps just "iterator plus > parent(), begin() and end()", or alternatively not having a separate > cursor type, and simply having traditional iterators over children at > any given node. I'm curious as to what tree algorithms can take better advantage of the cursor interface as-is. Also: * What are the primary differences between a plain hierarchy and a multiway hierarchy? * Why shouldn't one assume that an on-top cursor is dereferenceable? TIA, Cromwell D. Enage

1 0

[tree] associative containers
by Cromwell Enage 03 Nov '11

03 Nov '11

I've been studying the tree proposal to see how I could write adaptors in my tree_node library (now at version 0.2 in the sandbox) that conform to the current concepts. Is there anything in the proposal that is analogous to a PairAssociativeContainer? My tree_node library defines an AssociativeTreeNode concept and a couple of models that I've found to be useful, e.g. for implementing decision tree learning algorithms. Cromwell D. Enage

2 2

[1.48][math] Permission to merge to release branch
by John Maddock 03 Nov '11

03 Nov '11

I'd like to merge this Clang fix to release if possible: https://svn.boost.org/trac/boost/changeset/75152 The change basically just moves code from one header to another, so it's defined at the point of first use. Thanks, John.

2 2

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 03 Nov '11

03 Nov '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros.hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

2 3

Boost.Algorithm design question
by Marshall Clow 03 Nov '11

03 Nov '11

So, what do people prefer (and why?): template<typename InputIterator, typename V> bool none_of_equal ( InputIterator first, InputIterator last, V const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } or template<typename InputIterator, > bool none_of_equal ( InputIterator first, InputIterator last, iterator_traits<InputIterator>::value_type const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } In the first case, I think there's (possible) conversion from V to iterator_traits<InputIterator>::value_type each time through the loop. In the second case, there is not. Of course, the (mythical?) smart compiler would do the conversion once and save the result for reuse. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

17 79

[1.48.0 Beta 1][fusion] MacTypes.h conflict with nil
by Jeff Flinn 03 Nov '11

03 Nov '11

reposted from "[1.48.0] Beta 1 is now available from SourceForge" thread for better visibilty. Mac 10.6 Xcode 3.2.6 gcc 4.2: In compiling our application, upgrading from boost_1_44_0 I get conflicts with MacTypes.h define of nil when compiling cons_fwd.hpp from fusion. Any thoughts? Jeff

3 3

Interest in boost.deepcopy
by Allan Johns 02 Nov '11

02 Nov '11

Just gauging initial interest in a boost.deepcopy library, analogous to deepcopy in python. Each type would register deepcopy behaviour with the library (there are similarities to boost.serialize). Boost.deepcopy would supply out-of-the-box registration for pod types, pointer types, arrays, stl containers and common boost containers. Example: template<typename T> void deepcopy(deepcopycontext& ctxt, const T& obj) { ...; } Why not use boost::serialize and serialize into memory then out again I hear you say? That's a great approach, but only when every object requires the same deepcopy behaviour (also, it's not too optimal). The problem is, I need specific behaviour in some types. Specifically, I need copy-on-write behaviour for a Buffer class that I'm using. For example: void deepcopy(deepcopycontext& ctxt, const Buf& b) { if(!ctxt.contains(&b)) { Buf b2(b); // doesn't copy the buf data, just holds a shared ptr internally. Data is only cloned when b/b2 is written to ctxt.insert(&b, b2); } } I attempted to model this a while ago using boost.serialize, but it turned out pretty clunky, I started needing a few decorator classes for special cases, etc. Apologies for the oversimplified examples above, just wanting to get interest in the jist of it. Please let me know if this overlaps with existing boost functionality also (I'm not aware of anything atm). Feedback appreciated. Thx, Allan

9 18

[ratio] Request for permission to merge to release branch
by Vicente J. Botet Escriba 02 Nov '11

02 Nov '11

Hi, I want to merge https://svn.boost.org/trac/boost/changeset/75240 to the release branch. The modifications are minor and correct to tickets: https://svn.boost.org/trac/boost/ticket/5724 and https://svn.boost.org/trac/boost/ticket/6082. Best, Vicente

3 3

[multi_array] Ticket#4874 "multi_array compile errors using Visual C++ 2010 in debug mode"
by Stephan T. Lavavej 02 Nov '11

02 Nov '11

Hi Boost devs, VC10 users are occasionally encountering https://svn.boost.org/trac/boost/ticket/4874 and reporting it to MS. For example, see http://connect.microsoft.com/VisualStudio/feedback/details/687655/compilati… where I've explained what's going on (I wrote this analysis back in Feb 2010 and I believe it's still correct): The problem is that multi_array iterators report themselves as input iterators, which can't be written to (e.g. as the destination of a copy()). Under IDL=0, copy() doesn't actually care how its destination iterator is marked with an iterator category tag, it just tries to write to the destination iterator, and that works. Under IDL > 0, copy() wants to know whether its source and destination iterators are both random-access, in which case it can perform a range check and unwrap the destination iterator for increased performance. It does this by overloading foo(input_iterator_tag, output_iterator_tag) and foo(random_access_iterator_tag, random_access_iterator_tag) and calling foo(category(source), category(destination)). If both source and destination are random-access, both overloads are viable (i.e. callable) and the second overload is preferred, so it's actually called. Otherwise, source is required to be at least an input iterator (maybe stronger) and destination is required to be at least an output iterator (maybe stronger) so the first overload must be viable and the second overload will be non-viable, so the first overload wins by default. However, if the destination is not marked as an output iterator or stronger, then the first overload is non-viable as well as the second, so overload resolution fails and boom. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer

2 1

boost mapped_file issue
by dophine 02 Nov '11

02 Nov '11

Hi all, I try to use memory map file. However, I don't know why the readsome return 0. It is fine if I use getline. int main(int argc,char *argv[]) { boost::iostreams::mapped_file_source source(argv[1]); boost::iostreams::stream<boost::iostreams::mapped_file_source> input(source); while(!input.eof()) { char b[1]; streamsize iRet = input.readsome(b, 1); cout << iRet << endl; cout << b[iRet]; } //std::string line; //while(std::getline(input, line)) { // std::cout << "Line: " << line << std::endl; //} return 1; } -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mapped-file-issue-tp3971495p397149… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[locale] Premission to merge clang bugfix changeset to release tree
by Artyom Beilis 02 Nov '11

02 Nov '11

Hello, I'd like to ask a permission to merge a changeset 75174 from trunk to release tree. It is a fix of build issue under clang-2.9 and clang-3.0. See: https://svn.boost.org/trac/boost/changeset/75174 The changeset itself: ------------------------- Index: /trunk/libs/locale/src/posix/codecvt.cpp =================================================================== --- /trunk/libs/locale/src/posix/codecvt.cpp (revision 73382) +++ /trunk/libs/locale/src/posix/codecvt.cpp (revision 75174) @@ -135,5 +135,5 @@ // maybe illegal or may be double byte - char inseq[3] = {seq0 , begin[1], 0}; + char inseq[3] = { static_cast<char>(seq0) , begin[1], 0}; char *inbuf = inseq; size_t insize = 3; ------------------------- It solves build issues as I can see at trunk tests. Thanks, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

[atomic] comments
by Tim Blechmann 01 Nov '11

01 Nov '11

hi helge and others, ... has been rather quiet about the boost.atomic review, so i want to raise a view issues: shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed? atomic::is_lock_free(): is_lock_free is set to either `true' or `false'. however in some cases, there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require a 64bit alignment). afaict there are not precautions to take care of this, are there? compile-time vs run-time dispatching: some instructions are not available on every CPU of a specific architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all ia32/x86_64 cpus. i would appreciate if these instructions would not be used before performing a CPUID check, whether these instructions are really available (at least in a legacy mode) cmpxchg16b: currently cmpxchg16b doesn't seem to be supported. this instruction is required for some lock-free data structures (e.g. there is a dequeue algorithm, that requires a pair of tagged pointers). maybe this can be a starting point to discuss boost.atomic ... cheers, tim

6 38

Re: [boost] [atomic] comments
by Helge Bahmann 01 Nov '11

01 Nov '11

> > > > > e.g. i would not trust on accessing sockets from a > > > > > real-time thread. > > > > > > > > what makes you believe that message channels in real-time systems > > > > were > > > > designed so dumb as to make them unusable for real-time purposes? > > > > > > life would be so much easier for me, if the users of my software would > > > not run on off-the-shelf operating systems ;) > > > > and what makes you believe that the performance characteristics of > > sockets in off-the-shelf operating systems is unsuitable for real-time, > > while the process scheduling characteristics of process scheduling in > > off-the-shelf operating systems is suitable for real-time? > > i cannot comment on windows, but both osx and linux provide ways to > schedule a thread at a priority that it won't be preempted by any other > thread, so the process scheduler won't interfere. that answers the second part but not the first (and is getting off-topic from atomic operations) > > > > right, but the standard implementation for gcc does not use a > > > > spinlock > > > > per object (see __atomic_flag_for_address) which turns all of this > > > > moot - there is NO guarantee for std::atomic to be safe > > > > interprocess, period> > > > > > > well, i'd say this is a problem of gcc's implementation of std::atomic. > > > this doesn't justify that boost.atomic does not follow the suggestion > > > of the standard. > > > > the standard says "should" not "must" -- the gcc guys have not made this > > decision without good reasons, and I agree with these reasons > > > > note that there is also trouble lurking with run-time selection of > > whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you > > really want to make this at minimum 12 bytes in size (though effectively > > occupying 16 due to alignment) just to save the room for the > > rarely-if-ever used per-object spinlock? same with atomic<128> and > > cmpxchg16b ? > > i don't really care about the size of an atomic<>. but I *do* care and believe it or not there are people writing applications that are memory-bound (doubling the overhead of the reference count in each of several millions of objects is *not* funny) > one other point for > runtime selection is compatibility. e.g. you may have two binaries, one is > compiled with support for double-width CAS, the other one without. with > compile-time dispatching the behavior would be undefined, with run-time > selection, it would be handled gracefully ... I don't quite understand the point -- quite obviously nothing good will happen if the applications do not agree on a protocol, and there is nothing that can be salvaged if they do agree on the objects being lock-free, fine if they do agree on the objects not being lock-free, well then explicit locking is faster anyways and you should use your "locked" reference implementation of the data structure that you surely wrote to run suitable regression tests of your lock-free data structure > > 2. What is wrong with implementing boost::interprocess::atomic<T> that > > specializes to boost::atomic<T> when possible and uses an interprocess > > lock otherwise? > > will you provide an implementation? people were asking for > boost::interprocess support during the boost.lockfree review. the only > missing feature is the atomic<> implementation. no problem Best regards Helge

1 0

[config] clang.hpp is not up-to-date
by Michel Morin 01 Nov '11

01 Nov '11

boost/config/compiler/clang.hpp is not up-to-date. For example, BOOST_NO_AUTO_DECLARATIONS is *always* defined (even if clang supports this feature). Is it worth fixing this on the release branch? P.S. I can make a patch, but before doing that I'd like to confirm whether __has_feature(cxx_auto_type) means that multi-declarator auto is supported or not. The following page says nothing about multi-declarator auto. http://clang.llvm.org/docs/LanguageExtensions.html Doug? Regards, Michel

3 4

Silly Boost.Locale default narrow string encoding in Windows
by Alf P. Steinbach 01 Nov '11

01 Nov '11

When I engage the compiler-in-my-mind to the example given at http://cppcms.sourceforge.net/boost_locale/html/ namely <code> #include <boost/locale.hpp> #include <boost/filesystem/path.hpp> #include <boost/filesystem/fstream.hpp> int main() { // Create and install global locale std::locale::global(boost::locale::generator().generate("")); // Make boost.filesystem use it boost::filesystem::path::imbue(std::locale()); // Now Works perfectly fine with UTF-8! boost::filesystem::ofstream hello("שלום.txt"); } </code> then it fails to work when the literal string is replaced with a `main` argument. A conversion is then necessary and must be added. It breaks the principle of least surprise. It breaks the principle of not paying for what you don't (want to) use. I understand, from discussions elsewhere, that the author(s) have chosen a narrow string encoding that requires inefficient & awkward conversions in all directions, for political/religious reasons. Maybe my understanding of that is faulty, that it's no longer politics & religion but outright war (and maybe that war is even over, with even Luke Skywalker dead or deadly wounded). However, I still ask: why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do it right, using the platforms' native encodings. Cheers, - Alf

9 43

[unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'
by Johan Lindvall 01 Nov '11

01 Nov '11

After trying out beta 1, I am seeing some failures with unordered containers, see attached file. Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 The code compiles without problems under 1.47.0. Unfortunately, I cannot yet publish the source code that triggers this problem. Any hints where to start investigating this? -- /Johan.

2 5

[multi_array] typed subarray from raw memory
by Maxim Yanchenko 01 Nov '11

01 Nov '11

Hi, While using multi_array, I found I frequently need a way to view some memory which is a multi-dimensional array and I don't know the type of the element, but I know its size and I know that this element has a member of the type I need (and I know the offset). So I need to be able to write something like struct A { double x, y; }; void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array_typed_view<A, NumDims> my_view(p, extents, el_size, offset ); and have a standard multi_array-compatible interface. Also, with existing multi_arrays of known types, this feature will give a way to create views of element's members (the closest we have now is a strided view but it only works if the element size is a multiple of the member size). I filed a Feature Request for multi_array (https://svn.boost.org/trac/boost/ticket/6073) but I wonder if there are any other possibilities around, and I'd also like to know what the community think of necessity of this feature. Thanks, Maxim

1 0