October 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

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

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

[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

[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

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

[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

[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

[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

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

[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

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

[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

[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

[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

Re: [boost] [Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Previously, I had posted what I thought was a bug. I did not think to do this originally, but I just tried a simple Hello World program that included boost/tokenizer.hpp. It compiled fine. I then looked at where the sample code was pulling headers from, and it appears that the download included old boost headers it was including instead of 1.47.0. I completley missed this. I apologize - and take back the error - there is none :) Thanks!

1 0

[Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Hi all, make[1]: Entering directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' mkdir -p build/Debug/GNU-Linux-x86 g++ -c -g -DPF_PLATFORM_LINUX -DAPR_DECLARE_STATIC -DAPU_DECLARE_STATIC -I../../include/ -I../../include/darwin86 -I.. -o build/Debug/GNU-Linux-x86/Path.o Path.cpp In file included from ../../include/boost/mpl/apply.hpp:23:0, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/bind.hpp:27:0, from ../../include/boost/mpl/lambda.hpp:18, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:18:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/bind.hpp:364:31: error: missing binary operator before token "(" ../../include/boost/mpl/bind.hpp:531:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:22:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/aux_/full_lambda.hpp:230:31: error: missing binary operator before token "(" In file included from ../../include/boost/iterator/iterator_facade.hpp:34:0, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply.hpp:138:31: error: missing binary operator before token "(" make[1]: *** [build/Debug/GNU-Linux-x86/Path.o] Error 1 make[1]: Leaving directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' make: *** [.build-impl] Error 2 I looked on the web, and everything that looks remotley like this said it was a problem with GCC > 4.4, but was fixed in boost 1.37. I have tried with both gcc 4.4.6 and 4.5.3. I don't think I am missing anything since it is just an include file, but I could be wrong. any help would be appreciated. I tried the boost users mailing list with no luck after a couple of days. This is a more detailed example - it looks as though the same problem repeats for many files. Would it be appropriate to file a bug if I can't find any answers here? Thanks!

1 1

[math][distributions] superfluous checking of parameters?
by Thijs (M.A.) van den Berg 31 Oct '11

31 Oct '11

The boost math distributions check validity of distribution the same parameters multiple times. E.g. in normal.hpp, class normal_distribution, the constructor, normal_distribution(RealType mean = 0, RealType sd = 1) : m_mean(mean), m_sd(sd) { // Default is a 'standard' normal distribution N01. static const char* function = "boost::math::normal_distribution<%1%>::normal_distribution"; RealType result; detail::check_scale(function, sd, &result, Policy()); detail::check_location(function, mean, &result, Policy()); } however, those are *again* checked in e.g. the pdf() non member function inline RealType pdf(const normal_distribution<RealType, Policy>& dist, const RealType& x) { ... if(false == detail::check_scale(function, sd, &result, Policy())) { return result; } ... } Why is that? It's done in a consistent way across all distributions. Can we remove the check inside the non member functions that are already checked in the constructor?

3 7

[proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Joel de Guzman 31 Oct '11

31 Oct '11

Hi, This code: #include <boost/spirit/include/qi.hpp> int main() { namespace qi = boost::spirit::qi; qi::rule<char const*> r; r %= (+qi::char_); return 0; } no longer works as expected. r %= (+qi::char_) becomes a no-op. Before it calls either: template <typename Expr> friend rule& operator%=(rule& r, Expr const& expr); // non-const version needed to suppress proto's %= kicking in template <typename Expr> friend rule& operator%=(rule& r, Expr& expr); Both defined in the rule class. Correct me if I'm wrong, but it seems the changes in proto forces us to support rvalue refs, but we are not ready for that yet and it's too late in the release cycle. Thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

4 4

[c++1] BOOST_NOEXCEPT macros?
by Beman Dawes 31 Oct '11

31 Oct '11

Since Boost already has BOOST_NO_NOEXCEPT and at least one compiler (GCC) supports C++11 noexcept, I'd like to start using it in Boost code. So how about a <boost/detail/noexcept.hpp> header with the usual boilerplate and this: #ifndef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_IF(Predicate) #else # define BOOST_NOEXCEPT no_except # define BOOST_NOEXCEPT_IF(Predicate) no_except(Predicate) #endif As was pointed out in a previous thread, there isn't any reliable C++03 alternative for either of these two, so nothing is attempted, and that's OK in C++03 code. We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it. Comments? --Beman

12 37

[interprocess] native Windows cond_var + mutex
by Dan Brown 31 Oct '11

31 Oct '11

Hi, Attached is a patch to implement interprocess_condition and interprocess_mutex natively on Windows. Following are some detailed notes. I hope this isn't too awkward of a time for a submission like this - I realize there's a lot of 1.48 activity going on. One more note about the patch - IIRC, some patch utils won't create directories. This patch is intended to be applied to boost/interprocess and relies on a new directory boost/interprocess/sync/win32. Background I started out by looking at http://www.cs.wustl.edu/~schmidt/win32-cv-1.html. This appears to be from the late '90s and is the basis for ACE's cond_var implementation. The solution in section 3.4 is arguably the most correct implementation. However, this solution relies on the atomicity of SignalObjectAndWait(). SOAW() may have been atomic for unicore systems common at the time but from what I've read is not atomic for multicore (it prevents context switches on a single core but ignores concurrent threads on other cores), and win32 documentation backs this up. While the paper argues that this leads to unfairness, I don't think the solution is correct without this atomicity. Wait/signal/wait problem One problem that I came across is what I'll call the wait/signal/wait problem. Setting the state, thread 1 is waiting on a condition and thread 2 has just completed cond_signal. Without an atomic SOAW(), thread 1 may release the external mutex without obtaining the associated semaphore. Another thread, thread 3, may obtain the external lock and find the cond_var signaled and behave correspondingly. This I believe is incorrect - a waiter which obtains the external mutex after the signaler has exited signal()should not find cond_var signaled. This situation is unlikely but it makes assumptions about the scheduler that I am not comfortable with. If there's a flaw in my reasoning hopefully someone will point that out. This solution This solution is structurally somewhat similarly to the paper's solution. One point to note is that notify_one()/signal() blocks on an event in the same manner as notify_all()/broadcast(). There may be a solution which does not block the signaler while wake-processing is occurring, but I saw additional complexity on that path and decided to forgo it for the time being. I hope the solution is correct but have only testing to validate. I haven't used any formal methods to back it up. Maybe I'll construct a Petri net sometime. That's always .. fun. I throw this solution on the mercy of the court. External mutex I have yet to see production examples of cond_var use where signalers do not hold the external mutex while they signal, but this use case is allowed by POSIX. My original solution (if it is in fact a solution) relies on some particular external mutex being held by all waiters and signalers for some particular condition variable. I recently added two mutexes to solve that situation but I have only minimal testing experience with that recent addition. Use of these new locks is demarcated with WIN32_POSIX_SEMANTICS. Interprocess vs. Intraprocess I'm not sure if there is support for process-specific synchronization objects in boost.interprocess, but if support is present or was added at some future time this could help optimize things for win32. At the moment win32 interprocess mutexes rely on assigning random names to mutexes (only named mutexes can cross platform boundaries in win32), and all mutex operations have to look up the mutex by this name. Interprocess seems to have been designed primarily with pthreads in mind, and things get a little awkward on Windows in this regard. Similarly, it would be nice to be able to use the native condition variables that win32 added for Vista+, but these can't be used across processes according to the documentation, and so can't be used AFAICT for inteprocess_condition. Correspondingly, an intraprocess_mutex would be able to forgo the win32 mutex name lookups. Miscellaneous Not all interprocess tests currently pass. There are some additional variations of mutex like the upgradable/sharable, etc., that I haven't looked at in detail. I'm hoping that this patch goes far enough that it'll have some momentum. I'm happy to either complete this work in the future or help whoever undertakes the task, but I may not be able to justify much of my time to the task in the short term to my employer. I realized a little too late that I didn't keep formatting entirely consistent with the existing code. Apologies. Hopefully it's only the opening block curlies. Thanks. Dan

3 13

[C++ Now! 2012] Call for Submissions
by Brian Wood 30 Oct '11

30 Oct '11

Hartmut Kaiser: > The C++ Now! Conference is dedicated to discussion and education > about C++, an open and free language and standard. It costs a lot to buy a copy of the standard now! Hope conference goes well and maybe I can attend someday. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

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

30 Oct '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.

1 0

[C++ Now! 2012] Call for Submissions
by Hartmut Kaiser 30 Oct '11

30 Oct '11

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program available): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit Presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Re: [boost] Silly Boost.Locale default narrow string encoding in Windows
by Daniel James 29 Oct '11

29 Oct '11

On Saturday, 29 October 2011, Peter Dimov wrote: > > > The "dir" command has no problem displaying arbitrary file names directly > to the console (presumably via WriteConsoleW), but once it has to write to > a file, it needs to convert to narrow and no code page other than 65001 can > express the above file name. > This is not that relevant to the wider issue, but wide streams will work for console output if you first do this: if (_isatty(_fileno(stdout))) _setmode(_fileno(stdout), _O_U16TEXT); if (_isatty(_fileno(stderr))) _setmode(_fileno(stderr), _O_U16TEXT); i.e. set the output mode to UTF-16 when writing to the console. This only works for recent versions of Visual C++. Obviously doesn't fix piped output.

3 2

[1.48.0.beta 1][interprocess] detail namespace
by Jan Boehme 28 Oct '11

28 Oct '11

Hi, is the change of the name of the namespace 'detail' to 'ipcdetail' intended to be in the release? Isn't it over-qualified as it is located in the the namespace 'boost::interproces' anyway?. Btw it breaks our code and should mentioned in the release notes of the library. Thanks for reading, Jan.

4 6

[filesystem and beyond] Narrow strings be UTF-8
by Yakov Galka 28 Oct '11

28 Oct '11

On Wed, Oct 26, 2011 at 22:13, Beman Dawes <bdawes(a)acm.org> wrote: > (2) V3 may work OK with the Microsoft 65001 UTF-8 codepage, although > I've never used it myself and you would have to pass in a UTF-8 > encoded narrow character name. > If it had been possible, it would simplify everything. Unfortunately, you cannot set UTF-8 codepage for windows API functions (you can for the console though). Microsoft isn't interested in making portability easier, so I don't see them adding the support in the nearest future. But they could. UTF-8 should be considered as the only default narrow encoding on windows, because all other ANSI encodings are not unicode-aware. On Wed, Oct 26, 2011 at 22:47, Beman Dawes <bdawes(a)acm.org> wrote: > On Wed, Oct 26, 2011 at 6:24 AM, Yakov Galka <ybungalobill(a)gmail.com> > wrote: > > [...] > > Even if you fix the Unicode problems, > > What Unicode problems are you running into? Although there are some > locale related tickets outstanding, I'm not aware of any Unicode > issues. > 1) The one that was brought up in the previous thread. 2) The complexity of writing portable unicode-aware code: currently you're forcing me to a) use wstring on windows, or if I prefer to use my favorite portable UTF-8 encoded strings b) write all the boilerplate code that passes codecvt everywhere as a parameter (see below why ¬imbue()). In both cases you're shifting the complexity to the higher-level code. It's not a kind thing for you as a low-level library developer to do, The library is expected to ℍ𝕚𝕕𝕖 the platform differences by providing a uniform interface. ⇒ Myth: Using the native encoding on each platform results in portable code. ‽ In some definition of 'portable' definitely yes. But not when things are shared among different platforms. It starts with files transferred between different systems and ends with the source code itself (there is a different between "" and L""). Uniformity == simplicity. Consider a simple case of loading a path from some project file and loading the referenced file: The project file is encoded in UTF-8 making it portable among all systems with CHAR_BIT == 8. // Option a) #include "codecvt_implementation.h" std::basic_ifstream<native_char> fin("project.file"); std::basic_string<native_char> str; fin.imbue(locale(fin.getloc(), new utf8_to_native_codecvt())); getline(fin, str); fs::ifstream fin2(project_path/str); // Option b) #include "codecvt_implementation.h" std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(fs::path(project_path).append(str, utf8_to_native_codecvt())); // c) How it could be done std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(project_path/str); ⇒ Use boost⸬filesystem⸬imbue to convert b to c. ‽ Who is responsible for calling imbue()? I'm writing library code. I'm not allowed to change the global-state. ⇒ This code will break: int main(int argc, char* argv[]) { fs::ifstream fin(argv[1]); } ‽ It works fine for ASCII characters on all sane platform. For non-ASCII, I don't care. It's already not unicode-aware if the native encoding is not UTF-8 (which can't be so on Windows). If the writer of this code really cares about internationalization, she can use boost⸬program_options (assuming it's also changed to follow the UTF-8 convention). Otherwise she's a hypocrite. ⇒ UTF-8 is slow. ‽ Compared to what? You haven't measured this. On windows: we must do complicated operations on paths before we pass them to the OS anyway (system_complete, prepend \\?\). Most of the strings contain ASCII characters so std::strings take less memory, thus decreasing cache thrashing in other parts of the program. On other OSes: the encoding is already almost always UTF-8. Experience shows that the small overhead (if it's an overhead at all) is not the bottleneck. Many cross-platform libraries already switched to UTF-8 for narrow-chars (see one of the previous discussion for a list), and I don't see a reason why boost can't be the next. -- Yakov

2 1

Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
by Alf P. Steinbach 28 Oct '11

28 Oct '11

First, apologies if I'm posting to the wrong group/list; if so then please redirect me. IMHO access to files is a crucial part of Boost.Filesystem. However, with Boost 1.47, and using g++ 4.4.1 in Windows 7, boost::filesystem::ifstream etc. fail to open or create files with non-ANSI characters. It works fine with Visual C++; it FAILS with g++ 4.4.1, which is the one bundled with the Code::Blocks IDE. The failure probably has nothing to do with the g++ version: it's due to g++ not offering the Visual C++ wchar_t oriented extensions to the standard iostreams (Boost.Filesystem uses these Visual C++ extensions). I stumbled onto this while I was writing about using Unicode in C++ programming in Windows. I wrote up a technical solution in section 5, starting on page 16, of that work-in-progress document, available on Google Docs at: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B2oiI2re… Essentially, the fix I ended up with, full source code given in the above doc, uses Windows short file names if (1) there is no wide character support and if furthermore (2) the filename can't be perfectly translated to ANSI. The C++ implementation's support for wide chars is automatically detected using C++98-compatible code. I do not know what to do with this. But considering that Boost.Filesystem is slated for later inclusion in the C++ standard library (or at least into TR2), I think it would be nice if it is able to give access to all accessible files in Windows, also with g++, so that we don't end up with a file handling part of the standard library that can't handle files in general; hence this posting and plea for advice -- what more should I do, if anything? Cheers, - Alf

10 24

Re: [boost] [1.48.0] Beta 1 is now available from SourceForge
by Martin Elzen 28 Oct '11

28 Oct '11

Okay, I gave compiling the beta 1 another shot, as follows: ./bootstrap.sh --prefix=/home/martin/app/boost/installation --with-icu=/home/martin/app/icu/installation ./b2 -sICU_PATH=/home/martin/app/icu/installation install >out.b2.install 2>&1 & the b2 output then does start as follows: Performing configuration checks - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes ... but then later on there are compilation errors in Boost.Locale, such as: > In file included from libs/locale/src/icu/formatter.cpp:25:0: > libs/locale/src/icu/predefined_formatters.hpp: In member function ‘icu_48::NumberFormat* boost::locale::impl_icu::icu_formatters_cache::number_format(boost::locale::impl_icu::icu_formatters_cache::fmt_type) const’: > libs/locale/src/icu/predefined_formatters.hpp:127:61: error: ‘URBNF_SPELLOUT’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:127:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:49:5: note: ‘icu_48::URBNF_SPELLOUT’ > libs/locale/src/icu/predefined_formatters.hpp:130:61: error: ‘URBNF_ORDINAL’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:130:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:50:5: note: ‘icu_48::URBNF_ORDINAL’ > > "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_LOCALE_DYN_LINK=1 -DBOOST_LOCALE_NO_WINAPI_BACKEND=1 -DBOOST_LOCALE_WITH_ICONV=1 -DBOOST_LOCALE_WITH_ICU=1 -DBOOST_THREAD_NO_LIB=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -I"/home/martin/app/icu/installation/include" -c -o "bin.v2/libs/locale/build/gcc-4.6.1/release/threading-multi/icu/formatter.o" "libs/locale/src/icu/formatter.cpp" The above errors are probably caused because I did what ICU recommends you do (for the first time ever), which is: -# define U_USING_ICU_NAMESPACE 1 + // Set to 0 to force namespace declarations in ICU usage. +# define U_USING_ICU_NAMESPACE 0in the ICU unicode/uversion.h file The above is advised in ICU 's readme.html in the How To Build And Install ICU / Recommended Build Options section... Has that advice become incorrect in recent ICU versions, perhaps?

1 0

[1.48.0] Beta 1 is now available from SourceForge
by Beman Dawes 27 Oct '11

27 Oct '11

Boost release 1.48.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.48.0.beta.1/ This release includes 3 new libraries (Container, Locale and Move), an extension to TypeTraits to support operator detection as well as updates to many existing libraries. For partial details of what's in the release, see http://beta.boost.org/users/history/version_1_48_0.html. This page is still in process of being updated, and there are some known issues with links. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

4 5

[1.48.0] Beta 1 release candidates available
by Martin Elzen 27 Oct '11

27 Oct '11

Beman Dawes <bdawes(a)acm.org> wrote: > 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. On Ubuntu 11.10 amd64 with g++ (and gcc) 4.6.1, I built ICU 4.8.1 with almost all default options except for specifying a non-default installation dir. Then I created the LD_LIBRARY_PATH environment variable and set it to the lib dir of that new ICU installation *but did not* also create an ICU_PATH environment variable. Then I ran the boost bootstrap.sh script with a '--with-icu=/home/martin/app/icu/installation' parameter. The output of the b2 contained (among other things) the following bits about ICU: - has_icu builds : yes ... - icu : no - icu (lib64) : no Which led me to expect that the boost regex libs would end up referencing the Ubuntu default ICU libs (which was not what I wanted to do). But they didn't, instead they *did* correctly reference the newly built ICU libraries (or at least that's how I'm interpreting the output of ldd against libboost_regex.so ). Which is nice, but doesn't that also mean that the docs in Boost regex about the ICU_PATH environment variable might need some revision? Or did I just luck out somehow?

4 3

[interprocess] native Windows cond_var + mutex
by Dan Brown 27 Oct '11

27 Oct '11

Informed the previous patch was removed. Attaching patch without .zip.

1 0

[parameter] non-type template params
by lcaminiti 26 Oct '11

26 Oct '11

Hello all, Does Boost.Parameter support named parameters for non-type template parameters? For example, can I use Boost.Parameter on all the template parameters below including default_value? template< typename Value, Value default_value = Value() > class none { ... }; >From the docs, it seems that this is not possible but I might be missing something: http://www.boost.org/doc/libs/1_47_0/libs/parameter/doc/html/index.html#par… Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-non-type-template-params… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[atomics] Short review
by Phil Endecott 26 Oct '11

26 Oct '11

Dear All, Apologies for not having time to write a proper review for this important library. However, I have previously looked at this code in some depth, and I am using it in a number of shipping products. Based on that, I am reasonably confident that it is useful and functional. As others have said, the documentation needs some attention. In particular, I missed information about supported platforms and types. Users can reasonably ask whether a particular type is supported natively or whether a fallback is used, and what the fallback is. A link to the std::atomic spec (or a freely-downloadable draft of it) would also be useful. I believe that this is a vitally important and long-overdue library that should be accepted without delay. Regards, Phil.

1 0

Re: [boost] [interprocess] submission
by Stewart, Robert 25 Oct '11

25 Oct '11

Dan Brown wrote: > Christian Holmquist wrote: > > > > I have a question about submissions. I have an > > > enhancement, not a fix, for boost::interprocess (win32 > > > native mutex and condition variables as an alternative to > > > emulation). Ok to just submit the zip or should I open a > > > ticket first? > > > > see: > > http://www.boost.org/community/policy.html#effective > > > > i.e., include [Interprocess] in the email topic so maybe the > > maintainer will read it. > > Helpful, thank you. Another question. Not only is it helpful, it just might get you a useful answer to your query, which I'll leave to Ion. Consequently, I added it for you. > I may not be able to justify to my employer completing the work > to the satisfaction of all tests. For example, I don't have a > working win32 native implementation of sharable and sharable- > upgradable mutexes (aka read-write locks, I believe). Is it > worth submitting in such a state in hopes others might be able > to contribute, or should I hold off until I have time implement > these and get all tests working? I suspect the answer will be that offering something, even if not everything, will be helpful. Nevertheless, you need Ion to respond. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[signals2] 'static initialisation fiasco' issues
by elpidio valdez 25 Oct '11

25 Oct '11

I am trying to build a modular system in which independently compilable cpp files communicate by signals, but otherwise know nothing about each other at compile time. e.g. #include "TheRangeFinderSignals.h" #include "TheProximitySensorSignals.h" class TerrainMap { ....connect to signals and send signals.... } TheSingletonTerrainMap; This all works very well except that TerrainMap needs to connect to signals from its constructor. The signals are static global objects which serve to exchange data between the independent modules. Unfortunately I have fallen foul of C++ static initialisation problems. I cannot be certain that the static signal objects will be created before the modules that use them. The C++ FAQ recommends wrapping the static variables in a function: e.g. EventSignal<void (Gray16Image)> &OnNewDepthFrameAvailable() { static EventSignal<void (Gray16Image)> *zzz = new EventSignal<void(Gray16Image)>; return *zzz; } This works but it is syntactically messy to use. All uses of OnNewDepthFrameAvailable must be replaced with OnNewDepthFrameAvailable(). i.e OnNewDepthFrameAvailable().connect(...) OnNewDepthFrameAvailable()(theNewFrame); Is there any way to avoid this ? It is not easy to hide the detail. I wanted to define a template class to encapsulate the idiom and eliminate the need for the extra parenthesis. e.g. SafeStatic< EventSignal<void (Gray16Image)> > OnNewDepthFrameAvailable; template<type T> class SafeStatic { T *obj; void operator()(theArgsToSignal) { if (!obj) obj = new T; obj(theArgsToSignal); } }; The problem is that the Signal template defines a variable arity and signature operator(). I have no idea how to provide the same signature on the function call operator of SafeStatic Any other way around this problem ?

2 1

submission
by Dan Brown 25 Oct '11

25 Oct '11

Hi, I have a question about submissions. I have an enhancement, not a fix, for boost::interprocess (win32 native mutex and condition variables as an alternative to emulation). Ok to just submit the zip or should I open a ticket first? Thanks. Dan Brown

3 3

[bind] placeholders in namespace ::
by lcaminiti 25 Oct '11

25 Oct '11

Hello all, Do you know in which namespace Boost.Bind placeholders are actually defined? #include <boost/bind.hpp> #include <iostream> void f ( int a, int b ) { std::cout << a << " " <From the example above, the docs, and the source code, I am pretty sure Boost.Bind placeholders are defined in the unnamed namespace :: ... why? Isn't it a bad practice for a library to pollute the unnamed namespace? Thanks for the clarification. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bind-placeholders-in-namespace-tp3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Status of boost::make_shared_array
by Olaf van der Spek 24 Oct '11

24 Oct '11

Hi, What's the status of boost::make_shared_array? I've seen some discussion from 2009, but it's almost 2012 now and it doesn't appear to be available. Greetings, Olaf

2 11

[atomic] [review] Atomic Review
by Stewart, Robert 24 Oct '11

24 Oct '11

Boost.Atomic should be included in Boost. - What is your evaluation of the potential usefulness of the library? Providing C++03 support for the new atomics functionality will prove immensely useful. It would be even more useful if it could be provided as a portability layer for environments with both C++03 and C++11 compilers. That is, if one could use boost::atomic to get Helge's implementation on C++03 compilers and std::atomic on conforming C++11 compilers, without needing to change code, this library would be ideal. That might require changes to the current implementation, but seems unlikely to break code using the current release. - What is your evaluation of the design? The design is largely fixed since it is standardized. I was put off initially that the names appear in namespace boost rather than, say, boost::atomics, but since this is intended to provide *the* Boost implementation of C++11 functionality, I don't expect there to be any competitors. That said, s/boost::atomic/std::atomic/ is no simpler a change than s/boost::atomics::atomic/std::atomic/ to make in the future. - What is your evaluation of the implementation? I'll leave most comments on this to those with more experience. However, I'm positive that any issues will be addressed quickly as more eyes are drawn to the implementation, so even if there are present issues, they should not preclude acceptance. I think the fallbacks, in lines 22-77 of atomic.hpp, would be better in a separate file such as boost/atomic/fallbacks.hpp or even just at the end of boost/atomic/platform.hpp. It would remove clutter from atomic.hpp. I would expect a different conditional compilation structure in platform.hpp would be easier to follow and maintain: // Compiling with GCC #if defined __GNUC__ # if defined __i386__ || defined __x86_64 # include <boost/atomic/detail/gcc-x86.hpp> // etc. # else # include <boost/atomic/detail/gcc-cas.hpp> # endif // How about ARM on Linux? #elif defined __linux__ && defined __arm__ # include <boost/atomic/detail/linux-arm.hpp> // Use Windows Interlocked* APIs? #elif defined BOOST_USE_WINDOWS_H || defined _WIN32_CE... # include <boost/atomic/detail/interlocked.hpp> #endif Shouldn't BOOST_ATOMIC_ADDRESS_LOCK_FREE be named "BOOST_ATOMIC_POINTER_LOCK_FREE"? The directory layout is a little odd. I'd have expected boost/atomic/platform.hpp to be boost/atomic/detail/platform.hpp. That, of course, leaves nothing in boost/atomic. However, if namespace atomics is added, then boost/atomic.hpp, if retained, can just include boost/atomics/atomic.hpp, the latter containing the content presently in boost/atomic.hpp. - What is your evaluation of the documentation? As usual, I have numerous detailed comments which I've addressed at the end. The documentation should include some links to suitable background material for those not "already...familiar with concurrency in general, as well as elementary concepts such as 'mutual exclusion'". Information on the section(s) of the C++11 standard that are and aren't part of the library would be beneficial. Generally, the explanations assume too much familiarity with the material with no pointers to resources to bridge the gap. I've given one, specific suggestion in my detailed comments below on what I'd like to see in the Usage examples section. It may be that more thorough descriptions are the province of books and that it is fair for Boost.Atomic to assume a good deal -- as does the C++11 standard. Nevertheless, I'd prefer to see more in the documentation. I was hoping that Boost.Atomic would provide a bridge to C++11 by engaging platform-supplied atomic support when available so that I wouldn't have to do that work. However, since that is not available, the documentation should make that clear. - Did you try to use the library? With what compiler? On which platform? Did you have any problems? I wish I could say yes, but the team I was hoping to get to use the library opted for a safer, more expedient solution to their present issues than adopting a new library. I haven't had an independent opportunity. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a lot of time reviewing the documentation and a little looking over the code. - Are you knowledgeable about the problem domain? Sadly, I'm not nearly as knowledgeable as I should be. I'm working on that and Helge has actually been very helpful in answering specific issues I've had with other's code, so I'm comfortable trusting his knowledge. ___________________________________ Detailed Documentation Comments _________________________ Introduction _______________ Presenting Boost.Atomic s/these data types/them/ s/"emulating"/emulating/ _______________ Purpose The following change avoids the non-word "sequentialized" and should prove clearer: s/each operation behaves as if it were strictly sequentialized/the operation is executed as if no other thread were attempting to do the same/ The bulleted list would read better as follows. I eliminated, "custom coordination protocols", because that confuses rather than helps. "Atomic variables are useful as: - a means to coordinate multiple threads - faster alternatives to lock-based access to simple variables" _________________________ Thread coordination using Boost.Atomic s/accesses of threads to shared variables/threads accessing shared variables/ s/the cache hierarchies /cache hierarchies/ s/above one/above/ Presumably, a "fully formalized definition" of "happens-before" is in the C++11 standard, so the reader should be referred to the appropriate section thereof. The structure of this page seems broken. I'd expect the following: Coordination using happens-before Using mutual exclusion Using release and acquire Using fences Coordination of dependent data access Coordination using sequential consistency _______________ Enforcing happens-before through mutual exclusion s/If this is be thread1/If thread1 succeeds first/ s/Obviously cannot state/There is no way to determine/ s/either one/either option/ _______________ happens-before through release and acquire s/semantic/semantics/ s/the value this value/the value/ s/the same atomic/the *same* atomic/ s/avenues for/orders of/ s/hold: thread2/hold because thread2/ The presentation of the possible outcomes is not as clear as it could be. I suggest something like the following: "There are two possible orders in which the atomic operations can occur: "1. thread1 stores a new value in a before thread2 loads a's value. Since a has been incremented to 1, thread2 will execute B. All of the listed criteria are satisfied, so 'A _happens-before_ B' holds. "2. thread2 loads a's value before thread1 stores a new value. Given that a is initially zero, thread2 will execute C. Since thread1 did not first store a new value in a with release semantics, the criteria listed above are not satisfied, so 'A _happens-before_ C' does *not* hold." _______________ Fences The phrasing in the first paragraph is a bit less clear than it could be. Try the following: "...in conjunction with preceding (for acquire or consume), succeeding (for release), or both (for seq_cst) atomic operations." The use of memory_order_relaxed, in the example, should be called out. s/in the case C is executed/when C is executed/ _______________ happens-before through release and consume s/uses release and consume/uses release and consume semantics/ s/coordination: If/coordination. If/ s/semantic/semantics/ s/the value this value/the value/ s/the same atomic/the *same* atomic/ s/value of the atomic variable/value of that atomic variable/ s/avenues for/orders of/ s/hold: thread2/hold because thread2/ s/accesses (presumable writes) to/accesses of (presumably writes to)/ s/accesses (presumably reads) to/accesses of (presumably reads from)/ s/by thread2: Lacking/by thread2. Lacking/ s/Note that in this example, the fact that/Note that/ The following would be clearer for the explanation: "There are two possible orders in which the atomic operations can occur: "1. thread1 stores a new value in a before thread2 loads a's value. In this case, since a has been set to 1, thread2 will use 1 as the value of index to execute B. All of the listed criteria are satisfied, so 'A _happens-before_ B' holds. "2. thread2 loads a's value before thread1 stores a new value. In this case, thread2 will execute B with index set to 0, which is not the value (yet to be) set by thread1. Since thread1 did not first store a new value in a with release semantics, the criteria listed above are not satisfied, so 'A _happens-before_ B' does *not* hold." Your statement that the second example in this section is erroneous lacks an explanation. Presumably, the problem stems from the conditional branch, but an explanation is needed. _______________ Sequential consistency s/coordination: If/coordination. If/ This section deserves example code and an explanation: thread1: ...; /* A */ atomic_thread_fence(memory_order_seq_cst); ...; /* B */ thread2: ...; /* C */ atomic_thread_fence(memory_order_seq_cst); ...; /* D */ "There are two possible orders of execution of that code: "1. thread1 assigns to a before thread2 assigns to b. A _happens-before_ D. Whether A _happens-before_ C is not known. "2. thread2 assigns to b before thread1 assigns to a. C _happens-before_ B. Whether C _happens-before_ A is not known. "The fences could have been operations on the same or different atomic variables. All that matters is that memory_order_seq_cst be the memory order in each case." _________________________ Programming interfaces This section would be better formatted as in, for example, http://www.boost.org/doc/libs/1_47_0/libs/regex/doc/html/boost_regex/ref.ht…. _______________ Memory order The table formatting is confusing, at least without any borders between the cells. Add internal borders or align the constants to the top of their cell. Using a table may be faulty anyway. It would probably be simpler to define each in a separate paragraph. s/informally speaking/informally/ memory_order_relaxed: The description is hard to read. This should be better: "Informally, operations following the atomic operation may be ordered before it and operations preceding it may be ordered after it. This constraint is only suitable in two cases: when further operations do not depend upon the outcome of the atomic operation or ordering is enforced separately by atomic_thread_fence operations." (Notice that the final period is missing in your version.) memory_order_release: Rephrasing would add a bit of clarity: "Informally, all memory operations preceding the atomic operation may be reordered after, but not before, it." memory_order_acquire: s/succeeding/following/ (for consistency). Rephrasing would be helpful: "Informally, all memory operations following the atomic operation may be reordered before, but not after, it." memory_order_consume: s/restrictive/limited/. Rephrasing: "Similar to memory_order_acquire, except that only memory operations following the atomic operation that are _computationally-dependent_ (this should link to a definition!) on the value retrieved from the atomic variable, are order restricted." memory_order_acq_rel: s/operation/operations./ memory_order_seq_cst: s/additional enforces/additionally enforces a/, s/such qualified/so qualified/ s/section happens-before for explanation/happens-before for explanations/ _______________ Atomic objects s/template class/class template/ _____ boost::atomic<T> template class s/objects supports/objects support/ s/new value to atomic variable/new value/ The descriptions are weak, since they don't refer to the order argument(s). Describing the three- versus four-argument compare_exchange function differences in a subsequent paragraph is less helpful. A footnote reference, with a link, to that explanation would be fine, however. Also note that the success/failure ordering behavior deserves more explanation. Why is it useful or important? Who should care? Even if you think the assignment and conversion operators should be avoided, they should be documented. What's more, I disagree with your rationale. Those operators imply memory_order_seq_cst. If that's what a user wants -- and that's usually the case -- why not use the syntactic sugar? You can state your case as, "When specifying memory ordering, other than memory_order_seq_cst, for some atomic operations, specify them for all, rather than using the assignment and conversion operators, to make all of the operations clear." No mention of the default for the order argument. _____ boost::atomic<integral> template class The descriptions are inconsistent with those of the previous section. For example, a consistent description for fetch_add() would be, "Add v to current value, returning current value." Bitwise operations are typically capitalized. Thus, "bitwise AND". s/always has memory_order_seq_cst as default parameter/is defaulted to memory_order_seq_cst in each case/ Same argument regarding the operators as for the previous section. _____ boost::atomic<pointer> template class s/all atomic object/boost::atomic<integral> objects/ The descriptions are inconsistent with those of the initial section. s/always has memory_order_seq_cst as default parameter/is defaulted to memory_order_seq_cst in each case/ Same argument regarding the operators as for the previous section. _______________ Feature testing macros s/detection whether/detection of whether/ s/"true"/lock-free/ s/operations, or whether/operations or whether/ s/"lock"/lock/ s/signed\/unsigned/unsigned/ (except for BOOST_ATOMIC_CHAR_LOCK_FREE) _________________________ Usage examples There should be an introductory paragraph for this section. Try the following: "This section shows non-trivial examples of using Boost.Atomic to implement common mechanisms using atomics. These might be considered advanced tutorials or, perhaps, reference implementations." _______________ Reference counting You should reference some external source to discuss the idea behind and uses of reference counting, such as http://en.wikipedia.org/wiki/Reference_counting. s/reference counter/reference count/ You should clarify what you mean by, "passing an existing reference from one thread to another must already provide any required synchronization." I presume you mean that the old thread must not release its reference count on the object, so it won't be released, before the new thread can increment the reference count. s/must obviously happened/obviously must have happened/ You don't explain why the acquire fence is needed. I started to write why the release semantics were needed for the decrement, but found I couldn't figure out how to say it, which means I'm not entirely sure I understand it either. Every time I think I get the details of these things, I find that I'm somehow not quite clear. Thus, your explanation needs to be clearer. However, after thinking things over at some length, I think I have it and will give the explanation a try anyway: "If a thread is trying to increment the reference count, there's no contention. The increment is atomic and doesn't need to impose ordering on intrusive_ptr_release(), because there must be a valid, existing reference, thereby ensuring the reference count will be at least zero, regardless of the order between intrusive_ptr_release() and intrusive_ptr_add_ref() calls. That's why intrusive_ptr_add_ref() uses memory_order_relaxed. "If a thread is trying to decrement the reference count, it might be decrementing the value to something greater than zero. In that case, all that's important is that the decrement be atomic to prevent races between threads. However, if the reference count is decremented to zero, then no other thread can have a valid, outstanding reference. That implies that there can be no race in comparing the value returned by fetch_sub() (which returns the original value) with 1. If fetch_sub() returns 1 (meaning the reference count is now zero), then, and only then, must x be deleted. Thus, a memory_order_acquire fence is used to ensure that the delete expression is not reordered ahead of the fetch_sub() call." That sort of analysis, in which each of the various execution orders and use cases are examined and discussed, is necessary to grasp this stuff. Perhaps you'd rather that be left to book authors, but I don't think it's too much to ask in this context. _______________ Spinlock You should reference external information on spinlocks to guide readers to their appropriate uses, particularly in light of your warning to understand the consequences of their use. s/"happens before"/_happens-before_/ This example deserves a good explanation of the busy-wait loop and why acquire and release semantics are used in each case. Last paragraph: punctuation and wording problems. I suggest this instead: "This 'optimization' is actually useless and may be harmful. Since threads can be spinning busily on a locked spinlock, it doesn't matter whether CPU cycles are wasted with 'exchange' and 'acquire' operations or with just 'exchange' operations. Furthermore, a tight 'exchange' loop, without any memory-synchronizing instruction introduced by an 'acquire' operation will, on some systems, monopolize the memory subsystem which degrades the performance of other activities." _______________ Singleton with double-checked locking pattern This section should refer to external references on the Singleton Pattern and the Double-checked Locking Pattern, particularly with details on the problems with the DCLP. 1st para, 2nd sentence: change to read, "instance must ensure that creating the instance in one thread _happens-before_ any dereferences of the pointer in other threads." That avoids referring to "happens after" which you've not discussed in the documentation. The explanation of the implementation should be more detailed. _______________ Wait-free ring buffer s/one single/one/ or s/one single/a single/ s/without any locks/without locks/ s/"wait-free" which/"wait-free", which/ The code requires a great deal more explanation. Each ordering constraint should be discussed. Places where others have made mistakes might be worth mentioning as "anti-examples". Avoid the use of "happens after" since you don't discuss it anywhere. _______________ Wait-free ring buffer s/"happens before"/_happens-before_/ The code requires a great deal more explanation. Each ordering constraint should be discussed. Places where others have made mistakes might be worth mentioning as "anti-examples". _________________________ Limitations s/Advise/Advice/ or s/Advise/Recommendation/ In the second bullet, you assume that the reader understands "computation-dependency" and "control-dependency" but I doubt that fits within the expected knowledge claimed in the Introduction. _________________________ Porting _______________ Unit tests "For example" and, consequently (to my mind, anyway) "e.g." should be set off by a comma. (This probably applies elsewhere.) s/returing/returning/ s/behave atomic as appropriate/behave atomically as expected/ _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

[1.48] Release notes
by Daniel James 24 Oct '11

24 Oct '11

Hi, Sorry this is a bit late, I would normally have mostly sorted out the release notes by now. You can add your changes to the release notes by editting the file in the beta repository at: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… I've added a few libraries already, but feel free to change them if I've got them wrong. Most of the links don't work because the beta documentation will only be uploaded after the beta release. If you want to update the site (if you don't, I'll do it so this is optional), you need to check out the whole site and a quickbook executable in your path. Then run the script at 'site-tools/update.py' using python 2.5 to 2.7. Check in the changes to the site (including rss feeds and changes to 'site-tools/state/feed-pages.txt'). If anything goes wrong, just check in your changes to the quickbook file and let me know - the site update script has only been used by me, so I'm not sure how well it'll work for others. If it works well, the idea is to put the beta notes on the live site for future release - I'll make their status a bit clearer before doing that. Alternatively, you can just email me your changes and I'll make them. thanks, Daniel

5 6

[math] potentian bug: iround throws, given double( numeric_limits<int>::min() )
by Krzysztof Czainski 24 Oct '11

24 Oct '11

Hello, The docs of the Rounding Functions say: If the argument v is either non-finite or else outside the range of the result type, then returns the result of rounding_error: by default this throws an instance of boost::math::rounding_error. So the example shown below seems to show a bug, since std::numeric_limits<int>::min() is *not* outside the range of int. Or did I miss something? <code> #include <boost/math/special_functions/round.hpp> #include <cassert> #include <limits> int main() { int const i = std::numeric_limits<int>::min(); double const x = i; assert( i == boost::math::iround(x) ); } </code> Regards Kris

3 16

[gil][io_new] Image Reading and Writing Iterator
by Christian Henning 24 Oct '11

24 Oct '11

Hi there, one of the requirements for the acceptance of io_new as the new io extension for gil is the ability to read and write images in more then one step. For that the current state of an operation has to be cached. I have created some meta functions that give access to io_new's reader and writer classes. Right now, it still is very preliminary. I would like to ask the community how I could create an read_iterator and write_iterator classes which users could use to iterate over very large images. I know there are some specific iterator libs in boost but I'm just clueless in how to use let alone be able to come up with an implementation that will be released by boost. Any help would be very welcome! Thanks, Christian

3 3

[1.48.0] Schedule heads up
by Beman Dawes 24 Oct '11

24 Oct '11

branches/release for 1.48.0 is long since closed for new libraries. October 10: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj --Beman

11 45

[Review] Boost.Atomic review starts today, October 17th 2011
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th. I encourage everyone to participate the the discussion on the Boost mailing list about this very important library. In addition the code can be reviewed line-by-line in code collaborator (http://demo.smartbear.com/boost/) About Boost.Atomic: Boost.Atomic is a library that provides atomic data types and operations on these data types, as well as memory ordering constraints required for coordinating multiple threads through atomic variables. It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature. Tarball: http://www.chaoticmind.net/~hcb/projects/boost.atomic/boost.atomic.tar.gz Documentation: http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/index.html Please always state in your review, whether you think the library should be accepted as a boost library! Additionally please consider giving feedback on the following general topics: - 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? On which platform? 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? Cheers, Tim Review Manager

6 11

Re: [boost] [property_tree] include directive for non-info files
by Ivan Le Lann 24 Oct '11

24 Oct '11

----- "Sebastian Redl" <sebastian.redl(a)getdesigned.at> a écrit : > On 29.09.2011 16:18, Ivan Le Lann wrote: > > Hi, > > > > In Boost.PropertyTree, INFO format has the nice #include directive. > > But it seems you cannot include other formats. > > Typically such INFO file, > > > > key > > { > > #include_xml "my.xml" > > } > > > > with "my.xml" :<root><child>kid</child></root> > > > > could give : get<std::string> ("key.root.child") == "kid" > > > > A very quick look at info parser makes me think that > > it would be easy to implement. Any comment ? > > > This is a strange request. What is your use case? > Thanks for your answer and sorry for the delay. Some part of my configuration are XML files given by third parties and, being particularly lazy, I did not want to write the few lines needed to handle the indirection. :-) > I'm rather disinclined to implement it, since it would create > cross-dependencies between the various parsers. > Yeah, I kind of exspected this answer. It probably makes sense. Regards, Ivan

1 0

[Review] Boost.Atomic review period extended
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, Since there has been only rather limited discussion about the Boost.Atomic library and only one full review, the review period will be extended until next Sunday, October 30th. I encourage everyone with an interest in this library to participate in the remaining days of the review. If someone wants to do a review, but won't find the time during the review period, please let me know how much time you need. Cheers, Tim Review Manager

1 0

trouble with find() in property_tree
by Bernd Prager 23 Oct '11

23 Oct '11

Hi, I am experiencing trouble with the find() function in boost::property_tree. It doesn't seem to catch nested entries. Statement (1) below finds the child tree, but statement (2) prints unexpectedly "false". That was not what I was expecting. How do I find nested children? Thanks for any help. -- Bernd #include <iostream> #include <boost/property_tree/ptree.hpp> namespace pt = boost::property_tree; int main(void) { pt::ptree props; pt::ptree const empty; props.add("pi", 3.14159); props.put("name.first", "bernd"); std::cout << "find(none): " << (props.find("none") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(pi): " << (props.find("pi") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(name): " << (props.find("name") == props.not_found() ? "false" : "true") << std::endl; // (1) std::cout << "find(name.first): " << (props.find("name.first") == props.not_found() ? "false" : "true") << std::endl; // (2) return EXIT_SUCCESS; }

2 1

odeint feedback request
by Karsten Ahnert 23 Oct '11

23 Oct '11

Dear community, odeint is a library for solving ordinary differential equations and has been discussed several times on this list. After successfully fulfilling the GSOC 2011 we continued working on odeint and we published two papers which are available at the arxiv: http://arxiv.org/abs/1110.3397 http://arxiv.org/abs/1110.3233 We would like to request feedback and/or comments on the implementation and the current status of odeint. The library and the documentation are available at the github: https://github.com/headmyshoulder/odeint-v2 http://headmyshoulder.github.com/odeint-v2/doc/index.html Thank you, Mario and Karsten

1 0

[atomic] Initial comments
by Grund, Holger 23 Oct '11

23 Oct '11

Hi everyone, It's been awfully quiet on the list regarding the atomic review. The atomic operations library is an invaluable tool for higher level concurrent data structures and algorithms. While toolchain vendors have already or starting to support <atomic>, many people are stuck on compiler where there is currently no support at all. Building these libraries yourself is tedious and prone to error and errors that are hard to spot. I am in this situation and therefore very much appreciate Helge's effort and think the lack of review comments so far should not be taken as a lack of interest. Now, I haven't had the time to look on things in any detail yet. I ignored the docs (~~) and only locked at the atomic header and some of x86 implementation so far. I haven't tried to build anything, but I intend to do a proper review though it's unlikely I'll manage to get to it on the official time line. I would have put some of the comments of the review tool site, but I can't login right now: - The fallback atomic_thread|signal_fence in boost/atomic.hpp seem to have external linkage, but no inline. Doesn't that give a ODR violation when included from more than on TU? - The copy-assignment operators seem to always return atomic&. IIRC, the earlier working drafts said return value_type. Has this changed? - The primary base_atomic is not aligned at all, AFAICT. I take it because you explicit need to extract bits anyhow and that means a memcpy. Does this have a performance impact? - Inline asm is the preferred way to build instructions. Did you consider intrinsics where available (e.g. ICC and GCC4+)? - atomic_flag is not statically initialized: I guess, there is some tradeoff with uniform-initialization syntax and member functions on most (all?) current production compilers. However, it seems to me that static initialization guarantees are atomic_flag's primary if not sole raison d'etre. Did you consider to make it a statically initializable type? - What's the point of the fences around cmpxchg in x86? - I'm not a GNU inline assembly expert and it's probably fairly unlikely to really affect codegen, but shouldn't clobbered flags be mentioned? Also the EBX handling for 32-bit Linux code may deserve some additional comment. I take it you can't mention ebx in the clobber list because the register allocator would complain for -fPIC, right? Does the impact unwinding? - I seem some of the *LOCK_FREE macros are defined involving sizeof. I've always assumed these macros (or the corresponding standard ones) would be suitable for use in #if processing. Wouldn't that be one of the main use cases? Thanks! -hg Holger Grund, Vice President Morgan Stanley | Cross-Technology Services 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 1

[boost threads] threadid copy constructor
by Jason Newton 21 Oct '11

21 Oct '11

The following patch adds a copy constructor to threadid. There seems to be no reason why they shouldn't be copyable. Comments? -Jason

2 2

difference_type size()?
by Olaf van der Spek 21 Oct '11

21 Oct '11

Hi, iterator_range returns a signed size. Is this correct? IMO it should return size_t. boost\range\iterator_range_core.hpp: difference_type size() const { return m_End - m_Begin; } Olaf

6 28

Using trac for boost-sandbox?
by Paul A. Bristow 21 Oct '11

21 Oct '11

Is it permitted to use the Boost Trac system for libraries under development at boost-sandbox? This would be very helpful. (especially if a history could refer to the Trac in Quickbook, as done in Boost.Pool new docs at pool.qbk [section:tickets Appendix E: Tickets] Report and view bugs and features by adding a ticket at [@https://svn.boost.org/trac/boost Boost.Trac]. Existing open tickets for this library alone can be viewed [@https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&component=pool&c ol=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority here]. Existing tickets for this library - including closed ones - can be viewed [@https://svn.boost.org/trac/boost/query?status=assigned&status=closed&status=new&status=reopened&co mponent=pool&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority here]. [endsect] [/section:tickets Appendix E: Tickets] This removes a boring burden on authors on updating the history of features and bugs. (There isn't an option to use sandbox in the drop-downs - only trunk, release, 1.n ...). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

Fwd: Re: [Boost-announce] [Review] Boost.Atomic review starts today, October 17th 2011
by Tim Blechmann 21 Oct '11

21 Oct '11

---------- Forwarded Message ---------- Subject: Re: [Boost-announce] [boost] [Review] Boost.Atomic review starts today, October 17th 2011 Date: Friday 21 October 2011, 10:20:42 From: Darren Cook <snip> CC: Tim Blechmann <tim(a)klingt.org> > Boost.Atomic ... implements the > interface as defined by the C++11 standard, but makes this feature available > for platforms lacking system/compiler support for this particular C++11 > feature. Hello, (I wanted to cc Helge Bahmann but couldn't find an email address) As the library is a stand-in until compilers catch-up, I think it would be useful to have a page in the documentation that shows the minimum compiler versions where it is no longer needed, for at least the major compilers. (I skimmed the docs but couldn't see this covered.) Darren P.S. No need to reply, and sorry I won't be able to take part in the review. (I'm also not on boost-devel list currently.)

1 0

Throws exception while deserializing large no object
by Bikas Tanti 21 Oct '11

21 Oct '11

I'm using vs 2010 and getting memory leaks when deserializing objects with binary archive . #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> class ElementResultData { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar,const unsigned int version) { ar & m_pass; ar & m_fail; ar & m_units; ar & m_result_no; ar & m_outof_tolerance; ar & m_iPartNo; ar & m_iActualValue; ar & m_iMeasurement1; ar & m_iMeasurement2; ar & m_iMeasurement3; } public: std::string m_pass; std::string m_fail; std::string m_units; std::string m_result_no; std::string m_outof_tolerance; unsigned long m_iPartNo; double m_iActualValue; double m_iMeasurement1; double m_iMeasurement2; double m_iMeasurement3; public: ElementResultData(){}; ElementResultData(std::string ps,std::string fl,std::string unit,std::string rno,std::string tol, int n,double av,double m1,double m2, double m3) : m_pass(ps),m_fail(fl),m_units(unit),m_result_no(rno),m_outof_tolerance(tol),m_iPartNo(n), m_iActualValue(av),m_iMeasurement1(m1),m_iMeasurement2(m2),m_iMeasurement3(m3) {} }; //DataResultDlg.h class CDataResultDlg { // Construction public: std::map<int, ElementResultData> m_mElemResDatafirst; std::map<int, ElementResultData> m_mElemResDataSecond; std::map<int, ElementResultData> m_mElemResultData; }; //DataResultDlg.cpp #define NUM_ELEMENTS 50000 // works fine when NUM_ELEMENTS is 1 class CDataResultDlg { for(unsigned long i=0;i<NUM_ELEMENTS;i=i+2) { m_mElemResDatafirst.insert(std::make_pair(i, ElementResultData("Pass","No", "MM","PartA","O",i,1.6020,1.0400,1.320,1.1010))); m_mElemResDatafirst.insert(std::make_pair(i+1,ElementResultData("Fail","Yes","MM","PartB","O",i+1,1.085,1.0004,2.320,1.1010))); } //Saving Data std::ofstream ofs("ResultData"); // save data to archive { boost::archive::binary_oarchive oafirst(ofs,std::ios::app); //write instance to archive int no_of_map = 2; oafirst<< no_of_map; oafirst << m_mElemResDatafirst; oafirst << m_mElemResDataSecond; } //Loading Data std::ifstream ifs("ResultData",std::ios::binary); { // create and open an archive for input boost::archive::binary_iarchive ia(ifs); // read class state from archive int no_of_Element; ia>>no_of_Element; for(int i =0;i<no_of_Element;i++) ia >>m_mElemResultData; *// Out Of Memory * }; Same code works fine for text_archive.I have to serialize huge amount of data to a file . Any help will be appreciated . -- View this message in context: http://boost.2283326.n4.nabble.com/Throws-exception-while-deserializing-lar… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[msm] state machine construction / destruction
by Jinsong Huang 21 Oct '11

21 Oct '11

MSM enthusiasts, I have done a performance profiling with a simple parser with 3 implementations, plain C++, SMC and Boost MSM. I was happy to learn that the MSM implementation was very efficient. I'm having some questions about MSM space allocation, please let me know if my understanding of things are wrong (very likely). I work in a high performance computing environment so I will try to minimize unnecessary object constructions. Is it possible for the data in the state machine backend live somewhere else external to the state machine? If that's possible then I can put the state machine's internal states close to the data that needs to be manipulated and the state machine itself is data-less and I can have a single copy of the state machine and each data item carries everything. I know this breaks encapsulation but I'm just wondering. The state machine has a events queue (std::deque?), can I choose to not have this and other data structures I don't think I will need? Thanks, -jh

2 1

enable_if : how to make it work in the case of templated method of a template base inherited several times
by nico 20 Oct '11

20 Oct '11

I hope the subject didn't make you run away ;-) Let me be clearer (I'll try at least): If I have a template base class with a template method : template <typename T> class S { public: template <typename U> void f(U p, typename enable_if<is_same<T, U> >::type*dummy = 0) { std::cout < {}; Then I have what I want: int i = 1; A a; a.f(i); compiles, but double d = 2.0; a.f(d); doesn't compile : error: no matching function for call to ‘A::f(double&)’ It is the expected behavior. Now let's A inherit from S<double> also : class A : public S<int>, public S<double> {}; Then the following code doesn't compile : int i = 1; A a; a.f(i); error: request for member ‘f’ is ambiguous error: candidates are: template<class U> void S::f(U, typename boost::enable_if<boost::is_same<T, U>, void>::type*) [with U = U, T = double] error: template<class U> void S::f(U, typename boost::enable_if<boost::is_same<T, U>, void>::type*) [with U = U, T = int] I expected there is no ambiguity : f<int> exists only for S<int> In the compiler error, we can notice that T is known when this piece of code is compiled, but not U (U = U). Any explanation or "workaround" ? Thanks. Nicolas.

4 3

[Re:Opaque Typedef] observations on opaque typedef
by Robert Ramey 20 Oct '11

20 Oct '11

Vicent - I saw your post on this subject some months ago and I've reviewed the thread. I didn't look at the code though. I also looked at the C++0x document and I have something to say about this. a) as you know I'm the author of BOOST_STRONG_TYPEDEF which lets one assign a unique type to some primitive integer type. I did this to permit overloads on integers used for different purposes. The new types created had all the properties of integer types but they were all different types. So far so good. b) I eventually found the BOOST_STRONG_TYPEDEF did too much - what I really wanted to not to inherit all the interoperations but only some of them. So I've reduced or eliminated usage of BOOST_STRONG_TYPE from the serialization library implementation. Never the less, I do see it useful in other contexts so your efforts to create and opaque typedef seem useful to me. c) BUT now I really want something else. I want the ability to assign a new type to an existing type. The current typedef has the feature that if two different names are used for the same type, a new type is NOT created. That is typedef creates a synonym rather than a new type. I thought that C++0x template alias would do this. But a careful reading of the standard document that I have leads me to believe that if two names are aliased to the same underlying type - a new type is not created - just like the current typedef. So what we have in the new C++ is basically a templated typedef. d) what I really need is the equivalent to #define OPAQUE_TYPEDEF(name, t) \ struct name : public t {}; so I can say struct dollar_amount { ... operator *(const & rhs) const {..} // don't include this operator - makes no sense }; OPAQUE_TYPEDEF(debit, dollar_amount); OPAQUE_TYPEDEF(price, dollar_amount) and then say void f(debit, t){...} void f(price t){...} Notice in my example, I don't want debit and price types to be true types and not just synonyms for dollar_amount. I realize that this is whole different kettle of fixh than BOOST_STRONG_TYPE or OPAQUE_TYPE. So this might be considered off topic. or maybe not. Comments welcome. Also anyone can feel free to correct my understanding of the template alias feature of C++0x to create new types. Robert Ramey

5 7

missing locale/info.hpp
by markus.rauber＠bluewin.ch 20 Oct '11

20 Oct '11

Hi in your documentation you mention the availability of info.hpp (located in /boost/locale) I've just downloaded the latest 1.47 release and there's no such "locale" subdirectory and no info.hpp file containing a <locale> include statement. I'd like to use the language settings provided with this header file. Where can it be found? Where can the corresponding library be found? Thanks for your feedback Markus

2 1

using nabble to read/write on Boost ML
by lcaminiti 20 Oct '11

20 Oct '11

Hello all, I use Nabble to read/write Boost emails but it puts special HTML instead of the template parenthesis: template<typename T> Other Nabble users (if any), is there a way to configure Nabble to not do this? If not, is there another web-based tool (a side from my personal gmail) I can use to view and reply Boost emails? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-using-nabble-to-read-write-on-Boos… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [utility] How can I contribute?
by Stewart, Robert 20 Oct '11

20 Oct '11

Andrzej Krzemienski wrote: > > I am not well familiar with Boost procedures, so I apologize > if my question is silly. There's a good deal published on the web site (see Community). > I found a bug (or a missing feature) in template > boost::value_initialized. I found that a bug report and the > proposed resolution are already there in BoostTrac: > https://svn.boost.org/trac/boost/ticket/5483. Is there a way I > could help speed the process of getting it fixed up? Can people > from outside commit changes to Boost trunk? Outsiders may not commit changes. Adding "[utility]" to your subject would have helped to focus attention on the affected library. Boost.Utility has no single maintainer, so adding that to the subject will attract attention from the interested parties and your asking about the bug reported six months ago will help to increase attention. You might want to add your own details to the Trac report, including whether the proposed patch fixes your problem. (If it did, it should encourage the maintainers to accept the patch.) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [boost] [locale] missing locale/info.hpp
by Stewart, Robert 20 Oct '11

20 Oct '11

markus.rauber(a)bluewin.ch wrote: > > in your documentation you mention the availability of info.hpp > (located in /boost/locale) I've just downloaded the > latest 1.47 release and there's no such "locale" subdirectory > and no info.hpp file containing a <locale> include statement. > > I'd like to use the language settings provided with this > header file. > Where can it be found? > Where can the corresponding library be found? Boost.Locale was accepted into Boost this past spring (see http://www.boost.org/community/review_schedule.html for details). It has not yet been made part of a release (as can be seen from http://www.boost.org/doc/libs/, which you can access from boost.org's Libraries link.) FYI: It is also helpful to include the library name in square brackets in your subject to ensure the library author/maintainer discovers it (see http://www.boost.org/community/policy.html#subject-line) Conventionally, the library name is rendered in lower case. I have done so in my reply, so Artyom may well have more details to offer you. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RFC: A better shared_array
by Olaf van der Spek 19 Oct '11

19 Oct '11

Hi, The current shared_array doesn't keep track of size. This greatly decreases it's usefulness. So I wrote a variant that does: http://pastebin.com/wkdLVqM1 Any interest in such a variant? Olaf

3 14

How can I contribute?
by Andrzej Krzemienski 19 Oct '11

19 Oct '11

Hi, I am not well familiar with Boost procedures, so I apologize if my question is silly. I found a bug (or a missing feature) in template boost::value_initialized. I found that a bug report and the proposed resolution are already there in BoostTrac: https://svn.boost.org/trac/boost/ticket/5483. Is there a way I could help speed the process of getting it fixed up? Can people from outside commit changes to Boost trunk? Regards, &rzej

1 0

Re: [boost] Interest in StaticVector - fixed capacity vector
by Nevin Liber 19 Oct '11

19 Oct '11

On 14 October 2011 05:32, Dave Abrahams <dave(a)boostpro.com> wrote: > Use-cases, please! I worked on a messaging system that created messages via serialization (that took iterators) and delivered them via UDP. Most messages were small (<100 bytes) with occasional messages 1K-2K in size. To give ourselves breathing room, we allowed messages up to, say, 32K, as it would be a non-trivial effort to implement splitting/reassembly of messages. > How could it ever be a "drop-in replacement for vector" For over a decade, the mental model for calling push_back, insert, resize, etc. is that it they have no preconditions to check. This is true *for every standard container* (which supports the corresponding operation, of course). You want to *silently* break that consistency. That will lead to buffer overrun bugs, which we know are hard to debug and I'm not saying we don't need the unchecked functionality. I'm saying it should never be spelled p-u-s-h-_-b-a-c-k, i-n-s-e-r-t, r-e-s-i-z-e, etc. (which is one of the reasons I'm arguing against making it policy based). I'm strongly opposed to any solution that uses the same function signatures as the standard containers that isn't as safe and easy to call as the ones in the standard containers. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

3 7

[context] interface to query remaining stack space
by Charlls Quarra 19 Oct '11

19 Oct '11

Hi All, is there a easy way to query the remaining stack space in a given context? assuming the context is running, i can check the address of a stack dummy variable, but i don't see a way to query the top address of the stack. One could do this by storing that top address before creating the context, but i was wondering if there is already an interface that i'm missing? thanks

1 1

Interest in StaticVector - fixed capacity vector
by Andrew Hundt 19 Oct '11

19 Oct '11

On Sun, Aug 14, 2011 at 5:55 AM, Andrew Hundt <athundt(a)gmail.com> wrote: > I've implemented a small companion class to boost.array that functions > like a stack allocated vector with fixed capacity. The motivation for this > class came when I was using boost.array in an interprocess library, when I > realized that I actually desired an adjustable size boost.array, without the > complexity of the vector class in the interprocess library. The result is > StaticVector, which is boost.array directly modified with a size in front of > the array, and added facilities to match std::vector. > > The Implementation is available at: > https://github.com/ahundt/Boost.StaticVector > > Sample Code: > StaticVector<std::size_t,3> three; > three.push_back(5); > three.push_back(2); // size: 2 capacity: 3 > three.push_back(3); > > three.push_back(1); // throws std::out_of_range exception indicating the > capacity has been exceeded > > So here is the big question: > Is there any interest in the class? > > Cheers! > Andrew Hundt > > On Mon, Aug 15, 2011 at 5:20 PM, Nevin Liber <nevin(a)eviloverlord.com> wrote: > On 15 August 2011 16:05, Andrew Hundt <athundt(a)gmail.com> wrote: > > > Good point. I've modified elems to be a char array, and I now > > reinterpret_cast to the class T as necessary. Elements should only be > > constructed when they are added now. > > > > What are you doing about alignment? Take a look at Synyhesizing Types with > Specific Alignments in the Type Traits library for a start. > -- > Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404 > Phil Endecott wrote: > In the case of StativVector<char,N> where N<256, you should consider using > uint8_t to store the size - and similar variations. Boost.Integer makes it > possible to select a suitable type. Sorry for the duplicate email, but my other email seemed to get lost in the shuffle. I know its been a while since I sent my first emails regarding StaticVector, but I have fixed some of the issues others pointed out. - I added a benchmark based on a move benchmark found on C++Next, that shows StaticVector outperforming vector by about 30%, which seems reasonable since there is no dynamic allocation. - I believe I've resolved the StaticVector alignment using type_traits' aligned_storage, as suggested by Nevin Liber. - I've also added the use of Boost.Integer to select the smallest possible type to track the size of the vector given its capacity, as suggested by Phil Endecott. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Anyone still have additional thoughts or interest in this? Cheers! Andrew Hundt

27 129

range: strided unused parameter 'first' [PATCH]
by Shaun Jackman 18 Oct '11

18 Oct '11

Hi, When using boost::strided I get the following error: boost/range/adaptor/strided.hpp:52: error: unused parameter 'first' The following patch should fix this error. Cheers, Shaun --- boost/range/adaptor/strided.hpp (revision 75052) +++ boost/range/adaptor/strided.hpp (working copy) @@ -49,7 +49,7 @@ namespace boost { } - strided_iterator(base_iterator first, base_iterator it, base_iterator last, difference_type stride) + strided_iterator(base_iterator, base_iterator it, base_iterator last, difference_type stride) : super_t(it) , m_last(last) , m_stride(stride)

1 0

[review] request date change for Local review
by Jeffrey Lee Hellrung, Jr. 18 Oct '11

18 Oct '11

I'm manager for the review of Lorenzo Caminiti's Local library. After a brief discussion with Lorenzo and Greg Crosswhite (review manager assistant), we've decided it would be prudent to push the Local review back to November 10th - 20th (originally scheduled for October 24th - November 2nd), given its overlap with the Atomic review and it being likely that several possible review contributors could be tied up getting 1.48.0 shipped out during the original review time frame. Is it not too late to reschedule? It looks like Local is the last library scheduled for review, and I don't see any conflicts in the calendar. If this is problematic for anyone for any reason, please let me know. Thanks, - Jeff

1 0

[Review:Algorithms] - Review by Neil Groves
by Neil Groves 18 Oct '11

18 Oct '11

*Evaluation of the design.* The design is pleasingly consistent with other algorithms with the exception of clamp_range. The clamp_range function copies, which is inconsitent with the other Boost string algorithms that have the _copy suffix. The clamp_range feature would be better designed as a clamped range adaptor. *Evaluation of the implementation* Generally, the algorithms would benefit from concept checking. In particular the iterator traversals, and range concept requirements should be checked. The implementation of the functions in all.hpp and clamp.hpp are correctly implemented. The clamp function does not provide the usual guarantees about NaN values that most of the floating-point operations do. That is any one argument being NaN does not guarantee a NaN result. This is probably intended, if so a note should be made in the documentation.The argument types may benefit from using call_traits to optimally chose between constant reference and value types. It might be worth considering an assertion that p(lo,hi) is true in the clamp function. The mixing of differing integer types makes the search algorithms defective. The int type is signed, and typically <= the size of std::size_t yet these are mixed. The skip table uses ints, but std::size_t values are inserted. Certainly there should not be any c style casts. It would seem logical to use the boost::iterator_difference<Iterator>::type instead. Currently these algorithms are defective albeit under unusual conditions. There are numerous invocations of non-member functions that should use qualified calls to avoid accidental argument-dependent lookup. range_const_iterator<Rng> has been deprecated in favour of range_iterator<const Rng> The Range versions of the functions should provide a non-const reference version since there are no requirements for the interoperability of range_iterator<const Range> and range_iterator<Range> although they normally exist.. The tests have some defects with respect to dereferencing end iterators. As others have mentioned there should be range versions of all of the functions. *Evaluation of the documentation* The documentation should make very clear that the result for empty ranges into all_of, any_of, none_of as this is currently ambiguous. The documentation should provide more clear performance guarantees about the number of predicate evaluations where this is possible eg. any_of can and does early exit. The documentation should also provide the exception guarantees. *Evaluation of usefulness* If corrected and properly documented these functions will be very useful. The functions any_of etc. are extremely useful for runtime assertions of pre- and post-conditions. *Did I try to use the library?* I used the library with GCC 4.6.1. I had no problems, although I did defect the defects noted above. *How much effort did I put into my evaluation?* I reviewed the code for a couple of hours which was sufficient for the small amount of code under review. *Am I knowledgeable about the problem domain?* Yes, I maintain Boost.Range hence my comments with respect to ranges are reasonably well informed. I have long been a fan of Design by Contract and hence I have experience using my own versions of the functions all_of etc. I vote for inclusion into Boost if and only if: 1. the defects in the search functions and test are resolved 2. clamp_range is removed or replaced. Regards, Neil Groves

9 15

[multi_array] swap
by Maxim Yanchenko 18 Oct '11

18 Oct '11

Hi, The swap support for multi_array was under discussion from the very beginning. A multi_array is quite a heavy object so having light-weight and no-throw swap would be really great. In 2009 a patch was proposed (https://svn.boost.org/trac/boost/ticket/1045) and Ronald Garcia generally liked it, but planned to do some extra work before adding swap to multi_array (see the comments for the ticket above). What is the current status? Thanks, Maxim

2 1

[msm]Event convert at exit point
by Takatoshi Kondo 17 Oct '11

17 Oct '11

Hello, I have a question about Boost.Msm event conversion at exit pseudo state. (Version 1.47.0) http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s02.html#d0e942 Exit pseudo states struct event6 { event6(){} template <class Event> event6(Event const&){} }; //convertible from any event Above document said that we can convert the event using the template constructor. This exmaple doesn't access the constructor's parameter. I want to propagate some value of the event. Event2 is a source event. And Event3 is a target event like this.(see attached file) struct Event2 { Event2(int val_):val(val_) {} int val; }; struct Event3 { Event3(int val_):val(val_) {} template <class T> Event3(T const& e):val(e.val) {} // error Event3(Event2 const& e):val(e.val) {} // OK int val; }; // Transition table struct transition_table:mpl::vector< // Start Event Next Action Guard msmf::Row < SubState1, Event2, Exit, msmf::none, msmf::none > > {}; struct Exit :msm::front::exit_pseudo_state<Event3> {}; But compile error occurred. The compiler said Event1 doesn't have a member 'val'. I'm not sure why Event3's constructor instantiate from Event1. This is the question. If I define the constructor that has a parameter Event2 instead of template parameter, compile error doesn't occur. exit_pt_convert.cpp(attached file) is a source code that reproduces this error. Thanks, Takatoshi

3 4

Extra files in release branch
by Marshall Clow 17 Oct '11

17 Oct '11

As of revision #74996, the following files and directories exist only in the release branch - not in the trunk. Is this on purpose? boost/smart_ptr/enable_shared_from_this2.hpp boost/test/detail/unit_test_parameters.hpp boost/test/exception_safety.hpp boost/test/impl/unit_test_suite.ipp boost/test/interaction_based.hpp boost/test/logged_expectations.hpp boost/test/mock_object.hpp boost/test/test_observer.hpp boost/test/unit_test_suite_impl.hpp boost/test/utils/callback.hpp libs/phoenix/doc/html/phoenix-doc_HTML.manifest libs/test/example/cla/Jamfile libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/src/unit_test_suite.cpp libs/test/test/CMakeLists.txt libs/geometry/test/ranges (empty directory) libs/phoenix/doc/html/phoenix (not empty directory) libs/spirit/doc/html/spirit (not empty directory) libs/spirit/repository/doc/html/spirit_repository (not empty directory) libs/test/doc/html/utf/usage-recomendations (not empty directory) -- 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

4 5

Adding a --log_level="message" runtime option to a Boost.test test-suite
by Paul A. Bristow 16 Oct '11

16 Oct '11

Can anyone tell me how to add a --log_level="message" runtime option to a Boost.Test test-suite. Running using VS project I have a Custom Build Step command line "$(TargetDir)$(TargetName).exe" --log_level="message" I'd like to replicate this in a jamfile : ... test-suite "multiprecision EFX numerical test" : [ run numerical_test.cpp ] ; but adding --log_level="message" (and perhaps other Boost.test options as well). (I want this for all compilers of course, so placing in compile options doesn't seem right.) Suggestions most welcome. Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 6

Unittest capability for meta-programs feedback request
by Ben Robinson 16 Oct '11

16 Oct '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. The submission source is available at https://github.com/icaretaker/Metatest. The provided examples are based on the factorial metafunction from Chapter 8 of "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy - http://www.boostpro.com/mplbook/. Chapter 8 explains the rational behind the BOOST_MPL_ASSERT_* macros. This submission complements these macros by allowing the writing of regression unit tests, to ensure the user will encounter the mpl formatted compiler error, if the library types are incorrectly instantiated. Currently, many meta-programs are written using one of the BOOST_MPL_ASSERT_* macros. Unit tests for these metaprograms must of course compile, therefore unittests for these programs can verify that valid types produce the correct run-time behavior. This submission provides the following four complementary macros: BOOST_METATEST(pred) BOOST_METATEST_NOT(pred) BOOST_METATEST_RELATION(x, rel, y) BOOST_METATEST_MSG(cond, msg, types) Meta-program authors can use these macros to assert predicates/relations/conditions exactly as done with BOOST_MPL_ASSERT_*. In shipped library code, these four macros exactly forward to their BOOST_MPL_ASSERT_* counterparts, since the BOOST_MPL_ASSERT_* macros do an excellent job of providing maximally informative compiler error messages. In unit test code (where BOOST_METATEST_RUNTIME will need to be defined), these macros will instead instantiate an object, which will throw a runtime exception if the predicate/relation/condition fails. Now meta-program authors can write unittests like the following: BOOST_AUTO_TEST_CASE(factorials_should_not_be_negative) { BOOST_CHECK_THROW( factorial<mpl::int_<-1> > instance;, metatest_exception ); } As you can see, this unit test validates that the factorial meta-function will in fact fail to compile. All exceptions are subclassed from boost::metatest_exception. If the user would instead like to supply their own exception types for individual assertions, one of the following four macros can be used alternatively: BOOST_METATEST_EXP(pred, exp) BOOST_METATEST_NOT_EXP(pred, exp) BOOST_METATEST_RELATION_EXP(x, rel, y, exp) BOOST_METATEST_MSG_EXP(cond, msg, types, exp) Another feature of this library, is that it is independent of any unit testing framework, provided the framework can catch exceptions by type. The examples provided show how this is done with Boost Test. The submission files also show how to use try/catch directly should your unit test framework not have such a capability. I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

16 40

[test] Still having issues
by John Maddock 16 Oct '11

16 Oct '11

I'm still having a lot of issues with the latest Boost.Test not building: On Win32 with Intel's 11.1 and 12.1 compilers I see: ..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler; And on Ubuntu Linux with gcc I see: gcc.compile.c++ /home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o In file included from ../../../libs/test/src/unit_test_main.cpp:16: ../../../boost/test/impl/unit_test_main.ipp: In function 'int boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': ../../../boost/test/impl/unit_test_main.ipp:97: error: 'getchar' is not a member of 'std' "/usr/local/gcc/4.4.3/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "/home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o" "../../../libs/test/src/unit_test_main.cpp" Probably a missing <cstdio> include? John.

3 13

[1.48] Reminder: merge fixes by Monday!
by Eric Niebler 14 Oct '11

14 Oct '11

Just a reminder that as of Monday, the release branch will be closed except for permission by a release manager. If you have fixes to merge to the release branch, please try to get them in over the weekend. Here's the schedule: October 10: The release branch was closed for major code changes. It is still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 14 Oct '11

14 Oct '11

Hi all! Not so long ago I was looking for a solution to Base64 encoding/decoding. In this page - http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/dataflow.html - I found example of such solution, with 'base64_from_binary' and 'transform_width' iteartors. But it is just a "blank", not ready-to-use solution. I created solution. But I definitely know many developers looking for a simple, ready-to-use, header-only and 'real C++' solution for Base64. So I want to offer you such solution. Some examples: int main() { std::string my_text = "My text for encoding!"; std::string encoded_text = boost::base64().encode( my_text ); std::string my_text_again = boost::base64().decode< std::string >( encoded ); } For binary data: int main() { typedef std::vector< unsigned char > binary_string; binary_string my_bin = list_of( 0xFF )( 0xAA )( 0x01 ); std::string encoded_bin = boost::base64().encode( my_bin ); binary_string my_bin_again = boost::base64().decode< binary_string >( encoded ); } For streams: int main() { boost::filesystem::ifstream my_jpeg( "/some/path/to/my/image" ); // fstream checking omitted... std::string encoded_jpeg = boost::base64().encode( my_jpeg ); boost::filesystem::ofstream my_jpeg_again( "/some/path/to/decoded/image" ); // fstream checking omitted... boost::base64().decode( encoded_jpeg, my_jpeg_again ); } This is first variant. IMHO such solution will be useful for Boost users. What you think about it? - Denis

7 27

[date_time] performance tests
by Greg Rubino 13 Oct '11

13 Oct '11

Hi all, Does anyone know of/have an open source suite of performance tests for Boost.Date_Time? If not, I'll post back with whatever I come up with. Thanks, Greg

1 0

Checking interest in to_string functions
by Antony Polukhin 13 Oct '11

13 Oct '11

As was mentioned in `[boost] to_string(v)` 1) Functions to_string and to_wstring are part of the upcoming C++0x standard. However, there are no functions for char16_t and char32_t conversions. 2) Some users can't use C++11 in some projects for quite some time, but can use boost. 3) "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Some users would like to use a shorter form. Is there interest in stoi, stoll, stof, to_string, to_wstring, to_u16string, stod and other functions for char, wchar_t, char16_t and char32_t conversions? Shall I add them to lexical_cast library, or as a separate conversion library? Best regards, Antony Polukhin

8 15

[ASIO] tcp::socket::async_connect() connections count
by Jim Xochellis 13 Oct '11

13 Oct '11

Hi list, I am testing a slightly modified version of the chat_client/chat_server ASIO examples and I have noticed that, immediately after the tcp::socket::async_connect() call from inside the chat_client constructor, the client is creating and establishing not one, but three TCP connections, only one of which is targeting to the server-port. Furthermore, calling repeatedly the async_connect() seems to constantly create three connections per call. I have also noticed that other programs in my system, which also communicate via TCP (ie the hyper-terminal), only open one connection at the client side. Is this async_connect() behavior, which I have mentioned above, the expected/natural behavior, or maybe I am doing something wrong? If this behavior is expected, is there a reason for it? Do I have a choice to change it? Please note that there is a near-4000 outbound concurrent connections default limit in many Windows-XP installations, hence this question has a practical meaning. Configuration informations: OS: Windows XP Pro SP3 Boost version: 1.46.1 IDE: MVS 2005 Thank you in advance, Jim Xochellis ----- Homepage: https://sites.google.com/site/xochellis/ -- View this message in context: http://boost.2283326.n4.nabble.com/ASIO-tcp-socket-async-connect-connection… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[filesystem] scoped_file feature request?
by Beman Dawes 13 Oct '11

13 Oct '11

There is a long outstanding feature request, #1090 from Marcus Lindblom, requesting the following be added to Boost.Filesystem: class scoped_file { public: explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {} ~scoped_file() { boost::filesystem::remove(m_path); } private: boost::filesystem::path m_path; }; My weakly held opinion is that this request should be rejected. Rationale: Easy enough for users to do themselves, so it doesn't justify the additional surface area it would add to of the library. Does anyone have a killer argument for adding it? --Beman

5 12

Dennis Ritchie passed away
by Nevin Liber 13 Oct '11

13 Oct '11

<https://plus.google.com/101960720994009339267/posts/ENuEDDYfvKP> via Rob Pike - 8:02 PM - Public I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information. I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately. He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 1

BGL: labelled edge graph
by Shaun Jackman 12 Oct '11

12 Oct '11

Hi, I have a directed acyclic word graph (DAWG) [1] for which the fundamentally efficient operation takes a vertex descriptor and an edge label and returns an edge descriptor (if that edge exists). An out_edge_iterator can be used to iterate over the edges to find the edge with the specified label, but it's not very efficient. I plan to extend the BGL API to add the needed functionality. I wanted to check first that this function doesn't already exist, and if it doesn't, ask for suggested names. I was thinking of... pair<edge_descriptor, bool> out_edge( vertex_descriptor u, edge_label i, Graph g); The type of edge_label would depend on the graph. For me, it's a char. This sort of labelled edge navigation also applies to a de Bruijn graph [2]. Cheers, Shaun [1] http://en.wikipedia.org/wiki/Directed_acyclic_word_graph [2] http://en.wikipedia.org/wiki/De_Bruijn_graph

2 1

[numeric][interval] clang support patch
by Jürgen Hunold 12 Oct '11

12 Oct '11

Hi, I've been running into the (in-)famous clang bug http://llvm.org/bugs/show_bug.cgi?id=6907 which prevents detail/c99sub_rounding_control.hpp from working. Boost contains workaround code in <boost/detail/fenv.hpp> which is used by the 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

3 3

[thread] How to return a lazy future ?
by Ivan Le Lann 12 Oct '11

12 Oct '11

Hi, Boost.Thread documentation has a section regarding the creation of lazy futures. http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#t… The code on this page runs fine, but I can't find a way to return such future. Naïve code below exits with a boost::broken_promise in unique_future::get(). boost::unique_future <int> create_future() { boost::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything); task.set_wait_callback(invoke_lazy_task); return task.get_future(); } int main() { assert(create_future().get()==42); } Exceptional finish is marked in packaged_task destructor. And regardless of exceptions, since set_wait_callback want something that operates on packaged_task and not on pointed task_base, the code is doomed to do an access violation. So, is there any way to return lazy futures ? Regards, Ivan

1 0

Disable_if_type / is_pair
by Olaf van der Spek 12 Oct '11

12 Oct '11

Hi, I've got a find wrapper (returning a pointer instead of an iterator) that works for map, unordered map, ptr map, etc. I'd like to extent it to set and mult_index. What is the recommended way to disable the second overload? I didn't find a is_pair type_trait or disable_if_type. I call the find() member, which for example vector doesn't have. How should I use the free find() if a member find() isn't available? template <class T, class U> typename T::value_type::second_type* find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } template <class T, class U> typename iterator_traits<typename T::iterator>::pointer find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &*i; } Greetings, Olaf

2 6

[chrono][system] Make possible to don't provide hybrid error handling.
by Vicente J. Botet Escriba 11 Oct '11

11 Oct '11

Hi, Boost.Chrono provides by default an hybrid error handling for the Clock::now() function, implementing the following prototype Clock::now(system::error_code&= boost::throws()); Now that the standard has accepted the prototype Clock::now() noexcept; and set as NAD-Future the Beman proposal (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3314.html#935) The hybrid prototype can not be noexcept, as the use of boost::throws() force to throw an exception on error. We need to overload the function as follows: Clock::now() noexcept; Clock::now(system::error_code&); This lost the advantages of the announced by the hybrid error handling design (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html) as we are forced to have two implementations. In addition, while most of the uses of now(ec) expect that there is no exception, the prototype can not state it using noexcept, if the boost::throws() semantic is taken in account. Due to this split, we can now make Boost.Chrono a real header-only library if we admit to renounce to use the hybrid interface. The library could add a macro that prevent the inclusion of these prototype, as e.g. BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING. The experience while using these hybrid approach and mixing all these semantics has shown me that this doesn't promotes good design and doesn't compose well. Split the prototypes is cleared. system_clock::time_point system_clock::now() noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) // Note that this call is used only when the platform provides this interface. { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { if (BOOST_CHRONO_IS_THROWS(ec)) //[1] { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } else { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } } if (!BOOST_CHRONO_IS_THROWS(ec)) // [2] { ec.clear(); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } Note how the test on whether the ec is thows() in [1] to throw and in [2] see if the ec can be cleared are obscuring what in principle was simple. It will be maybe better to add yet a 3rd prototype that forces the throw_on_error. Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); system_clock::time_point system_clock::now() BOOST_CHRONO_NOEXCEPT { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } ec.clear(); return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(throw_on_error_t & /*tag*/) noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } While these functions are quite simple and repeating the code is not an issue, when the logic is more complex, this could become a maintenance issue that should be resolved other techniques, as using internal functions, policies, ... I see three alternatives: A- Standard Clock::now() noexcept; B- Standard+Hybrid Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() C-Standard+EC+TOE Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); A breaks code using the error_code. C breaks code using the boost::throws() Yet another temporary alternative: D- Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() but it is deprecated Clock::now(throw_on_error_t&); We can start by providing D and let the user using boost::throws to move to throw_on_error, and the move to C. In addition the library must provide the user the possibility to don't include the extensions. Which way do you prefer? What do you think? Best, Vicente

4 6

Re: [boost] [filesystem] scoped_file feature request?
by Andrzej Krzemienski 11 Oct '11

11 Oct '11

> There is a long outstanding feature request, #1090 from Marcus > Lindblom, requesting the following be added to Boost.Filesystem: > class scoped_file { > public: > explicit scoped_file(const boost::filesystem::path& file) > : m_path(file) {} > ~scoped_file() { boost::filesystem::remove(m_path); } > private: > boost::filesystem::path m_path; > }; > > My weakly held opinion is that this request should be rejected. > Rationale: Easy enough for users to do themselves, so it doesn't > justify the additional surface area it would add to of the library. > Does anyone have a killer argument for adding it? > --Beman Hi, I would add to the rationale for rejection, that scoped_file's destructor performs an operation that might throw an exception, which is counter to well established practices in C++. You could use the error_code version, but that would hide the error if any occurs. Regards, &rzej

1 0

BOOST_FORCE_INLINE
by Mathias Gaunard 11 Oct '11

11 Oct '11

I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp Who do I need to contact to make this happen?

16 31

Problems with proto and /clr
by Jorge Lodos Vigil 11 Oct '11

11 Oct '11

Hi In boost 1.47 proto stopped compiling with /clr in VS2008 and VS2010. Take the calc3 example, for instance. The root problem is that /clr is instantiating templates that normally are not. The change in proto is the new is_applyable metafunction. In normal compilation, when the received parameter is not callable mpl::and_ ensures that there is no need to fully instantiate the is_transform metafunction parameter. Apparently when using /clr it gets instantiated any way. You may verify this commenting out the 3 BOOST_MPL_ASSERT_RELATION lines in calc3 sample (so it will compile) and adding the following in the main function: // This is an instantiation of is_applyable that causes problems typedef boost::mpl::max<CalculatorGrammar,boost::proto::_state> is_applyable_parameter_t; // This is why it normally compiles BOOST_MPL_ASSERT_NOT((boost::proto::is_callable<is_applyable_parameter_t>)); // The following correctly fails to compile, the is_transform metafunction must never be instantiated //bool is_tranform = boost::proto::is_transform<is_applyable_parameter_t>::value; // This is the line that does not compile with /clr but normally does typedef mpl::and_<mpl::false_, boost::proto::is_transform<is_applyable_parameter_t> > problem_t; This code fails to compile with /clr, because is_applyable_parameter_t is instantiated and CalculatorGrammar is not comparable. Before I continue to dig in proto code, try workarounds and create tickets, I thought I might ask these questions here: 1. In case a workaround can be found (decomposing is_applyable in 2 metafunctions, for instance) is it of interest to support /clr? 2. Is this situation a compiler bug, a proto bug or just bad luck + undefined behavior? I'll appreciate any comment you may have on this. Please note that this causes xpressive and probably spirit to fail compilation with /clr. On a side note note, if there is interest to support /clr, it should not be a problem to modify MSVC test scripts. Only the /clr parameter must be added to the command line, nothing else. Apparently there is no big demand for C++ with /clr, but if there is interest I could try to modify tests scripts and correct any problem that may surface. Thank you in advance for your time. Best regards Jorge

2 1

[serialization] Technique used for registration of derived through base ( Abrahams wizardy )
by Sebastian Karlsson 11 Oct '11

11 Oct '11

A good while ago I got interested in how the registration process works in boost::serialization, I was never able to understand how the technique works, even if the gist of it is contained in 2 fairly small headers ( boost/serialization/export.hpp & boost/archive/detail/register_archive.hpp ). It would seem the creator of the technique is David Abrahams, so I'm hoping he or anyone else which understands how the registration process works could explain the technique used. >From my understanding it solves the problem of having 2 different sequences of types, and then being able to operate on all the combinations. All the techniques I've seen used previously for this requires the maintenance of some sort of compile time vector of one of the sequences. This is very cumbersome, not only does it needs to manually managed, but the file that defines the vector turns into a large dependency bottleneck. From my understanding the technique used in boost::serialization currently one sequence simply adds an overload to a free function, then at the registration point of the other sequence just having the overloads considered at compile time causes the magic to happen when the return type needs to instantiated. Unless I'm missing something obvious I think it would make for a very interesting subject of an article or discussion on the mailing list. Kind regards, Sebastian Karlsson

1 0

operator traits: ready for addition
by Frédéric Bron 11 Oct '11

11 Oct '11

Dear John, Included is are 2 patches vs trunk with operator traits additions: - boost_type_traits.patch.bz2 to be applied in boost/type_traits - libs_type_traits.patch.bz2 to be applied in libs/type_traits I have also updated the sandbox: :http://svn.boost.org/svn/boost/sandbox/type_traits/ This new version addresses all review comments. Tested with gcc 4.6.1 and intel-linux 12.0. Could be nice if somebody could run the tests with msvc. Hope everything is fine. What would be the best way to add it to the trunk? Regards, Frédéric PS: sorry for the long delay but it is very hard to find some free time with a job and a family.

2 2

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 11 Oct '11

11 Oct '11

On 10/10/2011 4:50 PM, Joel de Guzman wrote: > Everything's green now, Eric. The problem was not pervasive after > all; just a couple of fixes solved everything. Whew! > There's no need to revert. It makes me wonder though if we've missed > something that will blow up in the future. I'll probably have to > scrutinize classes that use proto::extends and check for overloads. The problem is that Spirit defines its own operator overload(s) that compete with Proto's. The officially sanctioned way of doing this with Proto is to use a grammar to restrict Proto's overloads, and then define your own. Admittedly, Proto's docs could be more clear about best practice here. > You might want to warn other proto users of this potential > breaking change. This will need to be mentioned in the release notes, yes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 11 Oct '11

11 Oct '11

On 10 Oct 2011 10:32:53 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: > Den 07-10-2011 20:45, Joe Mucchiello skrev: >> On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten > Ottosen<thorsten.ottosen(a)dezide.com> wrote: >> >>> Den 06-10-2011 18:27, Phil Endecott skrev: >>>> Thorsten Ottosen wrote: >>>>> Even better, don't use vector<const char*>. What o > you need that for? >>> [snip] >>>> >>>> Here's a real motivating example where I want to use > vector<const >>>> char*>. I have a large file containing null-terminated strings > which I >>>> memory map. After opening the file, I construct some sort of index > of >>>> those strings in a sorted vector. Then I search for things using >>>> std::equal_range, std::lower_bound, or similar. >>> >>> That's a good example, I grant you. >> >> >> I actually have a helper class for this called cstrptr which is a typedef > for the template class >> >> basic_cstrptr<char>. It is a "dumb" wrapper around const > char * that provides some std::string >> > > Also, something like iterator_range<const char*> might be somewhat more > handy to store in the vector. Perhaps in the generic case, but as I said, my class is for magic text found in programs and you practically never need to run generic algorithm against lists of magic text. The value in my class is that it is basically the same size as a pointer to char and has a near nop constructor. But my class might be too specific for boost based on the lack of any reaction to the concept. It is just a little fluff class. Joe

1 0

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 10 Oct '11

10 Oct '11

On 10/10/2011 2:08 AM, Joel de Guzman wrote: > On 10/10/2011 1:52 PM, Joel de Guzman wrote: >> On 10/10/2011 12:38 PM, Eric Niebler wrote: >>> >>> Bummer. I suggest adding an rvalue ref overload of operator%= that >>> shares an implementation with the const lvalue one. Should just be a few >>> lines of code. Is that a problem? >> >> Not really a problem. But, %= is just an example of the problems >> (plural with an s). We suspect that it is more widespread. I'll >> see how pervasive the changes need to be and get back to you. > > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. > > Hartmut, I committed the fix for Qi and Karma. Can you please > take a look at the Lex regressions? There's a good chance > that the problem with the examples is also related to the Lex > problem. I just ran the spirit_v2/lex and spirit_v2/lex_regressions test suites on msvc-10.0, and everything passed for me. Is this fixed already? Let me know asap so I know whether to revert my Proto changes. (Note: If they don't make it in this time, these Proto changes will eventually go back in for next release, so Qi/Karma/Lex will need to be fixed eventually.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Mathias Gaunard 10 Oct '11

10 Oct '11

On 10/10/2011 11:08, Joel de Guzman wrote: > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. Does it work without errors when enabling optimizations? It could be a problem with the lifetime of references.

1 0

multi_index bug?
by Olaf van der Spek 10 Oct '11

10 Oct '11

Hi, I've got this container: typedef boost::multi_index_container< torrent_t, boost::multi_index::indexed_by< // boost::multi_index::hashed_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::ordered_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::sequenced<> > > torrents_t; I'm using the find() member to find elements. When I use hashed_unique, it seems to be unable to find some elements, while it finds all if I use ordered_unique. This is with Boost 1.46.1.1 (Debian) and gcc version 4.6.1 (Debian 4.6.1-4) Is this a known issue? Olaf

2 2

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 10 Oct '11

10 Oct '11

On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >Den 06-10-2011 18:27, Phil Endecott skrev: >> Thorsten Ottosen wrote: >>> Even better, don't use vector<const char*>. What o you need that for? >[snip] >> >> Here's a real motivating example where I want to use vector<const >> char*>. I have a large file containing null-terminated strings which I >> memory map. After opening the file, I construct some sort of index of >> those strings in a sorted vector. Then I search for things using >> std::equal_range, std::lower_bound, or similar. > >That's a good example, I grant you. I actually have a helper class for this called cstrptr which is a typedef for the template class basic_cstrptr<char>. It is a "dumb" wrapper around const char * that provides some std::string functions to the normally even dumber bare pointer to char. It's designed for holding those magic strings that creep into production code all the time. sizeof cstrptr == sizeof const char* is always true so the constructor has very little overhead. The calling code is responsible for ensuring the lifetime of the ptr exceeds the lifetime of the cstrptr instance. It implements all the comparison operators against std::basic_string and const char*. It implements a const operator[] and an O(N) length() function. It only implements assignment and copy constructor to allow containers to hold them. I've wondered whether it was worth submitting to boost. It is so small I can't imagine it sitting on its own as a "library".

2 1

[test] backward compatibility issue
by Jürgen Hunold 10 Oct '11

10 Oct '11

Hi Gennadiy, I'm getting some compiler errors when using the new trunk version of Boost.Test with our sources. I'm getting error: ‘global_fixture_impl’ in namespace ‘boost::unit_test::ut_detail’ does not name a type when using BOOST_GLOBAL_FIXTURE and only #including "boost/test/unit_test_suite.hpp" This file #defines at line 179: static boost::unit_test::ut_detail::global_fixture_impl<F> BOOST_JOIN( gf_, F ) ; a simple #include <boost/test/tree/global_fixture.hpp> fixes this. Patch attached. Okay 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 2

Boost.Algorithms request
by Zoltán Tóth 10 Oct '11

10 Oct '11

I ask to change the name of function is_ordered(). The "is_" prefix suggests that it is a boolean function which it is not. Also, there are other functions there with prefix "is_" and which are boolean functions, and this non-uniformity hurts the eye. I suggest the name "first_misordered".

4 3

Re: [boost] vsix - template_profiler extension, Templight
by József Mihalicza 09 Oct '11

09 Oct '11

Hello, From: Domagoj Saric: ...you might want to try the Templight route. A couple of years back the Hungarian team behind it tried to do the same thing as you (a "meta program debugger and profiler" Visual Studio add-in, only it was written in C++ rather than in C#). The source for an alpha-ish version was also available somewhere... The biggest problem with our tools is that they are rather prototypes than tools for everyday use. As none of the authors have had enough time to maintain them, they more or less remained in an alpha state. Fortunately this seems to change soon, a team with dedicated resources is being formed to make these tools usable and presumably public domain. What we have so far: * Templight framework: a set of command line utilities, based on Xerces and boost.{wave,spirit}. Supports g++ and VC (patches and warning message interpretation). * Visual Studio add-in, where the user can place breakpoints in templates, view template stack, instantiation history, debug step by step. * Standalone debugger application with the same features as of the VS add-in. C++, Qt, mainly tested on Windows. * Templar: standalone visualizer application: can load previously generated (with the cpp2trace tool) trace files and draws the instantiation forest allowing step by step debugging. C++, Qt, graphviz. The latest binary for Windows is available here: http://people.inf.elte.hu/pocok/ * Ad-hoc solutions for profiling: modified g++, also had some patches for VC to print timestamp at each warning. * A not-yet-implemented approach to cope with inheritance. If B inherits A, currently the reported order is Abegin,Aend,Bbegin,Bend instead of the expected Bbegin,Abegin,Aend,Bend. As we used handcrafted makefiles (on linux) and projects files (VC) with absolute paths to installed libraries, it is not trivial to make the source compilable. This is why we decided not to publish it in its current form. Still, if anyone is interested in any of them, feel free to contact me, I can send the current version. Regards, Jocó

1 0

Re: [boost] [1.46.0] Compilation Issues
by Lars Viklund 08 Oct '11

08 Oct '11

On Sat, Oct 08, 2011 at 11:34:02AM +0530, ranganaths wrote: > Hello, > trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of > Pls let me know how to overcome the same. All the > redefinitions are the clashes with that of the MSVC compiler includes. VC6 is a pre-standard compiler. As such, it has lots of quirks and templates are pretty much unusable on it. I strongly recommend either upgrading the compiler (there's free Express editions and reasonably cheap business and academic versions through BizSpark and DreamSpark), or using older Boost versions who accidentally care more about legacy toolchains. Strong words, but it's not feasible maintaining workarounds for legacy toolchains, not to mention actively fixing things for them. There's a huge thread on what to do with dysfunctional toolchains a few months ago. It's an amusing read. -- Lars Viklund | zao(a)acc.umu.se

1 0

[1.46.0] Compilation Issues
by ranganaths 08 Oct '11

08 Oct '11

Hello, I am new to this forum. I am using the Boost Library in my open source application and I am facing lot of compilation issues when trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of the compilation errors are based on the redefinition. The errors is as below error C2371: 'XXX' : redefinition; different basic types Pls let me know how to overcome the same. All the redefinitions are the clashes with that of the MSVC compiler includes. Eg: Boost has definition for 'round_toward_zero' in e:\Application \boost\detail\limits.hpp(58) : see declaration of 'round_indeterminate' c:\program files\microsoft visual studio\vc98\include\limits(28) : error C2371: 'round_toward_zero' : redefinition; different basic types Regards, Ranganath

1 0

fusion - reverse_view on maps
by Brandon Kohn 07 Oct '11

07 Oct '11

Hello, Awhile back I was using fusion.reverse_view on a fusion.map sequence (I think it was ~<=1.37 or thereabouts.) In later upgrades this became broken as a bidirectional concept was enforced on the reverse_view (quite sensible.) To work around this I made a minor change to my version which allowed reverse_view to work on both bidirectional sequences and those meeting the is_associative trait. Anyway, it got me wondering if there is a good reason that the map type doesn't model a bidirectional sequence? Cheers, Brandon

2 2

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 07 Oct '11

07 Oct '11

I wrote about: >http://lists.boost.org/Archives/boost/2011/02/177696.php >https://svn.boost.org/trac/boost/ticket/5230 What was obvious to the contributors to the above discussion, but dawned on me only slowly, was that mixed bitness shared memory only stands a chance of working if ones uses offset_ptr< void , boost::int64_t , boost::uint64_t > rather than the default offset_ptr< void > (which is possible on current trunk). I've now begun testing this in my own app and it is looking promising so far. Hope this helps someone googling for the same thing. Pete

2 1

[Containers] How about a list with O(1) splice?
by Phil Endecott 07 Oct '11

07 Oct '11

In another thread, Stephan T. Lavavej wrote: > Two-list partial-splice is now linear time. FDIS 23.3.5.5 > [list.ops]/14: "Complexity: Constant time if &x == this; > otherwise, linear time." Is there an opportunity here for Boost.Containers to provide a std::list replacement that keeps the old O(1) splice and O(N) size? I can imagine a lot of demand for this once people discover that their old splicing code is trashed by a std library upgrade... [OT: does anyone know of a list of "C++1x nasties" like this? It's easy to find lists of new features, but harder to find lists of misfeatures...] Regards, Phil.

8 19

[Review] Review results for Lockfree
by Hartmut Kaiser 07 Oct '11

07 Oct '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

5 8

[boost.program_options] another constructor for option_description
by Guilherme Maciel Ferreira 07 Oct '11

07 Oct '11

Hi list, Through options_description_easy_init::operator()(const char* name, const char* description), I can create an option_description with just the option name and description, without the value_semantic. However, all option_description class constructors require this value_semantic. Checking the code, I saw that options_description_easy_init uses untyped_value to create an option_description without type. Why not providing a set of constructors consistent with the options_description_easy_init::operator() operators? Kind regards, Guilherme -- Guilherme Maciel Ferreira Gtalk: guigasurf MSN: guigasurf(a)hotmail.com Mobile Brazil: +55 48 9904 3728 e +55 48 9134 4651 Skype: guilherme.maciel.ferreira

1 0

[property_tree] include directive for non-info files
by Ivan Le Lann 07 Oct '11

07 Oct '11

Hi, In Boost.PropertyTree, INFO format has the nice #include directive. But it seems you cannot include other formats. Typically such INFO file, key { #include_xml "my.xml" } with "my.xml" : <root><child>kid</child></root> could give : get<std::string> ("key.root.child") == "kid" A very quick look at info parser makes me think that it would be easy to implement. Any comment ? Regards, Ivan

2 1

[filesystem] New operational function added: canonical()
by Beman Dawes 06 Oct '11

06 Oct '11

A canonical() function has been added at the suggest of David Svoboda from CERT. Boost.Filesystem's class path had such a function at one time, but it was deprecated because it didn't handle symlinks correctly. The new canonical() free function walks the path resolving symlinks, so now works correctly even when symlinks are present. For the curious, David's rationale for the function follows. --Beman Canonicalized pathnames are an important security measure when you want to do validity checking on your path (eg does this path live in /home/goodguy or /home/badguy?). There are several implementations of canonicalization functions, ranging from POSIX's realpath() function, to the GNU library's canonicalize_file_name(). For platform-independent implementations, Java provides the File.getCanonicalFile() method. CERT advocates the use of canonicalized filenames in its Secure Coding rules for both C FIO02-C. Canonicalize path names originating from untrusted sources https://www.securecoding.cert.org/confluence/x/EAY and Java IDS02-J. Canonicalize path names before validating them https://www.securecoding.cert.org/confluence/x/S4EVAQ

1 0

Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
by Andrew Hundt 06 Oct '11

06 Oct '11

I've implemented a small companion class to boost.array that functions like a stack allocated vector with fixed capacity. The motivation for this class came when I was using boost.array in an interprocess library, when I realized that I actually desired an adjustable size boost.array, without the complexity of the vector class in the interprocess library. The result is StaticVector, which is boost.array directly modified with a size in front of the array, and added facilities to match std::vector. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Sample Code: StaticVector<std::size_t,3> three; three.push_back(5); three.push_back(2); // size: 2 capacity: 3 three.push_back(3); three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded So here is the big question: Is there any interest in the class? Cheers! Andrew Hundt

7 12

[Review:Algorithms] all.hpp vs std::count
by Andrew Hundt 05 Oct '11

05 Oct '11

What is the advantage of the functions in all.hpp over std::count? I feel like one could simply call (in pseudocode) std::count == 0, std::count == 1, std::count == class.size() to achieve the same effect. Cheers! Andrew Hundt Robotics Engineer National Robotics Engineering Center Carnegie Mellon University 908-720-5501

5 11

[website] URL for most recent version of BoostBook docs?
by Beman Dawes 05 Oct '11

05 Oct '11

http://www.boost.org/doc/libs/1_47_0/doc/html/boostbook.html is the URL for 1.47.0. What URL always points to the most recent version? --Beman

4 4

[functional/hash] integer hash function
by Tim Blechmann 05 Oct '11

05 Oct '11

i was quite amazed that the default hash function for integers seems to be the identity function: from boost/functional/hash/hash.hpp: inline std::size_t hash_value(int v) { return static_cast<std::size_t>(v); } while this is probably the most efficient hash function, it is also the worst possible. is this done intentionally? tim

5 6

[operators] The future
by Daniel Frey 04 Oct '11

04 Oct '11

Hello, I would like to gather some feedback on my plan for the future of the Boost.Operators library. As the maintainer, I have to admit it was a pretty easy job for the last years, as not much has happened. The codebase is full of work-arounds, but it seems to be pretty stable. Another member of the list recently suggested an enhancement, see <https://svn.boost.org/trac/boost/ticket/5929>, which I think shows the first of two points that I would like to straighten out in the future: 1) The library currently mixes two domains, arithmetic operators and iterator helpers 2) No rvalue-support The first point, as already mentioned in the above ticket, could be solved by separating the two parts. I imagine the future Boost.Operators library to concentrate on arithmetic operators, while another, new library could concentrate on iterator and container helpers. Maybe there is an overlap with other libraries (Boost.Iterators), but I'll leave that to others. The (new) Boost.Operators library could provide a base for implementing the iterator helpers just like the current Boost.Operators library does - while there is no dependency in the reversed direction, i.e., the Boost.Operators library does not depend on iterators. The second point is actually a strong argument for a rewrite and a different interface. I have an implementation ready and as it turns out, rvalue-support could be used to optimize some cases *only* if the type itself is commutative. This property of a type is not taken into account in the current Boost.Operators library, which is why the new implementation has different bases, including a new set of grouped operators. See the end of this post for a list of the proposed bases. Note that the new grouped operators are also a consequence of taking commutativity into account, i.e., a field as a commutative_ring+dividable. Dropping some of the old grouped operators should not be a big deal, since grouped operators are more-or-less convenience only, the real functionality is in the "Simple Arithmetic Operators" (see current documentation). If there is a strong need, we could also preserve the old implementation as <boost/legacy/operators.hpp>, but I think it's also practical to drop it completely - old Boost versions are still available for those who need them. To sum up the plan: - Concentrate on arithmetic operators - Add rvalue-support - New set of convenience/grouped operators due to rvalue-support - Drop the old implementation, iterator support Someone else (Olaf?) then takes care of the iterator helpers. So, what do you think? Regards, Daniel ----------------------------- Proposed new base classes: equality_comparable less_than_comparable totally_ordered equivalent partially_ordered addable commutative_addable subtractable subtractable_left multipliable commutative_multipliable dividable dividable_left modable modable_left ring commutative_ring field andable andable_left commutative_andable orable orable_left commutative_orable xorable xorable_left commutative_xorable bitwise bitwise_left commutative_bitwise left_shifttable right_shiftable shiftable incrementable decrementable unit_steppable

10 18

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 04 Oct '11

04 Oct '11

Dear Ion and Boost.Interprocessors, I'm very interested in the status of support for using shared memory across processes of mixed bitnesses particularly on Windows. I see from the thread here: http://lists.boost.org/Archives/boost/2011/02/177696.php and the trac here https://svn.boost.org/trac/boost/ticket/5230 that this has been looked at before. The ticket is marked as fixed in 1.47, but I believe the changes are actually only on trunk at the moment? I appreciate Ion saying in that Trac ticket that support is experimental and requires feedback from real-world users. I'd be happy to be such a guinea pig user. But to help me along the way, I have a couple of queries: - with trunk, what features from Boost.Interprocess are intended to work across bitness? (I'd plan to build both the 32-bit and 64-bit with the same version of MSVC). For instance, might interprocess::managed_shared_memory, interprocess::vector and interprocess::basic_string be expected to work? - Is it possible to back port the changes from trunk to 1.47 or 1.46.1? If so what would I need to copy? AlignedStorage, Move and Interprocess? Many thanks for any help on this, Pete Bartlett

1 0

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7

Interest in simple unformatted binary stream I/O?
by Beman Dawes 04 Oct '11

04 Oct '11

There have been many requests on Boost and various C++ newsgroups for unformatted binary I/O. For example, in 2003 Neal Becker wrote: I wonder if anyone has code for implementing unformatted I/O? What I have in mind is for the simple case where the application that reads data knows the data types, so this is not as complicated as the general marshalling situation. This proposal provides a very simple solution that works with standard library input and output streams. The one caveat is that the stream must be opened with filemode std::ios_base::binary to avoid certain data values being treated as line endings. int main() { fstream f("binary_stream_example.dat", std::ios_base::trunc | std::ios_base::in | std::ios_base::out | std::ios_base::binary); int32_t x = 0x01020304; int32_t y = 0; f << bin(x); // write 4 bytes f.seekg(0); f >> bin(y); // read 4 bytes BOOST_ASSERT(x == y); return 0; } For docs, header, and example code, see http://mysite.verizon.net/beman/binary_stream/binary_stream.html http://mysite.verizon.net/beman/binary_stream/binary_stream.hpp http://mysite.verizon.net/beman/binary_stream/binary_stream_example.cpp Is there interest in this for Boost? It seems way too small and simple to be a whole library itself. Are there any ideas where it should live and what namespace it should be in? --Beman

15 26

[accumulator] no type named 'result_type' in 'boost::fusion::void_'
by Vicente J. Botet Escriba 04 Oct '11

04 Oct '11

Hi, I'm getting this error on trunk ../../../boost/accumulators/framework/extractor.hpp:36:74: error: no type named 'result_type' in 'boost::fusion::void_' typedef typename mpl::apply<AccumulatorSet, feature_type>::type::result_type type; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ I'm including #include <boost/accumulators/framework/accumulator_set.hpp> #include <boost/accumulators/statistics/count.hpp> If I add the following include everything is OK. #include <boost/accumulators/accumulators.hpp> Is this a know issue? Best, Vicente

2 4

[optional] Thoughts on disallowing assignment for wrapped references.
by Mostafa 04 Oct '11

04 Oct '11

Boost.Optional seems to really have a lot of potential for what I want to do, but one thing about it has been nagging me, specifically it's assignment semantics for wrapped references being different from the semantics of bare C++ references (see http://tinyurl.com/4yna643) Has/have the author(s) of the library or anyone considered disallowing assignment for Boost.Optional types that wrap references, and if so, what would the consequences of this entail? I rather disallow assignment in this case, then have what's basically a wrapper class behave partially differently than the type it's supposed to emulate. Thanks in advance, Mostafa

6 34

help with boost::property_tree erasing nested entries please
by Bernd Prager 04 Oct '11

04 Oct '11

All, I would appreciate some help with erasing a nested node entry in property_tree. Below is my example. (2) works, but only erases an entire tree. (1) doesn't but it's really what I want. Thank you for any help. (I'm sorry, the documentation is not very verbose on this topic.) -- Bernd #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> using namespace std; namespace pt = boost::property_tree; int main(void) { pt::ptree props; props.put("db.name", "Sesame"); props.put("user.name", "Ali Baba"); cout << props.erase("db.name") << " children erased. " << endl; // (1) cout << props.erase("db")<< " children erased. " << endl; // (2) }

2 2

Re: [boost] [Review:Algorithms] My review
by Brent Spillner 04 Oct '11

04 Oct '11

Also late! My apologies. On Mon, 03 Oct 2011 00:46 Phil Endecott wrote: >implementation. Furthermore, the amount of discussion of a proposal >seems to be in inverse proportion to its complexity! To avoid getting ...which probably tells us more about the number of people who take the time to fully understand more complex submissions than it does about anything else... >bogged down in endless discussions of trivia we should set a lower >bound on the complexity of submissions, and these functions are below >that threshold. I disagree... these algorithms are certainly trivial, but also frequently used by most programmers. A high-quality implementation has the potential to eliminate (well, reduce) the need for every C++ programmer to maintain medium-quality versions in a personal toolkit, saving a tremendous number of aggregate man-hours (initial development, maintenance, and reading others' versions as a possible source of defects in unfamiliar code) worldwide. Note that the original submission has already been substantially improved based on reviewer feedback--- how many of the tens of thousands of one-off versions out there have the same issues, or worse? Anyway, my own review: > * What is your evaluation of the design? Overall design is fine--- these algorithms are simple and should be kept so. Like several other reviewers, I believe some of the function and header names are suboptimal (increasing() should be nondecreasing(), any.hpp should be any_of.hpp, etc.), and as much as I abhor a boat shed argument I do honestly believe that they be reevaluated before release. There does seem to be a lot of redundant code that could be refactored out of the individual search algorithms, but that's an internal issue. > * What is your evaluation of the implementation? Adequate. I filed several issues on GitHub, and others contributed more. Marshall has been extremely responsive, and I think it's clear that the library will be top-notch before release. > * What is your evaluation of the documentation? Incomplete, but what library is in version 1? Certainly adequate for release. > * What is your evaluation of the potential usefulness of the library? Quite. Actually, I think the search algorithms are hindered a bit in this respect by their documentation (strengths and weaknesses in given situations, which to use, caveats, etc.), but that's been beaten to death here and on GitHub and is already being remedied by Marshall. > * Did you try to use the library? With what compiler? Did > you have any problems? No. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I carefully read the code and skimmed the docs, and logged my detailed comments as GitHub issues (almost all of which have already been addressed.) > * Are you knowledgeable about the problem domain? Fairly, although I'm not sure I'd ever seen the BMH search before. In summary, I think Algorithms should certainly be accepted, and like Phil and many other reviewers I think it's a good framework for other small submissions that would be useful to the community at large but don't justify a separate library.

1 0

where to go to with libraries for a narrow problem domain?
by Thijs (M.A.) van den Berg 03 Oct '11

03 Oct '11

I'm part of a community that work in financial mathematics, and every now and then there are ideas to start library development on narrow sub-fields. A thing missing is a centralized place -exactly like boost- where people can submit and acquire high quality *narrow* C++ source code libraries. There are a lot of fragmented initiatives in mathematical finance: there is overlap between projects, quality may vary a lot, etc. The landscape resembles a bit the pre uBlas era for matrices. It there a place just like boost (good quality C++ source code libs with a large community) for narrow libraries? If not, wouldn't it be possible to create a subsection at boost for narrow libraries? Something like the Matlab toolboxes for C++ source libraries?

3 2

Tokenizer docs: bug?
by Olaf van der Spek 03 Oct '11

03 Oct '11

Hi, > explicit char_separator() Explicit? Doesn't explicit only apply to one argument constructors? > The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped. std::string s("[1][3][5][]9"); BOOST_FOREACH(auto i, boost::tokenizer<>(s)) std::cout << i << std::endl; This outputs only numbers. Shouldn't the brackets be included too? Olaf

1 0

[chrono] now() performance on several clocks
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Le 28/09/11 13:29, Vicente J. Botet Escriba a écrit : > Le 28/09/11 13:12, Stewart, Robert a écrit : >> Vicente J. Botet Escriba wrote: >>> Le 27/09/11 17:42, Stewart, Robert a écrit : >>> >>>>> - There's no information on Boost.Timers overhead relative >>>>> to timing the target code. >>>>> >>>> Are you asking for the overhead of the time computations or >>>> the reporting? >>> The former. >>> >>> > I will add some performance tests in Boost.Chrono to measure the time > spent by the now functions and the difference between two time_points > for each one of the clocks, so we can be fixed. > > Hi, I have measured the cost of calling Clock::now for some clocks and platforms. All the test are run with variant=release. The measured code stores on a vector the result of Clock::now() 10000000 times. /// for (int i=size-1; i>=0; --i) { vec[i]=Clock::now(); //vec[i]=typename Clock::time_point(typename Clock::time_point::duration(i)); } /// On iMac 3.06 GHz Inter Core i3. clang2.9 system_clock around 44 nanoseconds. steady_clock/high_resolution_clock around 24 nanoseconds. process_real_cpu_clock more than 600 nanoseconds. process_user_cpu_clock more than 1000 nanoseconds. Currently process_real_cpu_clock uses clock() and process_user_cpu_clock uses times(). On MinGw Windows msvc.10 system_clock around 32 nanoseconds. steady_clock/high_resolution_clock more that 2400 nanoseconds. process_real_cpu_clock around 84 nanoseconds. gcc-4.6 system_clock around 38 nanoseconds. steady_clock/high_resolution_clock more that 2500 nanoseconds. process_real_cpu_clock around 110 nanoseconds. Clearly I need to make more measures for the Windows based steady_clock code. The program is available on the trunk under the libs/chrono/perf directory. Could someone run the program on a posix platform? Please let me know if you think there is a better way to make these measures. Best, Vicente

1 0

[Interprocess] an XSI message queue
by Matthieu Dorier 03 Oct '11

03 Oct '11

Hello, I recently had to work with XSI shared memory objects using Boost, and I noticed that their is no implementation of the message_queue class on top of XSI shared memory objects. So I have created a new file xsi_message_queue.hpp (attached) defining this type of message queue. It is mostly based on the structures and classes defined in message_queue.hpp (in particular the messages, message headers, etc. and the mutex mechanism used in message_queue). It works fine in my project, but should certainly be more extensively tested if you want to integrate it in a future release. I noticed that contrary to other structures of the Interprocess library, message_queue is not very generic: you cannot simply change a template argument to make it work properly with XSI or Windows shared memory objects. Maybe a good step forward to improve it would be to make it more generic. -- Matthieu Dorier ENS Cachan, antenne de Bretagne Département informatique et télécommunication http://perso.eleves.bretagne.ens-cachan.fr/~mdori307/wiki/

1 0

[test] more files missing
by Jürgen Hunold 03 Oct '11

03 Oct '11

Hi Gennadiy, it seems you forgot to add at least the following files to svn: On Monday, 3. October 2011 08:59:48 gennadiy.rozental(a)thomson.com wrote: > +#include <boost/test/tree/observer.hpp> > +#include <boost/test/tree/test_unit.hpp> > +#include <boost/test/tree/visitor.hpp> > +#include <boost/test/tree/traverse.hpp> > +#include <boost/test/tree/test_case_counter.hpp> And btw. could you please update your email on svn.boost.org? 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 2

the 'not' keyword
by Lorenzo Caminiti 03 Oct '11

03 Oct '11

Hello all, This might not be a "pure" Boost question but do you know if compilers portably support the 'not' keyword? int main ( ) { if(not false) return 0; return 1; } This compiles on GCC but not on MSVC... Why? If you look at the C++ standard, it says that 'not' is part of the language... Thanks a lot. --Lorenzo -- Sent from my mobile device Lorenzo

7 6

[accumulator] A lot of unused "parameter" warnings
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Hi, I'm getting a lot of warnings while using Boost.Accumulators. Would you accept a patch that resolve them by commenting the parameter name? Best, Vicente In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:19: In file included from ../../../boost/parameter/parameters.hpp:45: ../../../boost/parameter/aux_/tagged_argument.hpp:123:60: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](default_<key_type,Default> const& x) const ^ ../../../boost/parameter/aux_/tagged_argument.hpp:129:58: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](lazy_default<key_type,F> const& x) const ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:23: In file included from ../../../boost/accumulators/framework/depends_on.hpp:39: In file included from ../../../boost/fusion/include/mpl.hpp:11: In file included from ../../../boost/fusion/mpl.hpp:23: In file included from ../../../boost/fusion/mpl/has_key.hpp:11: ../../../boost/fusion/sequence/intrinsic/has_key.hpp:71:29: warning: unused parameter 'seq' [-Wunused-parameter] has_key(Sequence const& seq) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:29: In file included from ../../../boost/fusion/include/any.hpp:10: In file included from ../../../boost/fusion/algorithm/query/any.hpp:13: ../../../boost/fusion/algorithm/query/detail/any.hpp:112:36: warning: unused parameter 'it' [-Wunused-parameter] static bool call(It const& it, F f) ^ ../../../boost/fusion/algorithm/query/detail/any.hpp:112:42: warning: unused parameter 'f' [-Wunused-parameter] static bool call(It const& it, F f) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:14: ../../../boost/accumulators/numeric/functional.hpp:188:5: warning: unused variable 'plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:188:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:5: warning: unused variable 'minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:5: warning: unused variable 'multiplies' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:5: warning: unused variable 'divides' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:5: warning: unused variable 'modulus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:5: warning: unused variable 'greater_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:5: warning: unused variable 'less_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:5: warning: unused variable 'equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:5: warning: unused variable 'not_equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:200:5: warning: unused variable 'assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:200:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:5: warning: unused variable 'plus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:5: warning: unused variable 'minus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:5: warning: unused variable 'multiplies_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:5: warning: unused variable 'divides_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:5: warning: unused variable 'modulus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:207:5: warning: unused variable 'unary_plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:207:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:208:5: warning: unused variable 'unary_minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:208:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:209:5: warning: unused variable 'complement' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:209:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:210:5: warning: unused variable 'logical_not' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:210:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:414:28: warning: unused variable 'average' [-Wunused-variable] op::average const &average = boost::detail::pod_singleton<op::average>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:417:28: warning: unused variable 'as_zero' [-Wunused-variable] op::as_zero const &as_zero = boost::detail::pod_singleton<op::as_zero>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:418:27: warning: unused variable 'as_one' [-Wunused-variable] op::as_one const &as_one = boost::detail::pod_singleton<op::as_one>::instance; ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:16: ../../../boost/accumulators/framework/parameters/weight.hpp:17:1: warning: unused variable 'weight' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weight) ^ ../../../boost/accumulators/framework/parameters/weight.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weight) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:18: In file included from ../../../boost/accumulators/accumulators.hpp:21: ../../../boost/accumulators/framework/parameters/weights.hpp:17:1: warning: unused variable 'weights' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weights) ^ ../../../boost/accumulators/framework/parameters/weights.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weights) ^

4 5

[Review:Algorithms]
by Edward Diener 03 Oct '11

03 Oct '11

This is my late review of the Boost Algorithms library. First a minor irritation. I am used to downloading a library in its own directory separate from a Boost tree, and then being able to generate docs and tests by running the bjam files with a line such as: 'bjam --boost=C:/Programming/VersionControl/boost toolset=msvc-10.0' where I point to a Boost tree with the --boost parameter. This works if the bjam root file has the canonical search for BOOST_ROOT given in the sandbox example library's jamroot.jam. It's really simple just to copy over that jamroot.jam into the root directory of the library before distribution, but almost no one seems to do this automatically. So I always have to do it myself. This is a PITA. So I wonder if we can not put on some web page for library developers this simple jamroot.jam and tell developers to use it. * What is your evaluation of the design? Clean and clear. * What is your evaluation of the implementation? I did not look. * What is your evaluation of the documentation? Very good. My only suggestion is that soem sort of extended discussion of advantages and disadvantages of search algorithms would be possible in the docs which would allow an end-user to decide what search algorithm would be optimal for particular practical situations. * What is your evaluation of the potential usefulness of the library? Very useful and very much needed. There is a little overlap with some other Boost libraries as mentioned in Dave Abrahams initial introduction to the library in his post about the start of the review, but I very much like the general nature of the algorithms where other libarries are more specific to their domain. * Did you try to use the library? With what compiler? Did you have any problems? I tried quickly with MSVC-10.0 and gcc-4.6.0, neither with any problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A very quick evaluation but a thorough reading. * Are you knowledgeable about the problem domain? Aside from the search algorithms I have used various forms of nearly all the other algorithms in my programming career so I understand what they are about and how useful they can be. I vote for the Boost Algorithms library to be accepted into Boost and I look forward to other general purpose algorithms being added to it in the future. Boost should be leading the way in introducing general purpose algorithms that work on C++ sequences, via range or iterators, given the fact that the C++ standard library changes as slowly as the C++ standard and new algorithms can be quite useful, as these are. Kudos to Marshall Clow for a clean and effective design and keeping the initial algorithms focused on usefulness and end-user simplicity, both of which I value very highly.

2 1

[Review:Algorithms] My review
by Phil Endecott 03 Oct '11

03 Oct '11

Here is my review of the proposed Boost.Algorithm library. A problem with Boost in the past has been that the contributions have primarily been larger projects, while smaller things have not been submitted despite their potential usefulness because of the effort required to prepare and review them (real or perceived). I therefore very much welcome the idea of a library to which smaller contributions can be submitted - though we have yet to find out how such submissions will be processed, and perhaps some discussion of this would be helpful now. (I have an implementation of an edit distance / edit script "diff" algorithm that could probably be contributed.) Regarding the particular algorithms initially included: Search algorithms: These are certainly worth having and the implementations look satisfactory. Jim Xochellis has made some comments about relaxing the iterator requirements and this would be worth doing if possible. Reducing the size of the tables by storing uint8_t for short patterns (especially on 64-bit systems where 7/8 of the space is currently wasted) might be worthwhile, though it could conflict with the idea of relaxing the iterators. Perhaps something can be done with the traits class to make it easier for the user to tweak this, e.g. passing the skip-distance type as a defaulted template parameter to the traits class. Documentation needs to be improved as previously discussed, especially to guide the user to select the correct algorithm. Other algorithms i.e. Ordering & clamping: I have come to the conclusion that these algorithms are too trivial to be included in Boost. Anyone who wants one of these functions can easily implement their own in a "personal utility library" or similar; they are trivial to code and there are no subtle issues or portability problems. The difficulty with putting them in Boost is that there are different possibilities for naming and aspects of the behaviour and there is no one version that will suit everyone - for example, I would not want to use a version of clamp that is three times slower than my preferred implementation. Furthermore, the amount of discussion of a proposal seems to be in inverse proportion to its complexity! To avoid getting bogged down in endless discussions of trivia we should set a lower bound on the complexity of submissions, and these functions are below that threshold. > * What is your evaluation of the design? Straightforward. > * What is your evaluation of the implementation? Satisfactory. > * What is your evaluation of the documentation? Needs some work, but I'm confident this will happen. > * What is your evaluation of the potential usefulness of the library? Search algorithms useful. Other stuff not sufficiently useful. > * Did you try to use the library? With what compiler? Did > you have any problems? I did some simple tests and benchmarks with gcc on ARM Linux. I do recall some "unused argument" warnings that could be suppressed by removing or commenting the arg name. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I've read all of the docs and much of the code, written some test / benchmark programs, and taken part in discussions. > * Are you knowledgeable about the problem domain? Not especially. In summary, my opinion is that the library should be accepted in part. Regards, Phil.

2 1

[Review:Algorithms] Boost.Algorithms Review
by Stewart, Robert 02 Oct '11

02 Oct '11

Boost.Algorithms should be accepted into Boost. Many issues have been raised during the review and during the pre-review using Code Collaborator. I have confidence that Marshall will carefully weigh all of the ideas and concerns that have been raised and apply those that are sensible and appropriate. __________ Design I have a problem with the physical design. all.hpp is not the file I'd expect to find any_of or none_of. I'd prefer to see them moved to any.hpp and none.hpp. I realize that none_of must test all elements in a range in the case when no element matches the predicate, but that doesn't make me think of all.hpp as the place to find it. I think "is_ordered_until" is a better name than "is_ordered" for the reasons previously elucidated. As to your dislike of "is_ordered_until", just read it as "the range is ordered until the element referenced by the return value". As there may well be other search algorithms than those you've provided thus far, I think each should be in a separate header and documented separately. Otherwise, search.hpp may grow to be ridiculously large. __________ Implementation I find the naming of your formal parameters to be inconsistent: first, last, p, lo, hi, val, and range. A more consistent set of names would be first, last, predicate, low, high, value, and range. I'd even accept "pred" in that list. Likewise, the template parameter names are inconsistent: InputIterator, Predicate, R, V, Pred, FI, patIter, and corpusIter. A more consistent set of names would be InputIterator, Predicate, Range, Value, ForwardIterator, PatternIterator, CorpusIterator. If you'd prefer to abbreviate "Iterator" with "It" or "Iter", then I'd abbreviate the categories, too: InIt, FwdIt, RandomIt, etc. You presume that all C++ implementations with a specific value of __cplusplus provide std::all_of, std::any_of, and std::none_of. Is that portable? Indentation is inconsistent. The use of mpl::identity for clamp's arguments should be documented for future maintainers. is_ordered() uses a one-line if/return and a two-line for no apparent reason. That inconsistency increases the chances of a maintainer failing to notice one or the other. search.hpp uses BOOST_ALGO_DEBUG. "ALGO" should be spelled out. Many of the functions controlled by that manifest constant use camelcase and should be all lower case. I was expecting more algorithm documentation in search.hpp. The code is not overly complex, but there should at least be pointers to literature on the implementation of each algorithm. However, as such literature may not always be accessible, copying pertinent information to the header would be helpful to future maintainers. __________ Documentation Specific notes and corrections are listed at the end of this message. I'd like to see the complexity, behavioral, and iterator information be documented for each algorithm separately rather than for a group, such as you've done in paragraphs 3 and 4 of all.html. Note that the complexity is described below the clamp algorithms and above the all_of, any_of, and none_of algorithms. This should be consistent. The algorithms are all function templates, so "the function <algorithm-name>" is incorrect. Thus, instead of "the function all_of", write "all_of". Look for other uses of "function" and "functions" for similar terminology issues. While is_increasing, is_decreasing, is_strictly_increasing, and is_strictly_decreasing are implemented using is_ordered, that is by no means a requirement. Consequently, I'd prefer that each was documented separately. Complexities written as should be written in all upper case: O(N), O(M x N), etc. The treatment of the two internal tables used by the search algorithms is inconsistent ("first", "second", "skip", etc.). I'm not even sure they should be mentioned as you do. I realize that you want to document memory usage and customization options, but perhaps the better approach is to clearly document the traits class and its usage as well as the memory usage in terms of the pattern and corpus character sets. For example, K-M-P allocates N bytes per element in the pattern. The Reference section for each algorithm should include "#include <boost/algorithm/foo.hpp>", to permit copying and pasting, plus complexity and template parameter requirements. Template parameters should be documented just as function parameters. Thus, for example, in the reference page for knuth_morris_pratt_search(), there should be a section that describes the two iterator types including their iterator category as well as their relationship (which elsewhere you mention requiring that their value_types be identical). The boyer_moore_search() and boyer_moore_horspool_search() algorithms do not have reference pages. There are no examples in the text. There should be an example for each algorithm. The search algorithms' traits classes are not documented. __________ Usefulness This library, in its current state has certain utility. As a place to incorporate future algorithms that don't deserve a library of their own, it has enormous utility. __________ Usage I did not try to use the library due to time constraints. __________ Effort I spent many hours studying and commenting on the code during the pre-review and now, reading the documentation, etc. __________ Domain Knowledge I have no experience designing string search algorithms. I have used many algorithms. I have designed a good deal of generic code. Thus, I have broad domain knowledge, but nothing extraordinary. __________ Documentation Issues _____ Description and Rationale 2nd para, 3rd sent: missing "and" from "tested, reviewed, documented" _____ Future plans Written with this review in mind, this section is fine, but for an accepted library, it isn't right. I suggest something like this: "This library will be extended by algorithms submitted or suggested by Boost developers and users. The Adobe Source Library (http://stlab.adobe.com/) for example, contains many useful algorithms with documentation and test cases that might be culled for inclusion in this library. Knuth's _The Art of Computer Programming_ is full of algorithm descriptions, too. Various algorithms have been created and documented in magazines, online forums, etc., or even just for personal use. All of these sources, and more, can provide fodder for algorithms to add to this library. "Adding new algorithms will require some form of review, but will not be subject to the usual Boost review process. The Boost.Algorithm maintainer would have the ability to add algorithms without review, but this will not be the case for non-trivial algorithms. Non-trivial algorithms, and possibly even trivial algorithms, will be subjected to a mini-review. This will be a call for Boost developers to study the proposed algorithms with the goal to get more minds to consider their design and utility to ensure their broad utility." _____ Header: 'all.hpp' The heading can just be "all.hpp". 1st para, 1st sent: Strike "The header file". 1st para, 2nd sent: any_of does not verify that every element has a particular property. 2nd para: All three of these algorithms is in C++11. Try this wording: "The iterator-based versions are part of the standard library in C++11 (§25.2 Non-modifying sequence operations). Boost.Algorithms will use the standard library versions of these algorithms when available." 4th para: The algorithms will not work on output iterators. Therefore, you should indicate that they require input iterators. _____ Header: 'clamp.hpp' The heading can just be "clamp.hpp". 1st para, 1st sent: Strike "The header file". The description is insufficient, which you seem to understand since you quoted "clamp". I suggest this instead: "clamp.hpp contains function templates to constrain a value to be within the inclusive range formed from supplied boundary values." 2nd para, bullets: s/iff/if. "iff" is overly proscriptive on the implementation. That is, lo could be returned if v == lo without affecting the result. 3rd para: "also" this sentence refers the previous paragraph, which uses < in the bullets, but this is a bit awkard. It would be better to describe each version of clamp separately. The second would have the same bulleted list, but would use p(v, lo) and p(hi, v). _____ Header: 'ordered.hpp' The heading can just be "ordered.hpp". 1st para, 1st sent: Strike "The header file". Strike the parentheses. 2nd para, 4th sent: Surely is_ordered returns the end iterator for sequences of less than two elements. 3rd para: s/are will not/will not/ 5th para, 1st sent: I'd prefer, "There are also a number of function templates that use is_ordered to determine whether an entire sequence satisfies a particular ordering." _____ Header: 'search.hpp' The heading can just be "search.hpp". ___ Overview 1st para, 1st sent: Strike "The header file". 3rd para: merge with the 2nd para 4th para: Change from first person and quoting to "For each of these search algorithms, the sequence being searched is referred to as the pattern, and the sequence being searched as the corpus." 5th para, 1st sent: Change to "These search algorithms generate tables to make searches faster." 5th para, 3rd sent: s/To help with this/To provide control over the overhead/ 5th para, 3rd sent: s/;/:/ 5th para, 4th sent: s/the search/the search, thereby using the same generated table(s) for multiple searches./ 7th para: s/and here are/and here is/ 8th para, last sent: Must I1::value_type be the same as I2::value_type or must they merely be comparable? ___ Boyer-Moore 1st para: The wording at the end is confusing. I think you mean, "benchmark used in the literature on practical string searching." 2nd para: merge with the 1st para s/target string (pattern) that is being search for/pattern/ s/algorithm, while still...can have/algorithm has O(N) complexity, where N is the corpus length, but can have/ s/algorithms; it doesn't/algorithms because it doesn't/ s/gets faster as the key being search for becomes longer/is faster for longer patterns/ Note: s/skip table (the second one) as stored as an/skip table (the second one); it is stored as a/ s/are (say) UTF-16 text; in that case, the/are UTF-16 text, for example, since the/ s/The B-M and B-M-H objects take a 'traits' template parameter which lets/The traits template parameter of the B-M and B-M-H class templates allow/ s/paramater/parameter/ ___ Boyer-Moore-Horspool 1st para: s/Boyer-Moore, and has/Boyer-Moore, but has/ 2nd para: s/algorithm an internal/algorithm uses an internal/ You should mention that the traits template parameter allows using a different container to store that data so the memory usage can change. Unless this reference is to the "first" table. ___ Knuth-Morris-Pratt 2nd para: s/looking for the match - instead of just at the next entry/looking next for a match rather than just advancing to the next element/ _____ Reference I don't think the all.hpp content should be in reference.html. It should be found by a link like the other three headers. The declarations for all.hpp are compressed too much. Some vertical whitespace would be helpful. Why is "Marshall Clow" in the "Header <boost/algorithm/all.hpp>" section? It also appears in the clamp.hpp reference page. _____ Function template clamp (both) Returns: Could be improved: "lo if p(val, lo) returns true, hi if p(hi, val) returns true, and val otherwise." _____ Header <boost/algorithm/ordered.hpp> The declarations are compressed too much. Some vertical whitespace would be helpful. _____ Function template is_ordered (iterators) Returns: Could be improved: "the iterator it, in the range [first, last), for which p(*it) returns false, or last if there is no such iterator." _____ Function template is_ordered (range) Returns: Could be improved: "the iterator it, in range, for which p(*it) returns false, or boost::end(range) if there is no such iterator." _____ Function template is_increasing (iterators) Returns: "true if each element in [first, last) is greater than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_increasing (range) Returns: "true if each element in range is greater than or equal to the previous element or range has fewer than two elements." _____ Function template is_decreasing (iterators) Returns: "true if each element in [first, last) is less than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_decreasing (range) Returns: "true if each element in range is less than or equal to the previous element or range has fewer than two elements." _____ Function template is_strictly_increasing (iterators) Returns: "true if each element in [first, last) is greater than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_increasing (range) Returns: "true if each element in range is greater than the previous element or range has fewer than two elements." _____ Function template is_strictly_decreasing (iterators) Returns: "true if each element in [first, last) is less than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_decreasing (range) Returns: "true if each element in range is less than the previous element or range has fewer than two elements." _____ Header <boost/algorithm/search.hpp> The declarations are compressed too much, though the horizontal whitespace does help in the latter half. Some vertical whitespace would be helpful. _____ Class template boyer_moore The constructor deserves information on memory allocated, what exceptions might be emitted, etc. The function call operator should include information on its behavior, complexity, etc. The private member functions should not be listed. _____ Class template boyer_moore_horspool Ditto _____ Class template knuth_morris_pratt Ditto _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 7

Is someone interested in container CompressedVector, a vector-like storage for integer types
by Alexander Bulovyatov 02 Oct '11

02 Oct '11

Hi! Assume you want an interface as for vector<unsigned int>, but know that elements have only N significant bits, say 17. In this case the container will save 46% memory compared to vector<unsigned int>. CompressedVector internally stores elements as a dynamic bitset (vector<size_t>) and uses bitshift ops to put/get significant bits into one or two size_t elements. It's similar to vector<bool> and dynamic_bitset, and has the same drawback, it's not a proper STL container. Anyway, the container is simple, efficient and quite fast. It will work best for very long arrays of indexes. Since its storage is continuous, it can also be used to speed up IO (load/store to disk, network transfers) acting as a very fast compression.

2 4

metatest interface update, better Boost.Test integration
by Ábel Sinkovics 02 Oct '11

02 Oct '11

Hi, Thank you for the feedback about my library so far. I've done changes to the interface of the metatest library (currently part of mpllibs - https://github.com/sabel83/mpllibs) The purpose of the changes was to improve compatibility with Boost.Test. They make it easy to embed assertions of compile-time predicates in runtime test functions. The result and pretty-printed reason of a compile-time predicate is represented by an object of type test_result (http://abel.web.elte.hu/mpllibs/metatest/test_result.html) at runtime. These objects can be built using a template function, test_result::build. It evaluates the predicate and does the pretty-printing. operator<< is overloaded for test_result, thus one can easily display these objects in output streams. This is useful for passing the results of compile-time tests to runtime unit testing frameworks. I've implemented the metaprogramming equivalent of the BOOST_<level>() macros as template functions (meta_<level>). One can use them the following way: meta_check< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE); meta_warn< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE, "Some message"); // ... I've used a template function instead of a macro to improve the error messages about syntax errors in the predicates. The template function takes a location (http://abel.web.elte.hu/mpllibs/metatest/location.html) object as argument and metatest provides a macro, MPLLIBS_HERE, that constructs a location object with the current filename:line values. The template functions call BOOST_<level>_MESSAGE. A disadvantage of this solution is that the error reports contain two filename:line locations: the location of BOOST_<level>_MESSAGE in the integration function and the location of MPLLIBS_HERE (which is the one the user will be interested in). I've added a new example demonstrating these integration functions. You can find it in libs/metatest/example/boost_test_assertion in the source tree. I've tested the new interface with the same three compilers I've been testing the libraries with (gcc 4.5, clang 2.8, Visual C++ 10). I'm happy to receive feedback about the new interface. I'm interested if people find it useful. Regards, Abel

2 3

[contract] the volatile issue
by Lorenzo Caminiti 01 Oct '11

01 Oct '11

Hello all, N1962 does not indicate that contracts for volatile members should be handled in any special way (in fact, volatile is not discussed at all in N1962). My library does the following for volatile members: 1) The object `this` is const volatile (and not just const) while checking preconditions, postconditions, and invariants for a volatile member. 2) By default, class invariants of volatile members are the same as for non-volatile members. However, programmers can specify a different set of class invariants for volatile and non-volatile members if they wish to do so. The reason for 2) is that when programming a volatile member that overloads a non-volatile member, programmers can already specify a different set of preconditions and postconditions. Therefore, it seemed reasonable to give the option to also specify a different set of class invariants for volatile and non-volatile members (otherwise why would the pre/postcondition of a volatile member be different from the ones of its non-volatile version while the class invariants are forced to remain the same?). For example, consider a very strange number class which is non-negative (>= 0) when used in non-volatile context but it is non-positive (<= 0) when used in volatile context (probably not a real-life example but still...). The contracts could read: #include <contract.hpp> CONTRACT_CLASS( class (num) ) { CONTRACT_CLASS_INVARIANT( get() >= 0, // (1) volatile class( get() <= 0 ) // (2) ) public: CONTRACT_FUNCTION( public void (set) ( int x ) precondition( x >= 0 ) // 3) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public void (set) ( int x ) volatile precondition( x <= 0 ) // (4) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public int (get) ( void ) const ) { return x_; } CONTRACT_FUNCTION( public int (get) ( void ) const volatile ) { return x_; } num ( ) : x_(0) {} private: int x_; }; int main ( ) { num p; p.set(3); num volatile v; v.set(-3); return 0; } Note that via function overloading it is automatically possible to specify a different set of preconditions (and eventually postconditions) for the volatile member (4) than for the non-volatile member (5). Therefore, my library also allows to specify a different set of class invariants for volatile members (2) than for non-volatile members (1) so that the entire contract (including class invariants) can be programmed differently for volatile members if programmers wish to do so. However, if `volatile class(...)` is not used (default) the class invariants: CONTRACT_CLASS_INVARIANT( get() >= 0 ) are applied by the library to all members volatile and non-volatile. (In this case, this invariant is compiled in const volatile context iff the class has one or more volatile functions so a volatile verion of get() is only requirement if a volatile version of set() is introduced.) What do you think? Thanks, --Lorenzo

2 2

[Review:Algorithms] My review of Boost.Algorithm
by dpxguard-boost＠yahoo.gr 01 Oct '11

01 Oct '11

Hello list, First of all I have to clarify that I have only studied the three search algorithms and I can only speak about this part of the library. Furthermore my review was by no means exhaustive, I have only emphasized in few things which I had the time to notice. However I have noticed at least two showstoppers, one in documentation of the search algorithms and the other in the design of the KMP algorithm. Hence my vote for now is "no". I personally believe that the search algorithms should not be accepted, unless these issues are addressed, (or unless I am proved wrong of course) although it would be undoubtedly a good idea to have such a library in Boost. Specifically in the design issue of the KMP algorithm I am willing to help if this becomes necessary. A. Documentation issue The three search algorithms of this library does not offer any additional functionality compared to the standard std::search of the STL. On the contrary these algorithms are less generic than std::search. Consequently the only single reason that will make a developer to choose one of them instead of the std::search can be their performance superiority. (In the most notable STL implementations std::search is implemented using straightforward (brute-force) searching.) However in the documentation I have not found anything (no benchmarks, measurements, etc) that would help the user of the library to understand how fast each algorithm is and in which situations it is advisable to use it. (I believe Phil Endecott has mentioned this issue as well) This is especially important because of the following reasons: - Boyer-Moore and Boyer-Moore-Horspool have identical average time complexity, hence it is not easy for the user to choose among them based on their complexities. - Although KMP has much better worst-case complexity than a typical std::search implementation, their average complexities are practically the same. - The straightforward (brute-force) sequence searching is known to frequently outperform some KMP implementations. For all these reasons I believe that some performance analysis and performance guidelines should be added to the documentation, before this library becomes a part of Boost. For example it would be very nice to have a graphical performance comparison of these three algorithms together with the std::search, in different pattern and alphabet sizes. B. Design issue The fact that the KMP implementation of this library requires random-access iterators for both the pattern and the corpus, seems like a major design drawback to me. I also believe that this drawback virtually cripples the usefulness of the algorithm, for reasons I have already mentioned in previous posts. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

2 1