April 2011 - Boost - lists.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/

5 7

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

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

[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

[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

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

[serialization] or [spirit] JSON Archives
by Fernando Pelliccioni 08 Sep '11

08 Sep '11

Hi, After experimenting with Spirit.Qi to make a JSON parser, I had the need for a serializer. First, I thought I could serialize my model of JSON (json:: value, json: object, etc.), but that was not compatible with boost::serialization. I am currently writing a ARCHIVE for Boost Serialization, but I'm finding some problems in order to implement JSON correctly. The question is, does anyone know about some files to Boost Serialization already finished? I've seen the Archive made by Esteve Fernandez, but do not serve my purpose, because I just need JSON. I would like to develop a JSON parser which in turn is a compatible Boost Serialization serializer . Any ideas? Thanks and regards, Fernando Pelliccioni.

5 6

New version of Boost.Algorithm (proposed) in the vault
by Marshall Clow 17 Aug '11

17 Aug '11

<http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…> Changes since -008: * Better documentation all around - including doxygen. * Fixed typo-style bugs in all.hpp, and added tests to make sure they stay dead. * Better comments in clamp.hpp, and better tests. * The search algorithms now deal correctly with zero-length patterns and corpuses, and have tests for that. * The search algorithms now have tests for the compile-time assertions. * MSVC 10 compatibility Please download, try it out, and let me know! Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 2

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

[BGL] Contribute to the Boost Graph Library
by Camillo Anania 15 Jul '11

15 Jul '11

Hi all, I used BGL for around 6 months for my thesis (write a routing algorithm). I highly appreciate the BGL and I'm glad someone did it and generously gives their time to maintain/improve it. So now I would like to contribute to the development of the library and so give back something. Just a brief introduction to my profile: - a bachelor and a master in Computer Engineering - six months of experience using the BGL - good knowledge of C++ - great wish to improve my programming skills and master generic programming technique Can you please indicate me the steps I should do to start to actively help the development process? Thanks Camillo Anania

3 4

[mpl] string to type conversion
by Bartosz Marcinkiewicz 19 Jun '11

19 Jun '11

Hello, I would like to have a macro which could be used like this: STRING_TO_TYPE( MyType ) which would yield: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; Any ideas how to implement something like that? Thanks for any help, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

4 4

[unordered] equal_range is O(bucket_count()), not O(size())
by Brad Higgins 18 Jun '11

18 Jun '11

TR1 specifies that unordered_multimap::equal_range(k) worst case complexity is O(size()). However, in practice, I find that the worst case performance of boost unordred_multimap's equal_range is O(bucket_count()). Is this known? I believe the issue is with the second iterator returned by equal_range(). Specifically, if there are sparse elements in the hash table, the implementation may have to traverse many buckets to find the second iterator. I have a test that demonstrates the issue. The test makes 2 runs over an unordered_multimap, each using the same number of elements. In the second run, it calls rehash() in order to grow the bucket count by a large amount. Notice that the first run is quite fast, while the second run takes more than 10 seconds. Here are the results from my test: ---- $ ./main rehash(0) insert 1000 elements built hash, with 1543 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:00.001366 rehash(5000000) insert 1000 elements built hash, with 6291469 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:10.818002 ---- Here is my code for the test: ---- #include <iostream> #include <boost/unordered_map.hpp> #include <boost/date_time/posix_time/posix_time.hpp> typedef boost::unordered_multimap<size_t, size_t> hash_int_type; typedef hash_int_type::iterator hash_int_itr; typedef std::pair<size_t, size_t> hash_insert_type; void run_test(const size_t data_size, const size_t rehash_size) { hash_int_type hash; std::cout << "rehash(" << rehash_size << ")\n"; hash.rehash(rehash_size); std::cout << "insert " << data_size << " elements\n"; for (size_t i=0; i<data_size; i++) { hash_insert_type ins(i,i); hash.insert(ins); } std::cout << "built hash, with " << hash.bucket_count() << " buckets and " << hash.size() << " elements. Now, get some ranges\n"; boost::posix_time::ptime start(boost::posix_time::microsec_clock::local_time()); for (size_t i=data_size-1; i!=0; i--) { typedef std::pair<hash_int_itr, hash_int_itr> ret_pair; ret_pair ret = hash.equal_range(i); if (ret.first != ret.second) { hash.quick_erase(ret.first); } } boost::posix_time::ptime stop(boost::posix_time::microsec_clock::local_time()); boost::posix_time::time_duration diff_time(stop-start); std::cout << "time to obtain " << data_size << " elements: " << diff_time << "\n"; } int main(int argc, char* argv[]) { run_test(1000,0); run_test(1000,5000000); return 0; } ----- Thanks, Brad

2 3

Re: [boost] [msm] need to increase the fusion set and map size to 30
by Christophe Henry 05 Jun '11

05 Jun '11

> So i added these two statements at the beginning, and this solved the > problem. > > # define FUSION_MAX_SET_SIZE 30 > # define FUSION_MAX_VECTOR_SIZE 30 > > Perhaps we can add this somewhere in the doc. Hi Kim, Maybe I should make this subject more visible. It is described here: http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch05.html I think that FUSION_MAX_VECTOR_SIZE is actually enough, but it's only due to the fact that set is implemented in terms of vector (to be exact, as I only use fusion::set, FUSION_MAX_SET_SIZE ought to be enough, but it's not, so I suppose it's a fusion bug). Regards, Christophe

2 2

std::map::find() wrapper
by Olaf van der Spek 02 Jun '11

02 Jun '11

Hi, I've written a small wrapper for std::map::find() (and map-like containers/ranges) that returns a pointer to the value if found (or NULL if not found). See https://svn.boost.org/trac/boost/ticket/5227 The advantage is that you don't need the container type name (for ::reference), you can initialize the pointer inside an if condition, you don't have to compare against ::end() and you don't have to use ->second. For containers of pointers to objects, the wrapper could do an additional dereference. Do you think this would be useful for inclusion in Boost? Greetings, Olaf

17 61

[Config] Big changes in C++0x detection...
by John Maddock 31 May '11

31 May '11

Just a heads up, that the latest Boost.Config changes: * Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP! Thanks for your patience! John.

9 34

boost-test, why is there no DOUBLES_EQUAL?
by Sebastian Nowozin 31 May '11

31 May '11

Hello, I am a regular user of the boost test library, having used CPPunit before. I miss the following macro: BOOST_CHECK_DOUBLES_EQUAL(first, second, absolute_tolerance); which would check whether "std::fabs(first-second) <= absolute_tolerance" is true. It seems the boost test library does not support it, and instead forces/encourages users to use BOOST_CHECK_CLOSE(first, second, percent_relative_tolerance); The above macro does not really make sense in my application, I really need to check for absolute tolerances, irrespectively of the magnitude of the numbers. CPPunit has this feature as DOUBLES_EQUAL. Would you consider adding this? Thanks, Sebastian

9 16

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joel Falcou 23 May '11

23 May '11

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

18 67

Boost.Log status
by Vicente BOTET 23 May '11

23 May '11

Hi, what is going on Boost.Log? The library was accepted provisionally on March 2010 * Log - accepted provisionally March 2010; author: Andrey Semashev. Best, Vicente

7 18

Boost statechart viewer
by Petr Šilhavík 20 May '11

20 May '11

Dear Boost-Statechart developers and users, I would like to ask you to try the tool that I am developing in my bachelor thesis and give me your opinion about it. The tool is able to visualize state machines that use Boost-Statechart library. It uses Clang and LLVM *(version 2.9)* for producing the output files that can be visualized using dot. Now it can work with states (not the orthogonal states), transitions and custom reactions. You can find more information about it on the web page of this project where you can also download the source codes and see some examples of the output pictures. http://rtime.felk.cvut.cz/statechart-viewer/ I am looking forward to your answers. Best regards Petr Silhavik

4 11

[local] this_ or _this?
by Lorenzo Caminiti 19 May '11

19 May '11

Hello all, Boost.Local uses a special name `this_` to access the object `this` bound from the enclosing scope. Shall this name be `this_` or `_this` according to Boost practices? struct c { void g(int x) { ... } void f() { void BOOST_LOCAL_FUNCTION_PARAMS( (int x) (bind this) ) { this_->g(x); // <<<<<<<<< Shall this be `_this->g(x);` instead? ... } BOOST_LOCAL_FUNCTIO_NAME(l) ... } ... }; In particular, some library uses _ postfix for statements like mpl::if_ (not mpl::_if) while other uses _ prefix for variables like phoenix::local_names::_f (not local_names::f_). Thanks a lot. -- Lorenzo

12 21

[boostcon][proto] Suggestion for LIAW session: fixed-point numbers
by Ravi 19 May '11

19 May '11

Hi, Are there any proto-based ideas for the library-in-a-week sessions? If not, would building a fixed-point data type be of interest? The domain is narrow enough that something useful can be accomplished in 4 sessions, but of large enough scope to present opportunities for exploring proto in depth. A fairly simple design follows representing a number: fixed_number<int width, int ulp, // 2^{ulp} is the smallest increment possible bool signed, template assigner<first, last, signed> > 'assigner' handles rounding/truncation/wrapping/etc when assigning another number (floating-point or fixed-point) to the current one. Internally, each fixed-point number would be represented by a boost::uint64_t or a boost::int64_t (limiting the maximum precision allowed). As an example, fixed_number<5, -3, false> would represent a data type that would go from 0 to 3.875 in steps of 0.125. Proto would be used for creating all arithmetic operations since the return type of a+b could be different from the type of either a or b. A bonus would involve getting the fixed-point data type to play well with std::complex (and, yes, I am aware that std::complex is not designed to work with anything other than double and float, and will require specialization in the std namespace). If there is sufficient interest, I could even provide a starting point with +,-,* implemented; / would take more time. The design above is intended as a starting point for discussion and I am most definitely not wedded to it. I am a tyro when it comes to proto, and hence would need someone with more proto expertise to guide the discussion. Regards, Ravi

8 24

Conversion/Enums/Opaque request for interest
by Vicente BOTET 16 May '11

16 May '11

Hi, Lastly I've been working on 3 Boost libraries proposals. * Boost.Conversion (https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/…) * Boost.Enums (https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html) * Boost.Opaque (https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.h…) Boost.Conversion manages with generic explicit conversion between unrelated types. The template function convert_to allows to convert a source type to a target type, using argument dependent lookup (ADL) to select a specialized convert_to function if available. If no specialized convert_to function is available, boost::conversion::convert_to is used. Boost.Enums intends to provide a partial solution to the scoped enums problem ensuring a portable solution compatible with compilers supporting natively scoped enums or not. In addition provides a framework to view enumerations as ordinal types so we can define some specific and efficient enum containers. Boost.Enums is composed of the following parts: * Scoped enums * Ordinal enums * Enum containers * MPL enums * String <-> Enum conversions Boost.Opaque intends to provide a library partial solution to "opaque typedefs". Boost.Opaque provides: * a generic mixin class hierarchy which can be specialized by the user to make new opaque classes. * a generic class hierarchy which can be instantiated by the user to make new opaque typedefs. * a meta-mixin concept that allows to compose in a easy way several aspects of a class in an orthogonal way. * a considerable number of meta-mixins that helps defining new types from an underlying type * Some helper macros that can reduce the declaration of a new opaque type to a single line, emulating the language-based approach. Boost.Opaque and Boost.Enums depend in some degree on Boost.Conversion. These are quite basic libraries that any of you could find useful (or not) and that are not associated to a complex domain, so any of you could have an opinion without spending too much time. Please follow the above links to have a better idea of the motivation of these libraries. Before continuing completing the design, docs and tests of these libraries I would like to know if there is an interest on these libraries and if you have any suggestion on how to improve them, you see something missing or that should be removed. This will help me a lot to concentrate my efforts on the library that reveals more interest. Any comment will really be appreciated. Thanks, Vicente

7 10

[multi_array] Is there interest for an [index_list] library?
by Pierre-Andre Noel 13 May '11

13 May '11

(This email has earlier been sent to the wrong list. Thanks to Steven Watanabe for pointing that out.) Dear all, I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray. For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m". The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented. If you are interested to know more, I strongly suggest you to take a look at the example file in sandbox/index_list/libs/index_list/examples.cpp . The library itself is in sandbox/index_list/boost and a readme file (with some details concerning concepts and "priorities") is in sandbox/index_list/libs/README . An automatically generated (Doxygen) documentation is located in sandbox/index_list/libs/index_list/doc/index.html . Sadly, there is no "real" documentation for now. Many thanks for your time. Sincerely, Pierre-André Noël

5 11

[local] Help for the Alternatives section
by Lorenzo Caminiti 12 May '11

12 May '11

Hello all, I am updating Boost.Local docs and I could use a some help in getting the Alternatives section right http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… . How can I program the following code (its local function and `factor` constant binding) using Boost.Phoenix, Boost.Lambda, and C++0x lambda functions? If you know, can you please reply with the actual code? #include <boost/local/function.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, // Variable `factor` bound as constant. bind& sum, const bind& factor) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; // Local function `add` passed as template parameter. std::for_each(v.begin(), v.end(), add); return 0; } Thank you very much! -- Lorenzo

14 82

[provocative] Whom did the SFC pay to list boost developers as a whole in "Current Member Projects"?
by Alexander Terekhov 08 May '11

08 May '11

http://sfconservancy.org/members/current/ (Current Member Projects) "Boost provides free peer-reviewed portable C++ source libraries. Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. Boost aims to establish existing practice and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report ( TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2." The context: (pacer) 03/23/2011 192 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from David Leichtman dated 3/23/2011 re: Requesting that the Reply and Kuhn Declaration be stricken, or in the alternative, that the Court consider Best Buy's responses to these new theories and arguments. ENDORSEMENT: Defendant's request is granted. The Court will consider Best Buy's response to the new issues raised in Plaintiffs' Reply, as set forth in this letter. So Ordered. (Signed by Judge Shira A. Scheindlin on 3/23/2011) (jpo) (Entered: 03/23/2011) 04/14/2011 193 OPINION AND ORDER. For the reasons in this opinion and order, plaintiffs' motion to join WD is denied. The Clerk of the Court is directed to close this motion (Docket No. 133). (Signed by Judge Shira A. Scheindlin on 4/14/2011) (rjm) (Entered: 04/15/2011) 04/26/2011 194 ENDORSED LETTER addressed to Judge Shira A. Scheindlin from Emmett J. McMahon, dated 4/25/2011, re: Counsel for the defendant Best Buy Co., writes to request a pre-motion conference regarding a motion to strike Plaintiffs' claim for "actual damages and any additional profits of [Best Buy] incurred as the result of infringement." ENDORSEMENT: Request granted. A premotion conference will be held on May 6 at 2:30. So Ordered. (Pre-Motion Conference set for 5/6/2011 at 02:30 PM before Judge Shira A. Scheindlin) (Signed by Judge Shira A. Scheindlin on 4/25/2011) (lnl) (Entered: 04/26/2011) (details) http://www.terekhov.de/192.pdf http://www.terekhov.de/194.pdf Suggestion: Please remove boost from http://sfconservancy.org/members TIA. regards, alexander.

9 22

[PBGL] Distributed adyacency_list memory allocation
by Cosimo Calabrese 06 May '11

06 May '11

Hi to all, I'm working on WinXP, VS2010, boost 1.46.1. I've writed this short program: //---------------------------------- #include <boost/graph/use_mpi.hpp> #include <boost/graph/distributed/mpi_process_group.hpp> #include <boost/graph/distributed/adjacency_list.hpp> using boost::graph::distributed::mpi_process_group; typedef boost::property<boost::vertex_distance_t, long, boost::property<boost::vertex_name_t, std::string > > vertex_prop; typedef boost::property<boost::edge_weight_t, long > edge_prop; typedef boost::adjacency_list< boost::vecS, boost::distributedS<mpi_process_group, boost::vecS>, boost::directedS, vertex_prop, edge_prop > Graph; typedef boost::graph_traits<Graph>::edge_descriptor EdgeDescriptor; typedef boost::graph_traits<Graph>::vertex_descriptor VertexDescriptor; int main(int argc, char* argv[]) { boost::mpi::environment env(argc,argv); Graph g( 10 ); return 0; } //---------------------------------- When I launch it, every process allocates about 1 GB of memory. Why it allocates all that memory? Is it normal? Is there any tuning to the PBGL framework that I must made? I use it on a 2-core machine, and the command that I use is: mpiexec -n 2 .\test.exe I've tried with openMPI 1.4.3 and Microsoft HPC Pack 2008, but it seems irrilevant. Thanks in advance, Cosimo Calabrese.

2 1

[xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

10 17

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

[Review] Boost.Convert library, new subversion URL
by Edward Diener 03 May '11

03 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts today, April 23, and is scheduled to last through May 2. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* Normally you can find Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… However because the boostpro web site is having problems and will likely be down for the weekend, I have put the library into the Boost sandbox temporarily, since the Boost sandbox is up. So you can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. This is exactly the same as the vault with the files unzipped. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

12 19

Checking interest: reflectable types
by Noah Roberts 03 May '11

03 May '11

In my work I've developed a sort of reflection library for C++. There are still many problems to solve before it could near real reflection but I don't believe they are insoluble. It works much like fusion maps except that you can extend them through inheritance. In fact, my current implementation uses fusion to do its thing and with some minor changes to fusion::map it could provide the base. There is a boost.reflection proposal out there that is meant to work with boost.extension. This one is a bit different in that you're not additionally defining data; instead you declare your reflection as you declare your reflectable type through the instantiation of and inheritance from template metafunctions. It's primarily a static/compile-time kind of reflection but can be extended into runtime simply by making your field types a little smarter. Fields describe the data and provide access identifiers. Since they are general types that simply have to have an internal typedef you can attach whatever information is useful. We've done such things as attach valid value ranges, labels, etc... I currently use it do auto-construct property trees for user editing. I plan to use it for scripting/extension. I've had a look at boost.python and it looks like it would be possible, without too much difficulty, to automate python exposure of these types. A coworker with 0 experience in metaprogramming found it fairly easy to feed the types into a structure meant for a report design and printing library. This isn't a promise to actually do anything. I'm just gauging how much, if any interest there is to decide if I want to go to the trouble of hobby developing a publicly available and usable version.

4 11

[website] Suggestions
by Stephan T. Lavavej 02 May '11

02 May '11

It would be wonderful if: 1. On the main page, there was a direct link to the current version's documentation. Currently, you have to click Documentation, then "1.46.1 - Current Release". (Actually, I just noticed that a direct link does exist - Libraries under Welcome. I was hoping for a big blue button saying GET DOCS.) 2. There was a terse list of links to each library's documentation. The master list currently mentions 6 additional pieces of information for each library (Summary, Authors, First Release, Standard, Build, and Categories). That's nice, but it makes finding library X's documentation significantly more tedious than it has to be (I count 105 libraries in 1.46.1 - that's a lot of scrolling!). I suspect that even beginners don't need information other than the Summary 99% of the time. The current info should be preserved somewhere, but clicking on a release's documentation should bring up a terse list first. http://cid-e66e02dc83efb165.office.live.com/self.aspx/docs/boost.html is a horribly ugly preview of what I'm suggesting (because some libraries have long summaries, I've arbitrarily truncated them; ideally, each library would have a single-line summary at reasonable browser widths). 3. http://boost.org didn't redirect to http://www.boost.org . Even better, if the reverse happened ("Class B", according to http://no-www.org/faq.php ). Clearly, this is the most important issue of all. :-> Stephan T. Lavavej Visual C++ Libraries Developer

5 4

[locale] Review results for Boost.Locale library
by Chad Nelson 02 May '11

02 May '11

The formal review of Artyom Beilis' Boost.Locale library, originally scheduled to run from April 7th through the 16th and extended through the 22nd, is now finished. Fifteen people cast votes on it, ten for acceptance and five against. Though not overwhelming, the two-to-one majority clearly indicates the consensus of the list. As such: The Boost.Locale library IS ACCEPTED into Boost. The details follow, starting with the voters in favor, in the order their reviews were received: * John Bytheway * Steven Watanabe * Sebastian Redl * Fabio Fracassi ("possibly conditional") * Noah Roberts * Steve Bush * Volker Lukas * Paul A. Bristow * Matus Chochlik * Gevorg Voskanyan Those opposed: * Ryou Ezoe * Phil Endecott (but "borderline") * Edward Diener * Mathias Gaunard * Vincente BOTET ("count my vote as 1/2 or 1/4 vote") There was also an early off-list review from Darren Cook which did not include a vote, only listing issues. There was a great deal of discussion around the library, and a number of issues detailed. The major ones (and some less major ones that were repeated by several reviewers) are summarized below, along with the initials of the reviewer(s) who brought them up and Artyom's responses. Note that although I followed the discussions closely, these are only the issues brought up in the formal reviews themselves. * Issue: date_time interface uses enums for periods, which is error prone and inconsistent with other date/time libraries. (JB) * Response: Will be addressed. * Issue: Reference documentation needs more detail or some things not clear; some terms used in the documentation are not defined or are defined too briefly; can't find headers that items are defined in from the documentation. (JB, SW, FF, PE, ED, MC) * Response: Will be addressed. * Issue: There are no prev/next links in the documentation, or tutorial can't easily be navigated. (DC, JB, SR, FF, MC) * Response: Looking into it. * Issue: Few examples include output. (JB) * Response: Will be addressed. * Issue: No examples in Asian languages; the library may have design flaws that are not apparent without them. (DC) * Response: [Artyom has indicated to me (privately) that he's adding such examples. -- CN] * Issue: The translation system requires narrow-character tags, making it English-centric. (RE, ED) * Response: The library implements the most popular and most widely used message-catalog format. It is not perfect, but it is the best system currently available. There may be a work-around if you really must use wide-character languages under Windows. * Issue: Support for wchar_t/UTF-16 is unclear. (RE, ED) * Response: Wide characters are fully supported. * Issue: Doesn't support Win32 API as a backend. (RE) * Response: Misunderstanding, Win32 API backend is fully supported. * Issue: boost::locale::format is not compatible with boost::format. (FF, NR) * Response: boost::format is too limited for use in localization, and throws on any error, which means that a translator error could crash the program. * Issue: boost::locale::date_time is not compatible with boost::date_time. (FF) * Response: An unavoidable consequence of the differences between them, which are necessary due to support for locale independence and non-Gregorian calendars. * Issue: Boundary analysis is only available when using ICU. (FF) * Response: At present, only the ICU backend supports proper boundary analysis. * Issue: Little documentation on the toolchain needed to extract strings and translate them, or the versions required. (FF, NR) * Response: Will be addressed. * Issue: Concerns about relying on GPL/LGPL-licensed tools, or their availability on all platforms, or recommendations to write a Boost version of these tools. (NR) * Response: Reimplementing these is non-trivial and unnecessary; the licensing for these tools does not affect the programs developed with them. All are available for all platforms; will add explicit instructions for getting the latest versions for Windows. * Issue: Use of strings instead of symbols for language and encoding makes run-time errors that could be compile-time errors. The most common ones should be symbols. (PE) * Response: There are dozens of character encodings, and even more locales, and no way to determine which ones are the most common. Not all encodings are supported by all backends or OS configurations. Names ignore case and non-alphanumeric characters, which should minimize errors that could be generated from them. utf_to_utf transcoding will be added. * Issue: Error handling (in conversions) is very basic. (PE) * Response: An unavoidable limitation of the backends. * Issue: Code could use more commenting. (PE, VL) * Response: Noted, will be addressed in the future. * Issue: Some documentation phrasing is confusing, or could use a native English speaker's input. (SR, VL) * Response: Will be addressed as discovered. * Issue: There are no lists of valid language, country, encoding, or variant strings. (ED) * Response: Listed in standards ISO-639 and ISO-3166, which are referenced in the library's documentation. These standards are updated occasionally, and should be referred to directly for the latest information. * Issue: Only works on contiguous, entirely-in-memory strings. (MG) * Response: All current backends require this, and it satisfies the vast majority of use-cases. * Issue: Boundary analysis goes through the entire string and returns a vector of positions. (MG) * Response: Not perfect, but given the limitations of the existing backends, it is reasonable. * Issue: The library's interface is not generic enough, or independent enough of the libraries that it wraps. (VB) * Response: The interface is similar to that of every other i18n library, and should make as few assumptions as possible. It should not be changed. * Issue: The date-time code should be merged into Boost.DateTime. (VB) * Response: Date-time code is locale-dependent by its nature, and is more natural in Boost.Locale. Updating Boost.DateTime to do everything that Boost.Locale's library does would require a lot of work, and in all the time it has existed, only the Gregorian calendar has been implemented. There are Boost libraries that overlap others, so this is not a novelty. -- Chad Nelson Oak Circle Software, Inc. * * *

18 71

[BOOST CORE C++ Feature] The super or base keyword for C++
by Max Hölzer 02 May '11

02 May '11

Hello, i was wondering if it makes sens to add the well known super or base keyword to the C++ language in a generic way. Here I have a simple example on how it would make inherited base or super class overloaded function calls easier. Example 1: class A { public: virtual void print() { std::cout << "A" << std::endl; } }; class B : public A { public: virtual void print() { std::cout << "B" << std::endl; std::cout << "super call "; A::print(); } }; class C : public B { public: virtual void print() { std::cout << "C" << std::endl; std::cout << "super call "; B::print(); } }; int main(int argc, char* argv[]) { A a; B b; C c; a.print(); // Prints A b.print(); // Prints B and super call A c.print(); // Prints C and super call B super call A return 0; } Adding a template class superable would avoid one to write the explicit base or super class name. Example 2: namespace boost { template<typename T> class superable : public T { public: typedef T super; // C++ and java style typedef T base; // C# style }; } class A { public: virtual void print() { std::cout << "A" << std::endl; } }; class B : boost::superable<A> { public: virtual void print() { std::cout << "B" << std::endl; std::cout << "super call "; super::print(); // C++ and java style call } }; class C : boost::superable<B> { public: virtual void print() { std::cout << "C" << std::endl; std::cout << "super call "; base::print(); // C# style call } }; int main(int argc, char* argv[]) { A a; B b; C c; a.print(); // Prints A b.print(); // Prints B and super call A c.print(); // Prints C and super call B super call A return 0; } If somebody could add this to the core boost library, that would be great. Sincerely yours, Max

2 1

[filesystem] Decomposition of filenames beginning with period?
by Beman Dawes 01 May '11

01 May '11

Boost.Filesystem class path views filenames as being made up of a stem and an extension. My Windows Users directory includes files ".gitconfig" and ".netrc". The current class path implementation views these as having extensions of ".gitconfig" and ".netrc", respectively, and empty stems. To me, that's a bit counter intuitive. I guess I view filenames as always having stems, but extensions being optional. But I don't view that as a strong enough argument to change anything. Does anyone have a stronger argument than intuition for changing or retaining the current behavior? --Beman

13 20

Re : [Block Pointer] make_block
by Pierre Morcello 01 May '11

01 May '11

Hi Phil, >>> Phil Bouchard <philippe(a)fornux.com> wrote : >>> We can see it in action >>> in the following example: >>> https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… A detail : I think you could improve your sample by replacing __FUNCTION__ by BOOST_CURRENT_FUNCTION (which is more portable), or by writing directly the name of the function. >>>Is it time for a review? I looked for automated tests in the sandbox directory (not examples) and I did not find any. Instead of doing "cout", you could use a class like that : class ForTests { static int counter; // incremented at each construction int id; // id = current value of the counter in the constructor static std::vector<int> destructionOrder; }; Each destruction pushes the id in the destructionOrder vector. Then at the end of the program you just need to compare the content of destructionOrder with what you should expect (and return 1 or 0). Also the same might be done for construction. Good job BTW, and good luck for the review, Pierre Morcello

2 4