September 2010 - 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

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

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

[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

[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

[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

[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

[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

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

accurate sum accumulator (kahan)
by Gaetano Mendola 27 Apr '11

27 Apr '11

Hi all, I had to implement in terms of boost accumulators the Kahan summation algorithm. I will paste at the end of this message the accumulator, the feature and the extractor source code. This accumulator reduces the numerical error obtained with standard sequential sum, as example the sum of 1e6f elements equal to 1e-6f should give 1.0f, this is the results obtained with sum and sum_kahan: tag::sum: 1.009038925 tag::sum_kahan: 1.000000000 I'm not sure if that sum_kahan is worth to be inserted in the accumulators provided with boost, I'm not an expert of boost:accumulators (I just followed the guide to make this new accumulator) so not sure if you prefer to have a fast_sum and an accurate_sum instead of sum and sum_kahan. Regards Gaetano Mendola // File kahan_sum.hpp #ifndef KAHAN_SUM #define KAHAN_SUM #include <boost/accumulators/framework/accumulator_base.hpp> #include <boost/accumulators/framework/parameters/sample.hpp> #include <boost/numeric/conversion/cast.hpp> namespace boost { namespace accumulators { namespace impl { template<typename Sample> struct sum_kahan_accumulator : accumulator_base { typedef Sample result_type; template<typename Args> sum_kahan_accumulator(Args const & args) : sum(args[sample | Sample()]), compensation(boost::numeric_cast<Sample>(0.0)) { } template<typename Args> void operator ()(Args const & args) { const Sample myTemp1 = args[sample] - this->compensation; const Sample myTemp2 = this->sum + myTemp1; this->compensation = (myTemp2 - this->sum) - myTemp1; this->sum = myTemp2; } result_type result(dont_care) const { return this->sum; } private: Sample sum; Sample compensation; }; }}} namespace boost { namespace accumulators { namespace tag { struct sum_kahan : depends_on< > { typedef impl::sum_kahan_accumulator< mpl::_1 > impl; }; }}} namespace boost { namespace accumulators { namespace extract { extractor< tag::sum_kahan > const sum_kahan = {}; } using extract::sum_kahan; }} #endif

21 68

D-style scope guards?
by Martin Christiansson 07 Mar '11

07 Mar '11

Hi, I have used the good old scopeguard in the past and recently done some experiments with the Boost.ScopeExit library. Still I feel that the clean scope statements in D is missing. It will not be possible to do an equally clean solution without having the same features in the language itself, but I could reach as far as this example that reuses the ScopeExit library: void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_END } The GUARDED_SCOPE_BEGIN macro declares one boolean guard to handle return from several levels of nested scopes and one boolean to guard the current scope from exceptions (will be shadowed in nested scopes). GUARDED_SCOPE_END will set the exception_thrown guard to false before that variable is used by the GUARDED_SCOPE_*() destructors. The latter is actually reused ScopeExit code with an added wrapper with a single if-statement. GUARDED_SCOPE_EXIT() will allways run on scope exit. GUARDED_SCOPE_SUCCESS() will only run if the function is exited with wrapper for return keyword (GUARDED_SCOPE_RETURN). The wrapper must be used since it updates the hidden guard variables. Using plain "return" will behave as if exception was thrown. GUARDED_SCOPE_FAILURE() will run when exception is thrown. There is also a separate GUARDED_SCOPE_NESTED_BEGIN that is supposed to be used for all nested scopes. A reference is kept to the return_called variable in the top-level-scope (variable declared by GUARDED_SCOPE_BEGIN). The biggest issue here is that any extra closing curly bracket inserted between GUARDED_SCOPE_*-definitions and GUARDED_SCOPE_END will cause destructors to run before update of guard variable. Could happen if someone thinks it "looks better" without understanding how stuff works. That kind of error will behave as if exception was thrown. Is this something to investigate further? Messy or potentially useful? Suggestions for improvements? I've appended the contents of my small test program at the end of this email. Can be tested by inserting GUARDED_SCOPE_RETURN() and "throw exception();". Regards, /Martin ----------- #include <iostream> #include <exception> #include <boost/scope_exit.hpp> using namespace std; #define GUARDED_SCOPE_BEGIN bool return_called = false; { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_NESTED_BEGIN { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_END exception_thrown = false; (void) return_called_ref; } #define GUARDED_SCOPE_RETURN(rc) { return_called_ref = true; return rc; } #define GUARDED_SCOPE_EXIT(Seq) BOOST_SCOPE_EXIT(Seq) #define GUARDED_SCOPE_EXIT_END BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_SUCCESS(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(return_called_ref || !exception_thrown) #define GUARDED_SCOPE_SUCCESS_END } BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_FAILURE(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(!return_called_ref && exception_thrown) #define GUARDED_SCOPE_FAILURE_END } BOOST_SCOPE_EXIT_END void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END do { GUARDED_SCOPE_NESTED_BEGIN GUARDED_SCOPE_FAILURE() { cout << "Inner scope: Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_SUCCESS() { cout << "Inner scope: No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_END } while(0); GUARDED_SCOPE_END } int main() { try { foo(); } catch(exception& e) { cout << "main(): Caught exception: " << e.what() << endl; return -1; } cout << "main(): No Errors occurred!" << endl; return 0; }

9 16

[scope_exit] MSVC error C2355: 'this' : can only be referenced inside non-static member functions
by Lorenzo Caminiti 01 Mar '11

01 Mar '11

Hello all, I am trying to use Boost.ScopeExit parameter binding mechanism to implement Boost.LocalFunction. To do so, I need to use some internal ScopeExit code to detect the type of `this` and bind its value to the local function declaration. The following code works on GCC but not on MSVC... This appears to be a MSVC 2008 bug: http://connect.microsoft.com/VisualStudio/feedback/details/331418/erroneous… 1) Can anyone please try this code on MSVC versions later than 2008 to see if it was fixed? 2) Do you know of a workaround for this problem? // File: lf03.cpp #include <boost/scope_exit.hpp> struct c { void f() { typedef void (*this_t)(int this_ ); #if defined(BOOST_MSVC) // for MSVC typedef boost::type_of::msvc_typeid_wrapper< sizeof(*boost::type_of::encode_start( #else // for GCC typedef __typeof__( boost::type_of::ensure_obj( #endif boost::scope_exit::aux::wrap( boost::scope_exit::aux::deref( this, (this_t)0 ) ) ) #if defined(BOOST_MSVC) // for MSVC )>::type #else // for GCC ) #endif this_w; } }; int main() { c cc; cc.f(); return 0; } I get this error on MSVC 2008 but the code compiles just fine on GCC: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. lf03.cpp using native typeof lf03.cpp(17) : error C2355: 'this' : can only be referenced inside non-static member functions lf03.cpp(22) : error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list C:\Program Files\boost\boost_1_42\boost/typeof/msvc/typeof_impl.hpp(212) : see declaration of 'boost::type_of::msvc_typeid_wrapper' Thank you very much. -- Lorenzo

5 8

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[GIL] [patch] read multipage TIFF files
by Robert Pollak 29 Nov '10

29 Nov '10

Hello, the following patch (against the current trunk) allows to read any page of a multipage TIFF file, by optionally specifying the zero-based directory number. (The correct term for a TIFF page is "directory".) It adds a "dirnum" to the relevant functions, and uses the corresponding libtiff functionality. The "dirnum" default value is 0 for compatibility with present callers. Additionally, it defines the function tiff_get_directory_count to get the number of directories in the TIFF file. Please give me some feedback or consider applying the patch. This patch would close the corresponding feature request https://svn.boost.org/trac/boost/ticket/2373 . Credits go to Roland Richter, whose code the patch is based on. Best Regards, Robert Pollak Index: boost/gil/extension/io/tiff_io.hpp =================================================================== --- boost/gil/extension/io/tiff_io.hpp (revision 64065) +++ boost/gil/extension/io/tiff_io.hpp (working copy) @@ -122,9 +122,13 @@ protected: TIFF *_tp; public: - tiff_reader(const char* filename) { + tiff_reader(const char* filename,tdir_t dirnum=0) { io_error_if((_tp=TIFFOpen(filename,"r"))==NULL, "tiff_reader: fail to open file"); + if(dirnum>0) { + io_error_if(TIFFSetDirectory(_tp,dirnum)!=1, + "tiff_reader: fail to set directory"); + } } ~tiff_reader() { TIFFClose(_tp); } template <typename View> @@ -171,10 +175,10 @@ private: CC _cc; public: - tiff_reader_color_convert(const char* filename) : - tiff_reader(filename) {} - tiff_reader_color_convert(const char* filename,CC cc_in) : - tiff_reader(filename),_cc(cc_in) {} + tiff_reader_color_convert(const char* filename,tdir_t dirnum=0) : + tiff_reader(filename,dirnum) {} + tiff_reader_color_convert(const char* filename,CC cc_in,tdir_t dirnum=0) : + tiff_reader(filename,dirnum),_cc(cc_in) {} template <typename View> void apply(const View& view) { point2<std::ptrdiff_t> dims=get_dimensions(); @@ -336,18 +340,34 @@ }; /// \ingroup TIFF_IO +/// \brief Returns the number of directories in the TIFF file +inline int tiff_get_directory_count(const char* filename) { + TIFF *tif; + io_error_if((tif=TIFFOpen(filename,"r"))==NULL, + "tiff_get_count: fail to open file"); + + int dircount = 0; + do { + dircount++; + } while (TIFFReadDirectory(tif)); + + TIFFClose(tif); + return dircount; +} + +/// \ingroup TIFF_IO /// \brief Returns the width and height of the TIFF file at the specified location. /// Throws std::ios_base::failure if the location does not correspond to a valid TIFF file -inline point2<std::ptrdiff_t> tiff_read_dimensions(const char* filename) { - detail::tiff_reader m(filename); +inline point2<std::ptrdiff_t> tiff_read_dimensions(const char* filename,tdir_t dirnum=0) { + detail::tiff_reader m(filename,dirnum); return m.get_dimensions(); } /// \ingroup TIFF_IO /// \brief Returns the width and height of the TIFF file at the specified location. /// Throws std::ios_base::failure if the location does not correspond to a valid TIFF file -inline point2<std::ptrdiff_t> tiff_read_dimensions(const std::string& filename) { - return tiff_read_dimensions(filename.c_str()); +inline point2<std::ptrdiff_t> tiff_read_dimensions(const std::string& filename,tdir_t dirnum=0) { + return tiff_read_dimensions(filename.c_str(),dirnum); } /// \ingroup TIFF_IO @@ -356,17 +376,17 @@ /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its color space or channel depth are not /// compatible with the ones specified by View, or if its dimensions don't match the ones of the view. template <typename View> -inline void tiff_read_view(const char* filename,const View& view) { +inline void tiff_read_view(const char* filename,const View& view,tdir_t dirnum=0) { BOOST_STATIC_ASSERT(tiff_read_support<View>::is_supported); - detail::tiff_reader m(filename); + detail::tiff_reader m(filename,dirnum); m.apply(view); } /// \ingroup TIFF_IO /// \brief Loads the image specified by the given tiff image file name into the given view. template <typename View> -inline void tiff_read_view(const std::string& filename,const View& view) { - tiff_read_view(filename.c_str(),view); +inline void tiff_read_view(const std::string& filename,const View& view,tdir_t dirnum=0) { + tiff_read_view(filename.c_str(),view,dirnum); } /// \ingroup TIFF_IO @@ -375,25 +395,25 @@ /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its color space or channel depth are not /// compatible with the ones specified by Image template <typename Image> -void tiff_read_image(const char* filename,Image& im) { +void tiff_read_image(const char* filename,Image& im,tdir_t dirnum=0) { BOOST_STATIC_ASSERT(tiff_read_support<typename Image::view_t>::is_supported); - detail::tiff_reader m(filename); + detail::tiff_reader m(filename,dirnum); m.read_image(im); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, and loads the pixels into it. template <typename Image> -inline void tiff_read_image(const std::string& filename,Image& im) { - tiff_read_image(filename.c_str(),im); +inline void tiff_read_image(const std::string& filename,Image& im,tdir_t dirnum=0) { + tiff_read_image(filename.c_str(),im,dirnum); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its dimensions don't match the ones of the view. template <typename View,typename CC> -inline void tiff_read_and_convert_view(const char* filename,const View& view,CC cc) { - detail::tiff_reader_color_convert<CC> m(filename,cc); +inline void tiff_read_and_convert_view(const char* filename,const View& view,CC cc,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<CC> m(filename,cc,dirnum); m.apply(view); } @@ -401,31 +421,31 @@ /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. /// Throws std::ios_base::failure if the file is not a valid TIFF file, or if its dimensions don't match the ones of the view. template <typename View> -inline void tiff_read_and_convert_view(const char* filename,const View& view) { - detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter()); +inline void tiff_read_and_convert_view(const char* filename,const View& view,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter(),dirnum); m.apply(view); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. template <typename View,typename CC> -inline void tiff_read_and_convert_view(const std::string& filename,const View& view,CC cc) { - tiff_read_and_convert_view(filename.c_str(),view,cc); +inline void tiff_read_and_convert_view(const std::string& filename,const View& view,CC cc,tdir_t dirnum=0) { + tiff_read_and_convert_view(filename.c_str(),view,cc,dirnum); } /// \ingroup TIFF_IO /// \brief Loads and color-converts the image specified by the given tiff image file name into the given view. template <typename View> -inline void tiff_read_and_convert_view(const std::string& filename,const View& view) { - tiff_read_and_convert_view(filename.c_str(),view); +inline void tiff_read_and_convert_view(const std::string& filename,const View& view,tdir_t dirnum=0) { + tiff_read_and_convert_view(filename.c_str(),view,dirnum); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. /// Throws std::ios_base::failure if the file is not a valid TIFF file template <typename Image,typename CC> -void tiff_read_and_convert_image(const char* filename,Image& im,CC cc) { - detail::tiff_reader_color_convert<CC> m(filename,cc); +void tiff_read_and_convert_image(const char* filename,Image& im,CC cc,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<CC> m(filename,cc,dirnum); m.read_image(im); } @@ -433,23 +453,23 @@ /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. /// Throws std::ios_base::failure if the file is not a valid TIFF file template <typename Image> -void tiff_read_and_convert_image(const char* filename,Image& im) { - detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter()); +void tiff_read_and_convert_image(const char* filename,Image& im,tdir_t dirnum=0) { + detail::tiff_reader_color_convert<default_color_converter> m(filename,default_color_converter(),dirnum); m.read_image(im); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. template <typename Image,typename CC> -inline void tiff_read_and_convert_image(const std::string& filename,Image& im,CC cc) { - tiff_read_and_convert_image(filename.c_str(),im,cc); +inline void tiff_read_and_convert_image(const std::string& filename,Image& im,CC cc,tdir_t dirnum=0) { + tiff_read_and_convert_image(filename.c_str(),im,cc,dirnum); } /// \ingroup TIFF_IO /// \brief Allocates a new image whose dimensions are determined by the given tiff image file, loads and color-converts the pixels into it. template <typename Image> -inline void tiff_read_and_convert_image(const std::string& filename,Image& im) { - tiff_read_and_convert_image(filename.c_str(),im); +inline void tiff_read_and_convert_image(const std::string& filename,Image& im,tdir_t dirnum=0) { + tiff_read_and_convert_image(filename.c_str(),im,dirnum); } /// \ingroup TIFF_IO

2 7

[guidelines] why template errors suck
by Eric Niebler 26 Nov '10

26 Nov '10

This is borderline self-promotion and I fretted posting this. But we a community of advanced C++ library developers and I'd really like feedback about these issues. And they really do involve Boost library development. If we could reach agreement about these techniques, we might want to integrate them into Boost's coding guidelines. http://www.reddit.com/r/programming/comments/diddg/expressive_c_why_templat… Comments? -- Eric Niebler BoostPro Computing http://www.boostpro.com

24 136

LLVM license compatibility with BSL
by vicente.botet 19 Nov '10

19 Nov '10

Hi, I have found quite useful to adapt the test for llvm/libc++ ratio/chrono to test Boost.Ratio and Boost.Chrono. But Anthony has signaled me that maybe there is a compatibility problem with the license included in these files. //===----------------------------------------------------------------------===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===----------------------------------------------------------------------===// Is the LLVM License (http://llvm.org/docs/DeveloperPolicy.html#license) compatible with the Boost Software License? Can we include files with this comment on a Boost library? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

11 22

Interest in B-tree library for Boost?
by Beman Dawes 17 Nov '10

17 Nov '10

A Boost B-tree library would provide disk-based associative containers that scale all the way from really, really, small to really, really, large. B-trees perform well on hardware ranging from ancient floppy disk drives all the way up to humongous disk arrays. They are the technology behind most high-performance disk file systems and databases. If you don't know what a B-tree is, or think that "B-tree" is an abbreviation for "Binary tree", you might want to read the Wikipedia B-Tree article: http://en.wikipedia.org/wiki/B-tree. Knuth and other computer science texts also supply descriptions. See http://mysite.verizon.net/beman/btree/index.html for a more complete description of the proposed library. A preliminary implementation is available. Download http://mysite.verizon.net/beman/btree/btree-preview-1.zip, and unpack into a current Boost distribution. A few existing Jamfiles will be overwritten. The only compilers tested and working so far are VC++ 10 and GCC/MinGW 4.5. You can view the library online at http://github.com/Beman/Boost-Btree There is no detailed documentation yet, but if you know how to use std::map and other standard library associative containers, you already know most of what you need to know. Critical differences are documented in the Library Characteristics section of the index.html page referenced above. Initial timing tests have been very encouraging. The time test compares the btree_map implementation to std::map. As expected, a btree_map is many times slower than a std::map, given a cold operating system file cache and constraining the btree_map's caching to a minimum. But at the other extreme, when the O/S file cache is warm and the btree_map's cache is as large as the file, the btree_map is very similar in speed to std::map.The btree library's code is still very new, so timings and everything else may be subject to lots of revision. Any interest? --Beman

14 37

[gsoc] Boost.Process done
by Boris Schaeling 31 Oct '10

31 Oct '10

Here are the results of the Boost.Process project within this year's Google Summer of Code program: We have a complete library to manage system processes now! If you like to play around with the library download the ZIP file from <http://www.highscore.de/boost/gsoc2010/process.zip>. As it's a header-only library simply copy the files to your Boost folder. If you like to quickly check the documentation click on <http://www.highscore.de/boost/gsoc2010/>. The library is now complete and basically ready for a review. As there have been so many Boost.Process drafts before (after all the first version was created 2006) this library's version number is 0.4. This will somehow make it possible to refer to the various drafts if it's necessary. For now I would appreciate if the library's test cases are run on as many platforms as possible. After copying the files from the ZIP file to the Boost folder change to libs/process/test/ and run bjam - that's all! What has been changed? * All previous Boost.Process drafts including Ilya's 2008 version from the vault have been thoroughly studied to create a better version. From the multiple Boost.Process drafts which have been floating around since 2006 we took the best ideas and created a new unified version. * The design and implementation of the library have been simplified. The library's API is smaller, and the implementation is easier to understand. It should be possible to benefit from this library as quickly as possible. Even developers who have no experience in managing system processes should be able to do so easily. * There are no POSIX and Windows specific classes anymore (posix_context, posix_child, win32_context, win32_child etc. have been dropped). Instead of trying to support each and every feature platforms provide extension points have been defined. They enable library users to "link in" those platform specific features they are interested in. * For the first time there is full support for synchronous and asynchronous operations. While asynchronous operations are built on top of Boost.Asio synchronous operations can be utilized without that library. Developers don't need to include any Boost.Asio headers and don't need to learn about Boost.Asio if they don't need asynchronous operations. * Stream behaviors define if and how standard streams can be used by a child process. While the various stream behaviors were defined as an enumeration or a boost::variant in previous Boost.Process drafts they are now implemented as classes. This makes it possible for developers to create new stream behaviors. * The code to start child processes on POSIX platforms has been carefully adapted to support multi-threaded applications (it turned out that this code was wrong in all Boost.Process drafts so far). The documentation explains what you need to take care of if you want to create child processes in a multi-threaded application on POSIX platforms. * The documentation is new and has been shortened and simplified. There is a user guide which can be read in 10 minutes and introduces all the major features of the library. The documentation is now also based on Quickbook. * The test cases have been restructured to simplify them. They can now be run without patching Boost.Test and without setting a path to a helper executable in the source files - it's now all automatic. They are all passed successfully with MSVC 9 (2008) and g++ 4.2.1. What is currently missing? * Pipelines are not (yet) supported. If you have been using boost::process::launch_pipeline() there is nothing in this Boost.Process draft you can use instead. Depending on feedback this feature will be added again (there was simply no time yet to do this). We hope that after four years, two Google Summer of Code programs and countless drafts this new version will finally become the official Boost.Process library so many have been waiting for. Boris and Felipe

18 182

[constrained_value] Constrained Value review results
by Gordon Woodhull 29 Oct '10

29 Oct '10

Greetings, Substituting for Jeff Garland, I am pleased to present the results from the constrained_value review. The library is available at http://rk.dl.pl/f/constrained_value.zip The documentation is at http://rk.dl.pl/r/constrained_value Enjoy! Gordon 1. History The idea for a constrained value library goes back to at least 2004; Christopher Diggins proposed a mini-library at that time. In 2007 Joe Gottman suggested that Jeff Garland's constrained_value.hpp in date_time could be a top-level library. Concurrently, Robert Kawulak (henceforth RK) was working on his own library for the purpose, which he also started in 2004, unaware of the others. RK announced his library on November 11, 2007. Discussion continued into 2008; on June 19, RK announced his library was ready for review and it was put in the queue. The review began on December 1 2008 and continued until around December 15 (with some trailing discussion of the definition of invariant and why exceptions should not be used to check invariants). Gordon Woodhull reviewed the thread's 260 messages in the summer of 2010 and produced this report, dividing the issues raised between those where there was consensus on a change, those where no resolution was found, and those where the author and requesters (mostly) agreed that no change was needed. 2. Votes Eight people voted for acceptance of the library; there were no "no" votes. However, many people stated conditions on acceptance. Thanks to Chris (indy271828(a)sympatico.ca) Vicente Botet, Zach Laine, John Maddock, Thorsten Ottosen, Stjepan Rajko, Daryle Walker, and Gordon Woodhull for providing reviews. (In addition, Paul Bristow provided a review which looks like a yes but does not explicitly say so.) Thanks also to David Abrahams, Kim Barrett, Neal Becker, Paul Bristow, Edward Diener, Jeff Flinn, Joe Gottman, Mathias Guanard, Mika Heiskanen, Giovanni Pierro Deretta, Thomas Klimpel, Michael Marcin, OvermindDL1, John Phillips, raindog, Ravi (lists_ravi(a)lavabit.com) Johan Råde, Sebastian Redl, Peter Simons, Steven Watanabe, Utku Yaman, and Deane Yang for participating in a very active discussion. 3. Issues to be Addressed Floating point By far the most contentious issue in the review was the statement in the library documentation that floating point is not supported, and a few reviewers made fixing this a condition on acceptance. The issue is that the x87 math instructions (which are the default for 32-bit Intel compiles) utilize 80-bit registers which are then rounded down to 64 bits when a double value is written to memory. This can cause two values which were not equal to become equal later, with fairly unpredictable behavior depending on optimization and what code intervenes between calculating a value and comparing it. One solution is simply not to use the x87 math instructions by enabling the SSE2 math instructions instead. However, users may want the extra precision, and there is no way for a library to control this option. A few reviewers confused this issue with the frequent need for fuzzy comparison with epsilon; it was shown that the bug can still appear with epsilon-based comparisons. Jeff Garland points out that the Boost Numeric Interval library, http://www.boost.org/doc/libs/1_42_0/libs/numeric/interval/doc/interval.htm has also dealt with the x87 and NaN problems. It uses the round-trip-to-memory approach for x87. There is potential to create constraints for constrained_value using numeric::interval, and perhaps any other fixes for floating point belong in that library. Many solutions were proposed; after debate there were four left standing: * Force the new value to be written to memory Kim Barrett suggested the following function, noting that it should not force a memory write unless the value is in a register. inline double exact(double const& x) { return *const_cast<double const volatile*>(&x); } Gordon Woodhull has tested this against example provided by Thomas Klimpel in a message titled "floating point FUD" of January 23, 2010 (http://article.gmane.org/gmane.comp.lib.boost.devel/198817) and it does work. However, many people objected to this solution because of efficiency concerns: it requires a round-trip to memory (or at least to cache) for every assignment. * Only allow >= or <= for floating point types, and make sure the bounds are truncated 80- to 64-bit truncation can cause two values to become equal, but if one of them is already truncated, it cannot cause them to swap order. Since it is likely that the value will be changed much more frequently than the bound, it would suffice to apply truncation just to the bounds when they are set, e.g. with the exact() function above. However it does not seem that this solution can work if the bounds are dynamically calculated; the library supports bounds being returned by an inlined function. Johan Råde also suggested that it might be possible to implement < and > in terms of <= and >= and the std::nextafter function. * Force the processor to use 64-bit precision Johan Råde mentions a floating point control register which could be used in http://article.gmane.org/gmane.comp.lib.boost.devel/183760 There were also mentions of possible assembly code solutions, but none were provided and this was generally unpopular because it requires someone very knowledgeable to maintain it. John Phillips argued that reducing the precision will "lose significance faster than expected". * Another interesting solution was suggested by Stjepan Rajko: that the test might not be the same as the invariant. This is what testing with epsilon would guarantee. If the value passes the test it is guaranteed to satisfy the invariant, but only the test and not the invariant is in code. So some values might be rejected which are okay, but no bad value is accepted. RK felt that any floating point solution should be implemented separately from constrained_value, because he does not have the expertise. But he should be willing to document the scope of the problem better, including the SSE2 compiler flags that avoid the problem altogether. The first solution (truncation of the value) does not seem to require any changes to the library. Truncating the bounds might require some extra customization points. NaN Another problem with floating point is NaN, which compares false with everything. It might be okay if the bounds inclusion test always returned false. But the closed range is implemented as !(x < lower) && !(upper < x). Stjepan Rajko suggested that it should always be compare(lower, x) && compare(x, upper) where compare is < for excluded bounds and <= for included. It seems like this solution would work well for floats but not necessarily for user-defined types, which might only define operator<(). Substitutability with the underlying type A few people requested the ability to set a compiler flag in order to substitute the constrained_value with the underlying type. This is not exactly possible, unless the user is willing to explicitly extract the value using static_cast<T>(cv). The library does provide unconstrained<> which in most cases optimizes away, but the interface is not perfectly compatible with the underlying type. Constraints not copied when operators used The use of operators invokes implicit conversion to the underlying type, which means that in a statement like constrained_value x(10, constraint(...)), y(-x); y ends up with uninitialized constraints. Steven Watanabe suggested that the operators could be overloaded, but RK argued that the behavior would be application-specific: "For some applications returning a constrained value would be OK (but again there is the problem that the constraint may reject the modified value) while for others it's better to return the underlying type." Constrained strings Jeff Garland offered that he has written constrained_string classes for allowing values from a set of strings, and for validation against a regex. RK said he might add a constraint type which validates against set<T>, and affirmed that a regex validator would be nice too. Bounding on only one side Utku Yaman and others requested a way to bound integers on only one side. RK noted that you could set one of the bounds to the maximum or minimum possible integer, but this is verbose. Default arguments would be confusing, and RK thought maybe he would supply lower_saturating_int and upper_saturating_int. Note that there is a more general problem, especially if floating point is allowed. (Also consider e.g. fixed point, rational.) Recoverable error policy - error policy changing the value There were some objections to the error policy taking three parameters - the new value, the member value, and the constraint. Does it really need to change the member value? Yes, RK explained, because this is a recoverable error policy. Vicente Botet asked that the concept be called RecoverableErrorPolicy. Serialization Neal Becker requested support for serialization. RK agreed this is worth looking into and pointed out a couple of difficulties. One, a way to not serialize empty (or static) policies is needed. Two, non-default constructible types such as odd_number might require use of load_construct_data() / save_construct_data() instead of serialize(). Rename bounded_int This class name does not convey the fact that the bounds are specified at compile time. Neal Becker suggested compile_time_bounded or static_bounded. RK says the first name is too long, and the second might imply that the bounds are static members (which is also a legitimate use case). sizeof static constrained types == sizeof underlying type Assuming that the empty base class optimization is being applied correctly, which seems to be the case, if the constraint and the error policy are empty, the size of the constrained value should be the same as the size of the underlying type. However, this was not the case on all platforms, at least at the time of the review. The library should include sizeof tests in its test suite so that potential users know if there is unexpected overhead on their platform. Specify static bounds as open<0>, closed<100> for bounded<> and bounded_int<> Requested by Vicente Botet. If possible, this would reduce the number of template arguments and would be more clear than the current bounds exclusion boolean parameters. Some default constructions may throw If zero does not satisfy the constraint, then a default-constructed constrained value may throw an exception. (There are other examples, like non-empty string.) Many reviewers requested a means to provide a default value, which can be done by wrapping the underlying type, but RK felt a default value class was out of scope. At the very least this should be documented and probably an example given. Examples Vicente Botet requested: * an example showing how to create a constrained class by derivation and/or containment which adds/removes methods from the constrained value interface * a date example where changing the month affects the bounds for the day. * example of static bounding on only one side * example of bounds calculated at runtime by a function ("runtime dynamic bounding") Others: * example of constraints with static members - allows shared mutable constraints with no overhead per instance. Tests! Many reviewers were offended that there were no tests in the review version. RK said he would write some. Documentation * document the concepts and provide tests with concept archetypes. It turns out that these are documented briefly in the doxygen documentation of constrained<> at http://tinyurl.com/39v8o6r, but many reviewers were expecting a section in the main document. * Stjepan Rajko pointed out that the constraint can't depend on mutable members of the underlying type, and wondered if there were other implicit requirements, such as the way copy construction or swapping works. He requested these be documented. * Gordon Woodhull suggests a section on space efficiency and which configurations should allow the size to be optimized to the same size as the underlying type, and spelling out in each example what the cost in space is. * Thorsten Ottosen requested benchmarks of non-checking unconstrained against just using the underlying type. RK offered that he had looked at the generated assembly on some platforms. 4. Unresolved debates Error policy is allowed to change constraint Vicente Botet objected to the "bounded object with memory" example, which tracks extremal values by setting the bounds to include any new values. And Thorsten Ottosen objected to the inefficiency of change_constraint using construct-and-swap: it's not necessary to swap the constraint unless it might be changed by the error policy. This seems to be an example of a monitored value, which RK does not want to write himself, so does it belong in this library? RK argued that it does no harm, so why not allow? Double-checking and disabling assertions A number of people were concerned with the inefficiency of first checking the constraint, and then also asserting that the constraint is satisfied after the assignment has happened or the error handler has been called. But RK argued that it was necessary to check the invariant to make sure that the assignment operator and the error handler are doing their job. Besides, it is possible to disable the asserts with either BOOST_DISABLE_ASSERTS or NDEBUG. There was some discussion of adding an assert policy or a specific macro (with no clear conclusion). Disabling checks There is unconstrained, which offers a way to replace one constrained type with an unconstrained type, but Chris (indy271828(a)sympatico.ca) requested a way to disable all checks with a single macro. It might not be good enough to use a single error policy and select between throwing version and an assign-anyway version, because the compiler won't always optimize this away. More members, less free functions Thorsten Ottosen thought that any functions which change the state of the object should be members, not free functions. In particular, change_constraint might be less efficient than possible because the construct-and-swap requires copying the constraint. This does seem to be partly an ideological debate. Specific classes instead of a general super-template Vicente Botet requested that the interface use specific classes instead of typedefs: currently many of the specializations, like bounded<>, are metafunctions that apply some parameters to the generic constrained_value and return a new type, and then the specific operations are free functions. Instead these could be full classes with member functions. RK argued that this would result in unnecessary duplication. Way to disable the arithmetic operators Vicente Botet requested a solution in code or in documentation for users who don't want the arithmetic operators defined. 5. Ideas not requiring any action Monitored Values Stjepan Rajko suggested (and Vicente Botet expanded on the idea) that constrained value is really a special case of a more general "monitored value" class, in which a monitor policy decides how to handle any assignment. So constrained value would be a monitored value where the monitor policy checks a constraint, possibly calls an error policy, and then asserts the constraint. RK did not want to implement this and resisted suggestions to allow the assertion to be disabled in order to allow this use case, because without an invariant, it's not really a constrained value. But he suggested that monitored value could be implemented by someone else and constrained value could be re-implemented in terms of it. "Monitored value" might not be the best name for the general class, because "monitor" suggests something passive, rather than something which controls the outcome of assignment. A way to run a function on a constrained value Stjepan Rajko requested a way to make a copy of the value, run a function on it, and then reassign back, preferring the syntax call_using_copy(f, x) to x = f(x). But he notes this could be written as a free function. Multiple ranges Edward Diener requested a way to supply multiple ranges, but agreed that the syntax would be unattractive. Assertions instead of exceptions Thorsten Ottosen requested a way to have only assertions and no exceptions, and RK pointed out that this can be done either by specifying an error policy which asserts, or even with an assign-anyway error policy, which leaves the invariant checking in place. Exclude bounds parameter Vicente Botet found it confusing that bounded_int takes false to mean include bounds and true to mean exclude the bounds. RK explained that this is an artifact of the way within_bounds is templated on a type which can be either a compile-time or a runtime value, e.g. mpl::true_ or bool; this technique means there can be no default argument to the constructor and thus the more common option must be false, the default constructed value of bool. Constraints between several variables. Vicente Botet suggested a sort of constrained_tuple where if you set one field it would affect the constraints for the other fields. E.g. a date object where the month and year would affect the valid range for the day. With the current interface you'd have to set the whole date at once. Constrained values as sets of instances Exploring the problem domain, Vicente Botet suggested another possible implementation of constrained value where the constrained value type keeps track of which instances satisfy the constraint. This class would offer a split operation which moves any instances which satisfy a more specific constraint into the new set. Changing the constraint would similarly return the set of instances which are now excluded.

12 49

Thoughts for a GUI (Primitives) Library
by Gwenio 20 Oct '10

20 Oct '10

As it stands, neither Boost nor C++ has any support for GUI applications. Therefore I am suggesting a library that provides the bare minimum required to create a GUI application. My thoughts on what this library would contain are as follows: - Types for controls (contexts bound to the extent of their parent) and windows (contexts that remain separate from their parents). - An event handler class that is passed when controls and windows are created that contains all information needed to handle events for the new context. - Functions for generating events (if applicable) and (a) function(s) to initiate message handling (unless the event loop is run in its own thread like in Java). - Functions to access and manipulate the data of the contexts (size, position, z-order, ect). - Miscellaneous other types used for support (such as for screen positions). - A way to retrieve the native concept of a window/control. As you can see, there are no controls/widgets/ect defined, either from the library or using the native versions. Such things can be added later, if people can ever agree on how they should be implemented. It needs a lot of refining, but I believe this covers the *minimum* support that is needed for a GUI.

22 78

Re: [boost] [exception] ostringstream like
by Fabien Castan 19 Oct '10

19 Oct '10

> No, I mean that if you do advanced string manipulation in the exception > itself, you may screw up, adn cause a bad_alloc beign thrown and masking > your own exception. Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error. > Just make your own, informative exception type deriving from logic_error. The problem is not really the kind of exception, but an easy way to create message with boost exception tag system. The idea is to create a new base class for tags allowing to use an ostringstream with tags, which is not possible. typedef ::boost::error_info<struct tag_message,std::ostringstream> message; This little class only remap operator+ call to operator<< on an internal ostringstream. typedef ::boost::error_info<struct tag_message,::boost::error_info_sstream> message; I use it in my code, but I ask here if we can hope to see such things in boost exception. I would prefer to use a standard boost object rather than a custom class.

4 3

New Boostcon sessions uploaded
by Marshall Clow 14 Oct '10

14 Oct '10

Michael Caisse: Using Spirit V2: Qi and Karma http://blip.tv/dashboard/episode/4162161 Stephan T. Lavavej: Data Structure Visualizers in Visual Studio 2010 http://blip.tv/dashboard/episode/4162044 Matt Calabrese, Zachary Laine: Instantiations Must Go! http://blip.tv/dashboard/episode/4161957 Jeremy Siek: Generic Programming And the Boost Graph Library http://blip.tv/dashboard/episode/4161923 More to come (I'm shooting for one session every other day)..... -- Marshall

13 24

[Review] Formal Review: Boost.Ratio
by Anthony Williams 06 Oct '10

06 Oct '10

Hi everyone, The review of Vicente Botet' Ratio library starts October 2nd and lasts until October 11th, 2010, unless an extension occurs. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

5 6

[fusion] [intro] ADAPT_STRUCT extensions
by Stefan Strasser 04 Oct '10

04 Oct '10

Hi, in the discussion about the library I called "Intro" at the time it has been suggested to use BOOST_FUSION_ADAPT_STRUCT of Boost.Fusion for data member access. based on that I'd like to propose two extensions to ADAPT_STRUCT, which I think are useful beyond my use case: 1) ADAPT_STRUCT can adapt public data members only. with the modifications I uploaded here: http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ all data members can be adapted. for example: class A{ private: friend class fusion::access; int a; }; BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) 2) adaption of a class including its base class members. for example: struct A{ int a; }; struct B{ int b; }; struct C : A,B{ int c; } BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) BOOST_FUSION_ADAPT_STRUCT(B,(int,b) ) BOOST_FUSION_ADAPT_DERIVED( C, (A)(B), (int,c) ) an instance of C is now a fusion sequence of size 3. http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ad… private inheritance is supported as above, virtual inheritance is not. I'm not sure if virtual inheritance can be supported.

8 30

Boost.SQL?
by Roland Bock 04 Oct '10

04 Oct '10

Hi, currently I am working on a set of header files which are supposed to make the life of C++ developers easier when in comes to interacting with databases (based on SQL). Goals are: * Stay close to SQL syntax * Do as much type checking as possible * prevent oversights and typical security holes, e.g. by forgetting to escape strings The basic idea is, that given a table definition, it should be possible to * offer a lot of checks at compile time for building a query * make it hard to misinterpret the results Until now, I have been concentrating on table definitions and select statements. Here's a very simplistic example, assuming a table definition "my_table" and a database connection "db": // ------------------------------------------------------------------------- using boost; typedef my_table<> t; typedef sql::select_record<t> record; std::string name("Peter"); ... std::vector<record> records = db.select<record>( sql::where(t::id() > 1000 && t::first_name() == name), sql::order_by(t::priority()(sql::desc)), sql::limit(17)); // the values can be accessed by their name // and are of the correct type, e.g. records.front().first_name_; // is a string records.front().middle_name_; // optional<string> because the table definition says that it can be NULL // In case of a select from more than one table, the values can also be accessed like this records.front().my_table_.first_name; // ------------------------------------------------------------------------- I wonder if there would be interest for such a library in boost.

17 44

[thread] Memory leak in Boost.Thread?
by Denis Arnaud 03 Oct '10

03 Oct '10

Hello, a Fedora user has reported a potential memory leak in Boost.Thread (see https://bugzilla.redhat.com/show_bug.cgi?id=627875 for details), detected with Valgrind in (at least) versions 1.41.0 and 1.44.0. Following is a code snippet allowing to reproduce the issue: ==================================== #include <boost/thread.hpp> void someWork() { double a; for(int i= 0;i< 1000;i++) { a+=log((double)i); } } int main() { for(int i = 0; i< 10; ++i) { boost::thread_group pool; for(int j = 0; j< 100; ++j) { pool.create_thread(someWork); } pool.join_all(); } } ==================================== Then, following is Valgrind's report: ==================================== ==6442== Memcheck, a memory error detector ==6442== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6442== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==6442== Command: ./boost_leak ==6442== ==6442== ==6442== HEAP SUMMARY: ==6442== in use at exit: 8 bytes in 1 blocks ==6442== total heap usage: 5,967 allocs, 5,966 frees, 701,720 bytes allocated ==6442== ==6442== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 ==6442== at 0x4C2615D: malloc (vg_replace_malloc.c:195) ==6442== by 0x4E3F989: boost::detail::get_once_per_thread_epoch() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39923: ??? (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39BC8: boost::detail::get_current_thread_data() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A528: boost::this_thread::interruption_enabled() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A548: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x404DC4: boost::shared_mutex::lock() (in /tmp/boost_leak) ==6442== by 0x40588D: boost::lock_guard<boost::shared_mutex>::lock_guard(boost::shared_mutex&) (in /tmp/boost_leak) ==6442== by 0x405DB5: boost::thread* boost::thread_group::create_thread<void (*)()>(void (*)()) (in /tmp/boost_leak) ==6442== by 0x403B91: main (in /tmp/boost_leak) ==6442== ==6442== LEAK SUMMARY: ==6442== definitely lost: 0 bytes in 0 blocks ==6442== indirectly lost: 0 bytes in 0 blocks ==6442== possibly lost: 0 bytes in 0 blocks ==6442== still reachable: 8 bytes in 1 blocks ==6442== suppressed: 0 bytes in 0 blocks ==6442== ==6442== For counts of detected and suppressed errors, rerun with: -v ==6442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) ==================================== Is that really a memory leak? Kind Regards Denis

3 5

[filesystem] Issue with replace_extension
by cheesy4poofs 02 Oct '10

02 Oct '10

I've recently switched all our code to filesystem v3 and added BOOST_FILESYSTEM_NO_DEPRECATE on our builds for good measure. One of the changes I had to fix was our use of change_extension(), which was modified to use the replace_extension() method. However, some of our code started failing and I tracked it down to this example: boost::filesystem::path p("C:\\database\\test\\filename"); p.replace_extension(".db"); std::cout << p.string() << std::endl; // OUTPUT - C:\database\test\filename.db p = "C:\\database.1\\test\\filename"; p.replace_extension(".db"); // bug? std::cout << p.string() << std::endl; // OUTPUT - C:\database.db As you can see, in the second example, it truncates the path and assumes the directory name "database.1" has the extension that needs replacing. change_extension() did not behave this way. Is this the expected behavior? Thanks, Scott

2 1

[1.43.0] [variant] Compilation errors when swapping variant type objects
by Adam Badura 01 Oct '10

01 Oct '10

We are using Boost 1.43.0 (we tried to move to 1.44.0 but there were some problems which I reported some time ago) in Visual Studio 2010. And there are some compilation problems when variant type objects are swapped. This does not affect all variant types but I didn't figured out what are the exact conditions (however I guess it is likely something with namespaces and templates). Following code demonstrates the issue: ---------------------------------------- #include <cstdlib> #include <list> #include <boost/variant.hpp> int main() { typedef boost::variant< std::list< int >::iterator > variant_type; variant_type v; variant_type().swap( v ); return EXIT_SUCCESS; } ---------------------------------------- compilation fails with following message: ---------------------------------------- 1>d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(155): error C2668: 'boost::detail::variant::detail::move_swap::swap' : ambiguous call to overloaded function 1> d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(141): could be 'void boost::detail::variant::detail::move_swap::swap<T>(T &,T &)' 1> with 1> [ 1> T=T0 1> ] 1> c:\program files\microsoft visual studio 10.0\vc\include\utility(100): or 'void std::swap<T>(_Ty &,_Ty &)' [found using argument-dependent lookup] 1> with 1> [ 1> T=T0, 1> _Ty=T0 1> ] 1> while trying to match the argument list '(T0, T0)' 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(698) : see reference to function template instantiation 'void boost::detail::variant::move_swap<T>(T &,T &)' being compiled 1> with 1> [ 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(825) : see reference to function template instantiation 'void boost::detail::variant::swap_with<Variant>::operator ()<T>(T &) const' being compiled 1> with 1> [ 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(141) : see reference to function template instantiation 'void boost::detail::variant::invoke_visitor<Visitor>::internal_visit<T>(T &,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(169) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke_impl<Visitor,VoidPtrCV,T>(int,Visitor &,VoidPtrCV,T *,boost::mpl::false_)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(252) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke<Visitor,VoidPtrCV,T0,NoBackupFlag>(int,Visitor &,VoidPtrCV,T *,NoBackupFlag,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1769) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl<first_which,first_step,Visitor,VoidPtrCV,boost::variant<T0_>::has_fallback_type_>(const int,const int,Visitor &,VoidPtrCV,boost::mpl::false_,NoBackupFlag,Which *,step0 *)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> Which=first_which, 1> step0=first_step 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1780) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor_impl<Visitor,void*>(int,int,Visitor &,VoidPtrCV)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void * 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1803) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor<boost::detail::variant::invoke_visitor<Visitor>>(boost::detail::variant::invoke_visitor<Visitor> &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1637) : see reference to function template instantiation 'void boost::variant<T0_>::apply_visitor<boost::detail::variant::swap_with<Variant>>(Visitor &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1631) : while compiling class template member function 'void boost::variant<T0_>::swap(boost::variant<T0_> &)' 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] 1> d:\test\simple\simple.cpp(10) : see reference to class template instantiation 'boost::variant<T0_>' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] ---------------------------------------- Adam Badura

2 2

Potential scoped_ptr improvement
by David Abrahams 30 Sep '10

30 Sep '10

The incantation scoped_ptr<Base> x( new Derived ); will succeed and produce undefined behavior upon x's destruction unless Derived has a trivial or virtual d'tor. It would be pretty easy to prevent something like that from compiling when has_virtual_destructor<Base>::value is false. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[btree] Library working with more compilers and standard libraries
by Beman Dawes 30 Sep '10

30 Sep '10

* VC++ 10 and MinGW/gcc 4.5 are my primary platforms, and the tests continue to pass on those. Some of the tests have been beefed up, too. * The Btree library now passes tests with Cygwin/gcc 4.3. That was a bug in my POSIX implementation code that is now fixed. * VC++ 9 is working OK in release mode. There is a bug in some debug mode code in the standard library <algorithm> header's lower_bound and upper_bound functions. I'm not sure how to deal with that. Maybe supply lower_bound/upper_bound implementations, and switch to them when needed. * I'm about to start a round of tests on Linux. --Beman

3 4

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 29 Sep '10

29 Sep '10

> > > Well, I believe I got it wrong. It is concept maps where the specializtion > > > is to tke plce. It should read: > > > > > > explicit concept< typename T > IntOrPair > "explicit concepts" were never part of any accepted proposal ;-) > > { > > int sum_ints_impl( T const& ); > > } > > > > concept_map IntOrPair<int> > > { > > int sum_ints_impl( int const& i ) { return i; } > > } > > > > template< IntOrPair type1, IntOrPair type2 > > > concept_map IntOrPair< std::pair<type1, type2> > > > { > > int sum_ints_impl( std::pair<First, Second> const& p ) { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > } > > > > template<IntOrPair T> > > int sum_ints( T const & t ) > > { > > return IntOrPair::sum_ints_impl( t ); > > } > I think what you wrote is equivalent to what I posted in > http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 > However, as I noted in that message, trying to constrain something to > be either an Int or a Pair is really against the spirit of GP. I understand. On the other hand, even though concepts were designed to support GP, once they are designed it would be interesting to see how they can be used to do other thing, and what other possibilities they enable. Regards, &rzej

2 1

Advice sought on memory allocation latency reduction C++ standard proposal
by Niall Douglas 29 Sep '10

29 Sep '10

Dear Boost Devs, I am hoping to gain feedback on an ISO C++ standard library proposal I hope to submit. It consists of a rationale (http://mallocv2.wordpress.com/) which shows how growth in RAM capacity is exponentially outgrowing the growth in RAM access speed. The consequences are profound: computer software which has always been written under the assumption of scarcity of RAM capacity will need to be retargeted to assume the scarcity of RAM access speed instead. I appreciate that Boost is not the C++ standard library, however I have asked this on comp.std.c++ and received no reply at all. The proposal comes in two parts: (i) The C proposal (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends the classic 1979 malloc API to enable realloc() to speculatively attempt in-place allocation resizing and (ii) the C++ proposal (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends std::allocator<> with batch allocation and deallocation member functions along with a reallocate() member function. These work much as expected and are intended for STL implementations - I have given a sample std::vector<>::reserve() implementation for the Dinkumware STL which attempts an in-place extension before performing a move construction of the vector contents. I am going to guess that these member functions will be fairly uncontroversial - reallocate() in particular has been in the SGI STL for a while, though in an unhelpful form which is basically a realloc() wrapper. What I think will likely be much more controversial are the new std namespace functions: template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer New(Args&&... args); template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer NewA(size_t n, Args&&... args); template<class T, class allocator=allocator<T> > void Delete(typename allocator<T>::const_pointer p); template<class T, class allocator=allocator<T> > void DeleteA(typename allocator<T>::const_pointer p); These parallel global operators new and delete except of course that they are standard functions and take a std::allocator<> type with which they perform the allocation and deallocation. The biggest danger here obviously enough is the chance of collision with any New() or Delete() defined by application code as the overloading and type specialisation problems (thanks to the unhelpful syntax) of operators new and delete are well known. The second biggest danger is the perhaps confusing duplication of functionality, though of course std::New() and std::Delete() are intended as a superset of global operators new and delete. I would appreciate any feedback, and in case you don't think discussion of this topic is appropriate here I will cross post this email to comp.std.c++. You can reply there instead if you wish. My thanks in advance for your time and consideration. Niall Douglas -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.

3 2

Floating point truncation bug in qi::float_
by Henry Tan 29 Sep '10

29 Sep '10

Hi I am using boost 1.4.1 Spirit::Qi. I think we have a floating point truncation bug in the qi::float_ parser. I attached a simple program to repro the bug. Below are some examples of an input floating point gets truncated (=>) by the qi::float_: 12312321421421 => 12312321720320.000000 123123214 => 123123216.000000 123233.4124 => 123233.406250 I don't see the same issue with the qi::double_. Wondering if this is a known issue? Regards, HTan

5 4

How to cast _1 ?
by Henry Tan 29 Sep '10

29 Sep '10

I want to cast a value of _1 to a _val of a different type. How do I do that? I tried using static_cast_, it does not compile for me. rule<UInt8Iterator, UInt32()> MyRule; ... MyRule = (long_ | float_) [_val = static_cast_<UInt32>(_1)] Any help is appreciated Regards, Henry

2 1

Re: [boost] [asio] Question regarding io_service.post() and pool of threads
by Tan, Tom (Shanghai) 29 Sep '10

29 Sep '10

-----Original Message----- Date: Tue, 28 Sep 2010 11:18:22 +0800 From: Romain CHANU <romainchanu(a)gmail.com> To: boost(a)lists.boost.org Subject: [boost] [asio] Question regarding io_service.post() and pool of threads > >Extracted from Boost Asio reference: "The >io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/ref >erence/io_service.html> >guarantees >that the handler will only be called in a thread in which the run(), >run_one (), poll() or poll_one() member functions is currently being invoked." > >For my understanding, since there is a pool of threads, a handler can >run concurrently in different threads, even though we are using >io_service.post(). > >Is that correct? My concern here is about the need or not to lock the >data accessed by the handler. > My understanding is that, it's another way to say that those calls won't create an additional thread while calling the completion handler having been registered by io_service.post(). Therefore, if io_service.run() itself is running in n threads, it's guaranteed all the registered completion handler will be invoked in at most n threads at random order, since there are only n threads in total . -Tom

2 1

Fwd: [test] crash with the following test
by Felipe Magno de Almeida 28 Sep '10

28 Sep '10

Hello, Since I couldn't solve the problem in boost-users list I'm forwarding here. ---------- Forwarded message ---------- From: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Date: Wed, Sep 22, 2010 at 2:07 PM Subject: [test] crash with the following test To: boost-users(a)lists.boost.org With boost 1.44.0 (the same happens with 1.43) the following test causes a crash in framework.ipp:388 with a dereference of a NULL pointer. The test_unit* res returns NULL from s_frk_impl().m_test_units[id] where id is 1. id is equal to 1 because when unit_test::framework::run is ran, id is INV_TEST_UNIT_ID is passed to it. Then in framework.ipp:399 if id == INV_TEST_UNIT_ID id is assigned the value in master_test_suite().p_id which is 1. I've verified that when master_test_suite is constructed it assigns INV_TEST_UNIT_ID to p_id, so I'm lost why this is 1 here. Then, back in framework.ipp:386 s_frk_impl().m_test_units there's only one element in the map and the id is 65535 and not one. -- test.cpp -- #define BOOST_TEST_MODULE parse_empty_import_documents #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_CASE (parse_empty_import_documents) { } -- test.cpp -- Any help would be appreciated. -- Felipe Magno de Almeida

2 5

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> > I think so far I have failed to make my use case sufficiently clear, so > > I'll simplify and try to follow the Process. Take the following simple > > algorithm sum_ints: > > > > template<class First, class Second> > > int sum_ints_impl( std::pair<First, Second> const & p ) > > { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > > > int sum_ints_impl( int i ) > > { > > return i; > > } > > template<class T> > > int sum_ints( T const & t ) > > { > > return sum_ints_impl( t ); > > } > > Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is > always required. The second concept_map implements the recursion. > > Regards, > &rzej > > explicit concept< typename T > IntOrPair > { > } > > concept_map IntOrPair<int> > { > } > > template< IntOrPair type1, IntOrPair type2 > > concept_map IntOrPair< std::pair<type1, type2> > > { > } > > template<IntOrPair First, IntOrPair Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > > template<IntOrPair T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Well, I believe I got it wrong. It is concept maps where the specializtion is to tke plce. It should read: explicit concept< typename T > IntOrPair { int sum_ints_impl( T const& ); } concept_map IntOrPair<int> { int sum_ints_impl( int const& i ) { return i; } } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { int sum_ints_impl( std::pair<First, Second> const& p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } } template<IntOrPair T> int sum_ints( T const & t ) { return IntOrPair::sum_ints_impl( t ); } Regrds, &rzej

2 1

New library ( countertree: Binary trees with access by position like the vectors)
by Francisco José Tapia 28 Sep '10

28 Sep '10

Is there any interest in a library implementing counter trees, which permit us to access to the elements by the position, as in the same way than a vector.The insertion, deletion and access to elements are operations O(log N). The iterator and const_iterator are random access iterators in the same way than the STL vector::iterator and STL vector::const_iterator. These iterators and const_iterators have a function pos() which provide the position in the tree. The first class implemented is vector_tree wich has the full interface of the STL vector and STL deque. When the information stored in the vector_tree is sorted, we can build the new classes boost::set, boost::multiset, boost::map and boost::multimap. These clases have the full interface of the STL set , multiset, map and multimap, plus a function which permit to access to the elements of the set, map... by the position. The iterators of this data stuctures are random access, and have a function to take the position of the element pointed by the iterator. The performance of these data stuctures is similar to the STL set, multiset, map and multimap You can find the documentation, the code and the test programs in : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=counte… The compilers used for to check are GCC 4.5 ( 32 and 64 bits) and Visual Studio 2008 Thanks Francisco Tapia fjtapia(a)gmail.com

6 6

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> I think so far I have failed to make my use case sufficiently clear, so > I'll simplify and try to follow the Process. Take the following simple > algorithm sum_ints: > > template<class First, class Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > template<class T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is always required. The second concept_map implements the recursion. Regards, &rzej explicit concept< typename T > IntOrPair { } concept_map IntOrPair<int> { } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { } template<IntOrPair First, IntOrPair Second> int sum_ints_impl( std::pair<First, Second> const & p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } int sum_ints_impl( int i ) { return i; } template<IntOrPair T> int sum_ints( T const & t ) { return sum_ints_impl( t ); }

1 0

Interest in specialized types
by Henning Basold 28 Sep '10

28 Sep '10

Hello, in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler. So I think that is something that can be generalized. The concept is to wrap a type into a class and restrict the interface. This ensures that values from one context (e.g. an id) can't be used in another context (e.g. adding of number or as an id for other objects). Attached is a very simple implementation where the needed concepts can be specified as parameter. To distinguish for example between different id types also a tag type can be specified. Do you think this might be a useful utility? Or is there something similar already available? I've searched the vault but did not find anything. Regards Henning

5 11

Recall: Boost Digest, Vol 3047, Issue 1
by Tan, Tom (Shanghai) 28 Sep '10

28 Sep '10

Tan, Tom (Shanghai) would like to recall the message, "Boost Digest, Vol 3047, Issue 1".

1 0

[asio] Question regarding io_service.post() and pool of threads
by Romain CHANU 28 Sep '10

28 Sep '10

Hi, I was looking at this website where the guy gives an interesting example about the use of a pool of threads and io_service.post(): http://mostlycoding.blogspot.com/2009/05/asio-library-has-been-immensely-he… However, something confuses me a bit, cf. the website "In just a bunch of lines of code we have a thread pool executing any arbitrary task whenever one thread is available. No need to address the usual multi-threading issues with concurrent jobs sharing few resources: just post what you need and let io_service take care of it!" Extracted from Boost Asio reference: "The io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/reference/io_servi…> guarantees that the handler will only be called in a thread in which the run(), run_one (), poll() or poll_one() member functions is currently being invoked." For my understanding, since there is a pool of threads, a handler can run concurrently in different threads, even though we are using io_service.post(). Is that correct? My concern here is about the need or not to lock the data accessed by the handler. Thank you. Regards, Romain

3 3

Missing file
by Belcourt, Kenneth 28 Sep '10

28 Sep '10

Tests failed for this missing file. error: Unable to find file or target named error: '../no_limits_lowest_pass.cpp' error: referred from project at error: '/scratch/boost/boost/libs/config/test/all'

2 1

Re: [boost] [B-tree] Continuing development
by Brian Wood 27 Sep '10

27 Sep '10

OvermindDL1: <woodbrian77(a)gmail.com> wrote: >> >> Just fyi, I've been experimenting with a similar string -- >> http://webEbenezer.net/misc/lil_string.hh . >> >> If an operation would result in a string with length more than 255, >> an exception is thrown. ?This allows the length of the string to be >> marshalled with one byte. ?As you mention this limitation is not a >> problem in many circumstances. ?I'd quibble a little with it not being >> suitable for demanding applications. ?I think it is fine to use it in that >> context, but that you might need to also use other string classes. > > Why not use a compressed uint type? Google's Protocol Buffers > compressed uint compresses an uint just fine, below 128 will be >represented in one byte, etc..., it works very simply, by just having > the MSB be a marker indicating the last byte of the integer if it is > zero, thus it is base 128 instead of base 256 per byte, so as an > example: > hex -> compressed bits > 0 -> 0000 0000 > 1 -> 0000 0001 > 300 -> 1010 1100 0000 0010 > And so forth, and if you have looked in the protocol buffer source it > decodes each byte very quickly and efficiently. So if you are worried > about space, you could use this (especially since I have many use > cases where strings would exceed 255 characters, and we need a > 'bytestream' type or so too). I've thought about doing that and I'm using that technique in one place in my library. The only thing I can say is I like the documentation effect that the name lil_string has. I don't claim what you suggest is a bad idea, but at the moment I'm happy with what I have. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

[Atomic] Confusion about Atomicaty of atomic::exchange.
by cexer 27 Sep '10

27 Sep '10

Hey guys, I am very interested in Boost.Atomic library, but when I went deeply into the source code, I found there are mysteries that I can not fullly understand, for example, the implementation of atomic::exchange, list its implementation code (see. /atomic/builderhpp, line 47.) as follow : integral_type exchange(integral_type replacement, memory_order order=memory_order_seq_cst) volatile { integral_type o=load(memory_order_relaxed); // A do {} while(!compare_exchange_weak(o, replacement, order, memory_order_relaxed)); // B return o; } From my view, although atomic::load and atomic::compare_exchnage_weak are both atomic operations, the atomicity of atomic::exchnage is not guaranteed，take this illustrative code-snippet for example : atomic<int> i( 1 ); thread1 i.exchange( 100 ); thread2 i.exchange( 200 ); // C To help explanation, in the atomic::exchange method and the above code-snippet, I lable corresponding code fragments as A, B, C. Assume that thread1 is completed running A, but has not arrive B yet, at this moment values of i and o ( o is the temporary variable in atomic::exchange method, see source code of atomic::exchnage above. ) are: o == 1 i == 1 Since the atomic::exchange is not locked, and calling to atomic::load using memory order of memory_order_relaxed, under this circumstance, atomic::exchnage is not prevent from calling from more than one threads, so these is possibility that thread2 could call atomic::exchange (like the code C above) between A and B, after thread2 completed C, the value of i is changed, values of i and o values are now: o == 1 i == 200 Then thread1 arrives code B, because at this moment o! = i, calling to compare_exchnage_weak will fail, atomic::exchange them will went into infinite loop, this is terrible. I know I must missing something here, so I posting here, expecting that someone could please remind me a little bit?

2 1