October 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

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

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

16 60

[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

Re: [boost] [filesystem] temp_dir_path()
by Domagoj Saric 21 Feb '11

21 Feb '11

"Beman Dawes" <bdawes(a)acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com... > On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz(a)gmail.com> wrote: >> Would it be perhaps possible to provide a lower-level function (even in >> the detail namespace) that uses a plain char buffer and an error code, >> that is free of std::vectors, std::strings, boost::paths, >> system::error_codes and >> other things one might not want to pay for (especially if one does not >> use them otherwise) just to make a system API call..? The 'proper' >> version can then wrap the thinner one... > > It would be technically possible, of course, but ... > > What you are really asking for, I think, is a C language interface or > something pretty close to that. The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'... - it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?' The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage... > I could have designed the library that way, but didn't want to add a > third way for users to do things, and didn't want to take on the > increased documentation, test, etc, workload. Calling it a 'third way' is bit too hard IMO, why not think of it just as an overload (albeit of a more extreme kind)? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

[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

[system][chrono] header-only libs
by vicente.botet 06 Jan '11

06 Jan '11

Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 23

[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

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- 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

2 2

[gil] New IO release
by Christian Henning 30 Nov '10

30 Nov '10

Hi there, a new gil IO extension is ready for download. Here is the link: http://code.google.com/p/gil-contributions/downloads/detail?name=boost_revi… This is the final version that will be used for the boost review. Could someone try to build documentation on Linux? Thanks to all people that have helped me out. Regards, Christian

5 18

[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

Bug-fix volunteers: risks, downsides?
by Jim Bell 26 Nov '10

26 Nov '10

To round out the discussion... What risks or downsides would there be to recruiting a little legion of bug-fix volunteers and turning them loose on the tickets and/or regression matrix?

10 23

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

What's so cool about Boost.MPI?
by David Abrahams 18 Nov '10

18 Nov '10

Just wanted to call some attention to this article I wrote about Boost.MPI: http://daveabrahams.com/2010/09/03/whats-so-cool-about-boost-mpi/ I think it might be useful to link that from the Boost.MPI docs, too. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2

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

[function] function wrapping with no exception safety guarantee
by Daniel Walker 15 Nov '10

15 Nov '10

Hi all, A few weeks ago, there was a request to remove boost::function's dependency on boost::throw_exception when the user ensures that boost::function is always initialized before attempting a call. https://svn.boost.org/trac/boost/ticket/4646 Providing an alternative invocation method in addition to the call operator is an unattractive solution for many reasons; e.g. boost::function would be less function-like syntacticly. Instead, why not provide an alternative function wrapper with no exception safety guarantee and no dependency on boost::throw_exception? Thanks to Boost.Function's implementation design, which uses preprocessor metaprogramming to generate many function wrappers with different arities, it is simple to generate a function wrapper with no exception safety guarantee. I have submitted a feature request with a patch that implements boost::unsafe_function -- a function wrapper with no exception safety guarantee -- along with tests and updated documentation. https://svn.boost.org/trac/boost/ticket/4720 unsafe_function's API and semantics are identical to boost::function except that the behavior of operator() is undefined when uninitialized. Also, swap, constructor and assignment operators have been added to allow an unsafe_function to wrap the target of a boost::function and vice versa. unsafe_function is primarily useful in certain environments in which exceptions and/or compiler optimizations are unavailable, such as some embedded systems. On contemporary PC hardware, unsafe_function typically would not have an advantage over boost::function. For example, with object code generated by gcc -O2, I could only detect a ~1% difference between the two in terms of runtime costs using a simple benchmark; i.e. less than a nanosecond. However, with -O1, unsafe_function costs ~15% less than boost::function due to the lack of overhead from the strong exception safety guarantee. Thoughts? Daniel Walker

19 127

[1.45] Where are we in the release process?
by John Maddock 14 Nov '10

14 Nov '10

I'm asking because someone's just assigned a Boost.Interval issue to me: https://svn.boost.org/trac/boost/ticket/4799#comment:1 Seems like there is a trivial fix in Trunk, but as the library appears not to have been maintained for while, it looks like none of the patches that some folks have applied to Trunk have been merged to release :-( On a related note, I believe there are quite a few old and unmerged changes to the Utility lib as well. We really need to figure out a better way of dealing with this... John.

6 13

[optional] swap not a member of boost::optional
by Eric Niebler 10 Nov '10

10 Nov '10

It seems like boost::optional has a swap member function on trunk but not on release, and it's been this way for a few releases already. Can we get this inconsistency resolved? I've been bitten by it a few times already when merging things to the release branch. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 1

[function] new implementation
by Domagoj Saric 09 Nov '10

09 Nov '10

Hi, <...those that followed the latest function related discussions can skip the first paragraph...> For about a year and half now (or even more but that's about how long I've been involved in the matter) there have been repeated discussions/requests/complaints about various aspects of Boost.Function. Most of those fall into one or more of these categories: - overall code speed overhead - overall code bloat overhead - lack of configurability - dependencies on RTTI and exception handling with the most frequently brought up specific issue being the various implications (in all of the above mentioned areas) of the hardcoded throw-on-empty behaviour... Unfortunately Boost.Function code remained virtually unchanged (except for the added RTTI emulation for platforms w/o RTTI support) with all of the issues still remaining... The new implementation proposal @: https://svn.boost.org/svn/boost/sandbox/function/boost/function http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… Objects solves or at least provides drastic improvements for all of the mentioned issues. It is intended as a drop in replacement for the current implementation and as such I have so far tested it in the following ways: - compiling some real world code: VC10, GCC 4.2.1, LLVM-GCC 4.2.1, GCC 4.5.1, GCC 4.6, Clang 2.0, Clang 2.8 - compiling and running a real world project: VC10, Clang 2.8 - building Boost trunk: VC10, GCC 4.2.1, GCC 4.5.1, Clang 2.0 - running Boost regression tests for Function, Signals, Signals2, Thread, Program Options and Graph libraries: VC10, GCC 4.2.1, Clang 2.0. (All of the tests passed except for two bogus assertion failure boxes that pop up with VC10 and the Program Options tests during the automated regression test procedure that OTOH do not popup when I run the same tests manually through the VC10 IDE, i.e. the tests finish successfully...I tried to make sure all the relevant compiler switches were the same in both cases so I am out of ideas what else can make the difference.....) Next, let me give you a comparison of for-size-optimized code generated by VC10 with both the current and the proposed implementation for a short code snippet demonstrating invocation, construction and assignment: struct X { int foo( int const x ) const { return x + y; }; int y; }; int main( int /*argc*/, char * * /*argv*/ ) { using namespace boost; X x; function<int(int)> foof( boost::bind( &X::foo, &x, _1 ) ); foof( 0 ); function<int(int)> barf; barf = foof; barf( 1 ); return 0; } Notice in new_function_code_listing.txt how all of the wrapper code in the new Function was completely transparent to the compiler and was completely inlined to relatively simple machine code with direct calls to/through the vtable pointers...while OTOH in current_function_code_listing.txt the code generated for the "barf = foof;" assignement alone is several times larger than the entire code generated for the new Function implementation. The small asm snippet of the generated invoker/'thunk'/'trampoline' code also demonstrates the effects of various tweaks done to minimize or all together remove the need for any stack adjustment on the invoker side... The new implementation of course has the same semantics and exception safety guarantee levels as the original/current one. Listing all of the improvements and detailed implementation changes here in the first post would be quite cluttering as they are quite numerous. Those that desire more tests and details right now, can follow this trail: http://lists.boost.org/Archives/boost/2010/01/160908.php As for the dependencies issue this is solved in several ways: - use of exception handling: new code uses guard objects instead of explicit exception handling and provides a way to change on-empty-behaviour so that the EH code/dependency can easily be removed/disabled - use of RTTI (for getting the type of the stored function object): this can be globally disabled with the BOOST_FUNCTION_NO_RTTI macro. BOOST_NO_RTTI is not used for this purpose for backward compatibility reasons: in the current implementation it actually turns on RTTI emulation...The idea is to also add per instantiation RTTI on-off configurability... 'Configurability' will probably be the most controversial issue/change because it required the addition of an extra template parameter through which an MPL list of policies can be specified at compile-time. This parameter is properly defaulted to allow existing code to compile without changes while providing current Boost.Function behaviour (e.g. on-empty- behaviour). As all the performed tests showed this to also be true in practice the proposed code should IMO go in as a straight drop-in replacement but, of course, I might have missed some important higher level detail/concern so this is open to discussion... Currently two policies are supported: - on throw behaviour (with throw-on-empty, nop-on-empty and assert-on-empty handlers provided) - whether the function instantiation should mark itself (i.e. its operator()) as nothrow. Additional policies my be added later, for example: - sizeof and/or alignment of the SBO buffer - default allocator - per instantiation RTTI on/off ... Finally, there is one more addition, somewhat 'unholy' as it brings in the concept of binding into Boost.Function but considering its efficiency and/or verbosity benefits (and the fact that the first issue can be 'explained away' by saying that this is not actually 'binding' but a workaround for the lack-of-delegates-support C++ language deficiency). The addition is in the form of two more assign() member function overloads (one for a free function that has the exact signature as the Boost.Function instantiation, and one for a member function that has a matching signature with the addition of a this pointer) that allow assignment of (suitably typed) plain (free or member) functions specified as non-type-template parameters. This allows for the removal of the extra indirect-call-through-function-pointer otherwise incurred by traditional assignment of function pointers (not functors), which is actually a rather common use case. For example, in the above example given, one can now write: foof.assign<X, &X::foo>( x ); and get a trivial invoker with the X::foo() target function inlined straight in... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

7 27

[build] print test failing on release
by Eric Niebler 06 Nov '10

06 Nov '10

Volodya, can you investigate the failure of the Boost.build "print" test on the release branch? It's currently failing across all platforms. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

How about a call for bug-fix volunteers?
by Jim Bell 05 Nov '10

05 Nov '10

Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done). So what if we try to recruit a couple helpers for each library? I see two avenues where we can use some volunteer help to improve boost's quality. 1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues. Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication. Not so glamorous, but important and great experience. Perhaps we could assign a little of each to each SoC person. Maybe put the word out on Slashdot. See previous topic threads (http://lists.boost.org/Archives/boost/2010/10/index.php) "Report # 29 (aka 1.45 blockers) is too narrow" "[1.45] Beta final schedule" "[1.45] Thread issues"

14 18

Unicode Library
by Emery Denuccio 02 Nov '10

02 Nov '10

Hey guys, about three years ago I mentioned I was working on a unicode library for boost and there was some interest then. I guess professional work got in the way and I never got around to polishing it up and submitting for review. I was digging through an old hard drive and found the source. It still lacks a few features, but is pretty damn cool. I threw up on on github if anyone wants to take a look and possibly help me get rolling on it again. Here: http://github.com/imori/boost.unicode Thanks, -em

3 2

[iostreams] Inconsistency of "faiture" of writes in Sinks and filters
by Artyom 02 Nov '10

02 Nov '10

Hello, I implement the sink device that sometimes may fail on writes. When Sink is implemented it should throw an exception on fault. To notify the stream on error. However it is not always works this way. I've got the exception to "leak" to the main program when I combine in the filter gzip_comressor() filter that writes to output device that its Sink is full. When I call reset on the filter the exception in leaking to the program instead of being caught. Is it bug or (accidental) feature? On the other hand, if I don't throw but rather return 0, I get into infinite loop in the boost::iostreams::non_blocking_adapter::write when I call filter.reset(). So I how can I write a sink device that reports errors? In following example the exception is caught when filter.reset() is called: #include <boost/iostreams/stream.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/gzip.hpp> #include <boost/iostreams/tee.hpp> #include <iostream> class my_small_device : public boost::iostreams::sink { int count; public: my_small_device() : count(1000) {} std::streamsize write(char const *d,std::streamsize n) { if(count < n) throw std::runtime_error("Device is full"); count-=n; return n; } }; int main() { try { using namespace boost::iostreams; boost::iostreams::stream<my_small_device> output(my_small_device(),10); { boost::iostreams::filtering_ostream filter; filter.push(gzip_compressor()); filter.push(output); for(int i=0;i<10000000;i++) { if(!(filter << i << '\n')) { std::cerr << "Fail!" << std::endl; break; } } std::cout << "Closing filter" << std::endl; filter.reset(); } std::cout << "ok" << std::endl; return 0; }catch(std::exception const &e) { std::cerr << "Catched " << e.what() << std::endl; return 1; } } Thanks, Artyom

1 2

Issues with intel's compiler and newer builds of GCC
by Bryce Lelbach 02 Nov '10

02 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While working on getting icc to not choke on Serialization (the Boost test boxes indicated that icc was failing to build with the addition of my changes), I came across a very nasty bug the occurs when using icc with version 4.5 or higher of GNU's standard library - GNU's <iomanip> uses what are either illegal or C++0x semantics which icc doesn't support. Serialization uses <iomanip>, and icc seems to select the latest version of libstd++ installed on a Linux machine as it's default standard library (I have been unable to find an Intel standard library - I'm assuming such a thing doesn't exist). When using an older version of libstd++, icc + Serialization compiled fine. I removed all uses of IO parameterized manipulators in Serialization (there were only maybe half a dozen cases)*, and got icc to compile Serialization with libstd++ v4.5. Is there any chance the linux/darwin Intel build bots can be set up to use libstd++ v4.4, if they're not already using it? Intel is apparently aware of this issue, but it won't be fixed until their next major release (http://software.intel.com/en-us/forums/showthread.php?t=74691) If the build bots aren't using v4.5 of GNU's standard library, then I'm at a loss as to why Serialization is failing to build on them. My only other thought is that the timeout for the build cycle is too low - the failures indicate that the error is a timeout after 300 seconds. On a more general note, is Intel on Linux/Darwin a "supported" Boost compiler? Unless I've missed something, Intel doesn't provide a standard library, and I find it a bit troubling that they ship their compiler to use GNU's standard library by default. Intel is far behind GCC in C++0x support, and newer versions of the GNU standard library have been making increasing use of GCC's C++0x support. Unless icc starts shipping with an older version of libstd++/use a compiler neutral standard library such as the Apache standard library/starts to catch up with GCC's C++0x support, I imagine that using icc to compile C++ code that makes use of the standard library will become increasing difficult. * I also had to modify proto/debug.hpp to not use <iomanip>. Eric, when I was having an issue with typeinfo in proto/debug.hpp a couple days ago, you mentioned that proto/debug.hpp shouldn't be included by proto/proto.hpp? If that's accurate, is there any chance that change could be made, and if not, can I commit my changes to proto/debug.hpp or send them to you as a patch for review? - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky+c7cACgkQO/fqqIuE2t4DZQCfUnhGAsqX4GDZu3Ze7BvrPBRL XRkAn33vWcTm1RuXk2iuQWH0+bp+RVUf =mHwK -----END PGP SIGNATURE-----

7 9

[range] - Proposal to change the indexed range adaptor
by Neil Groves 01 Nov '10

01 Nov '10

Fellow maintainers and developers, Having gained experience using the Boost.Range library changes I submitted for Boost 1.43, I have become dissatisfied with my indexed adaptor. Currently the underling index_iterator has a return type identical to the wrapped iterator, and the index is extracted via a method call on the iterator. While this works for the case where one is writing algorithms to explicitly utilise the underlying iterator, it is clearly a poor design choice since it severly limits the interoperation with other algorithms. I feel that I have made a mistake. I propose that a breaking change is made to the index range adaptor so that it returns a pair<original_reference_type, index_type>. How do you feel about this change? Do you have alternative suggestions? Regards, Neil Groves

5 7

boost::optional - rvalue references
by Daniel Larimer 01 Nov '10

01 Nov '10

I have been looking to optimize my code using rvalue references when they are supported; however, I currently use boost::optional which does not know how to handle / forward rvalue references. In fact even the in_place() utilities do not work to forward the rvalue into the proper constructor. My latest profiling shows that assigning a large vector to an optional is eating up 5% of my CPU time and I could replace this with a std::move() if boost::optional supported it. I have attached an updated optional.hpp with the minimum changes necessary to support the following: test v ( 99 ); test A ( 400 ); boost::optional<test> i2(std::move(v)); i2 = std::move(A); Such that if test were a vector and 99 and 400 were the sizes, the end result is v & A are of size 0 and i2 is of size 400 and no copy constructors are called (only moves). What is the plan for updating more of boost to take advantage of rvalue references?

2 1

Get PID from local socket?
by Rush Manbert 01 Nov '10

01 Nov '10

I am using boost ASIO to do socket communications between an app and a daemon running on the same machine. The communications go through a Unix Domain Socket on the Mac and a named pipe on Windows. I'm looking for a way that the client app could obtain the PID of the daemon process, starting with the connected socket. I have tried calling local_endpoint() and remote_endpoint(), but the only information there seems to be the socket path (at least on the Mac). My google searches have turned up nothing, and they actually suggest that there is no way to achieve this on the Mac, even if I were using the "normal" socket API. Does anyone know whether this is possible and how to do it? Thanks, Rush

2 1

[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

[rational] PATCH: Use ordered_euclidean_ring_operators
by Mario Lang 30 Oct '10

30 Oct '10

Hi. Below is a patch which makes rational.hpp use grouped arithmetic operators. While we are at it, use ordered_euclidean_ring_operators instead of just ordered_field_operators. While it might sound strange at first, mod can make sense even for rational numbers. For instance, Common Lisp, which has a native rational type, works fine if mod is used on rational numbers... template <typename IntType> rational<IntType>& rational<IntType>::operator%= (const rational<IntType>& r) { return *this -= r * floor(rational_cast<double>(*this / r)); } I am aware that the use of floor() is probably problematic. I am all open for comments and suggestions for improvements. -- Thanks, ⡍⠁⠗⠊⠕

1 0

[graph] PATCH to eliminate gcc 4.2 warnings when compiling boost/graph/read_dimacs.hpp
by Daniel Trebbien 30 Oct '10

30 Oct '10

Attached is a patch that changes the definition of `err_message` in boost/graph/read_dimacs.hpp@66260 from: static char *err_message[] to: static const char *err_message[] This will eliminate the warnings that were recorded at: http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-4-… Daniel

2 1

Is it time for another bug sprint? (Post 1.45 release, I mean)
by Marshall Clow 30 Oct '10

30 Oct '10

What do people think? -- Marshall

11 17

[regex] Disabling ICU check when building with bjam, 1.44
by Cliff Green 30 Oct '10

30 Oct '10

This is on Boost 1.44, g++ 4.1.2 on Linux (RHEL 5.x, can't remember the x at the moment), although it applies generally to building regex. I can't find a way to easily "disable" the "ICU installed" check and resulting functionality / build. I chatted on IRC, and the only way some (experienced Boost) developers could come up with was to change: alias icu_options : : : : [ check-target-builds has_icu : $(ICU_OPTS) : ] ; to alias icu_options : : : : ; in Jamfile.v2. My situation / use case: Our build system has ICU installed. Our deployment system has exactly the same OS and runtime environment, except that the ICU package is not installed. I would like to build regex without the "check that ICU is installed to determine whether the enable ICU" logic in the jamfiles. The regex documentation has an: "-sHAVE_ICU=1" example, but "-sHAVE_ICU=0" doesn't work, and tracing through the jamfiles / boost build I couldn't find where that option is honored / processed. There's also a BOOST_HAS_ICU macro that is defined or undefined in various ways, but adding define=BOOST_HAS_ICU 0 to bjam also didn't appear to do anything (and I tried some other ways to undefine BOOST_HAS_ICU, including in the jamfile, but nothing seemed to work). The docs also mention that the default is to not enable / build with ICU, but that doesn't seem to be the case (with 1.44). (From the first line of ICU build section: "A default build of this library does not enable Unicode support via ICU. There is no need to enable ... ".) So I'm confused (as well as some other regulars on IRC), and either the documentation needs updating, jamfiles need updating, or my understanding needs updating. For now, the workaround mentioned above works fine, and the resulting regex.so file does not have any ICU external library dependencies (which is what is desired for our deployment environment). Thanks! Cliff

2 2

[assign] list_inserter regression test failure on VC10 / release branch
by Richard Webb 30 Oct '10

30 Oct '10

Another minor regression test fix: The list_inserter regression test (libs\assign\test\list_inserter.cpp) was fixed for VC10 on the Trunk in revision 62737, but hasn't yet been merged to the release branch. (the change also fixes one of the errors from GCC/C++0x, but the test still fails for other reasons).

1 0

[1.45] Beta next week?
by Beman Dawes 30 Oct '10

30 Oct '10

I've been too busy to do much on 1.45, but don't see any reason we can't get a beta out next week more or less as scheduled. If anyone know of any showstoppers, please let us know what the problem is. Thanks, --Beman

11 35

[mpl] anyone fancy merging the for_each test to the release branch?
by Richard Webb 29 Oct '10

29 Oct '10

Does anyone feel like merging libs/mpl/test/for_each.cpp (revision 65167) to the release branch? It's only a minor change to the test itself, but it clears a failure on VC10 and various C++0x GCCs.

3 2

[quickbook] Code links not working
by Edward Diener 29 Oct '10

29 Oct '10

I can not seem to get the quickbook code links to work. Nothing is being generated from the code link. As an example, to test them out I have in quickbook: This is a test of a macro reference - [macroref VMD_DATA_SIZE Test Macro reference] . and in my doxygen generated XML I see: <library-reference id="variadic_macro_data_reference"> <title>Variadic Macro Data Reference </title> <header name="boost/variadic_macro_data/VariadicMacroData.hpp"> <macro name="VMD_DATA_SIZE" kind="functionlike"> etc. but the output shows: This is a test of a macro reference - . Any ideas to get this to work would be appreciated.

12 20

[Thread][Release] Boost.Thread and 1.45 release
by Anthony Williams 29 Oct '10

29 Oct '10

Hi, I've fixed all the outstanding "showstopper" bugs in boost.thread on trunk (including the thread interruption issue, #2330), apart from #3847 (https://svn.boost.org/trac/boost/ticket/3847) - "Unable to statically link thread lib on ia64" I don't know how to fix this, and this platform doesn't appear to be actively tested. Is it OK to merge the other fixes to the release branch? Anthony -- 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

3 8

[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

Boost Threading Shared Memory
by Tanya Gillis 29 Oct '10

29 Oct '10

I have a question regarding Boost threads, and am awaiting acceptance into the Boost Threads forum. I was wondering if anyone can help me. I am creating a multithreaded application using Boost threading, and would like to know how shared memory is implemented by Boost for threading. Each thread creates an object separately, and that object has a private member variable. We are seeing in our application that that member variable is looking the same, as if it was shared among the threads. Is this plausible? How does it work? Thanks.

2 1

Call for interest - BOOST_AUTO_FUNCTION
by Matt Calabrese 28 Oct '10

28 Oct '10

I've been noticing that a lot of times in 0x code I've found it useful to create a very simple "auto function" macro that uses trailing return type syntax with decltype with 1-liner functions that automatically repeats the same expression in both the return type and the return statement. #define AUTO_FUN( name, param_list, expression ) \ auto name param_list -> decltype( expression ) { return expression; } There are two big advantages to this. The first and most obvious one is that it reduces redundancy when you have a 1-line function template which has a difficult to deduce return type that you generally would use decltype on, and the more subtle benefit is that since the exact expression is repeated in the return type you automatically get "perfect-fit" SFINAE. By that I mean it provides a quick way to SFINAE-out potential instantiations before instantiating the implementation. Because of this, even though a return type may be simple to deduce without decltype, the macro is still a valuable tool since it can cause substitution to fail if the body of a function template would fail to instantiate. You get very basic, automatic, syntax-only concept checking for free. It's a simple macro, but I find that it gets lots of use. As an example: http://codepaste.net/iqzbiz The above example is a simple "multi_cast" that chains several static_casts in a row (the example code shows a potential use-case). The subtlety here is that the return type is easily deducible without the need for decltype (the return type would just be "TargetType"). Instead, the macro is used because it causes substitution to fail if the body of the function would fail during instantiation. So when using "multi_cast" here, If someone attempts to do a cast where any of the intermediate types is not a valid conversion, rather than getting a complicated error nested inside of several instantiations, you get a single error message at the top-level call-site stating that there is no match for the function call (well, at least it's a simple to read error in gcc... *cough*). This works because if the body of any of the calls would have an error, substitution would instead fail, meaning substitution would fail for the caller, all the way back up to the top without any bodies being instantiated. In other words, it's SFINAEs all the way down :| I find this type of functionality to be very useful, particularly in libraries. In fact, I find myself using it for just about all 1-line function templates. Do others agree that this would be a worthwhile addition to boost? Documentation should be quick to write up. The macro would of course be renamed to something along the lines of BOOST_AUTO_FUNCTION If anyone thinks multi_cast would be useful, let me know and I'll also spin off a separate thread for that, though I'm tempted to think it's more of a curiosity than something that would get much use. -- -Matt Calabrese

11 54

New video from Boostcon
by Marshall Clow 28 Oct '10

28 Oct '10

Roshan Naik: Logic Paradigm for C++ http://blip.tv/file/4307883 Some people have asked about Doug Gregor's Clang talk. Unfortunately, Doug's employer nixed recording that one. -- Marshall

1 0

Bidirectional streams/archives - Frames
by vicente.botet 28 Oct '10

28 Oct '10

Hi, The use I have is to implement binary messages that are user through protocol stacks. When sending a message, lower layers add usualy headers and trailers to payload comming from the upper layer. When receiveing a message, lower layers extract its corresponding headers and trailers before passing the payload to the upper layer. I'm thinking in generalizing the stream or archive concept, so we could in addition to been able to read from the begining and write at the end, been also able to read from the end and write from the begining; a kind of bidirectional stream or archive. I was thinking in namming the concept "frame", as frames are usualy composed of header, payload and trailer. Do you have other namming sugestion? Could this concept have any interest for Boost? Please, let me know if there is already someting on Boost or the standard library that could help me. Best, _____________________ Vicente Juan Botet Escribá

2 2

spirt status?
by Robert Ramey 28 Oct '10

28 Oct '10

What is the situation of the spirit library in the trunk? The serialization library now depends upon the latest spirit to parse xml archives. But now serialization can't be built for a number of compilers which previously could handle this library. This was not a surprise to me as its not unusual to require some tweaks to get this to work. But now I'm surprised that this hasn't resolved the issue. The newer version of spirit has been around for at least a year, and the serializaiton library xml grammar is very simple compared to other spirit applications so I didn't anticipate any major problems - but it seems that we now ahve them. Could spirit library developers take a look at this and give us an idea of what we should do about this? Is anyone working on this? Should we just roll back and try again before the next release? Robert Ramey

7 11

[gil][io_new] Problems with templates
by Christian Henning 27 Oct '10

27 Oct '10

Hi there, I don't see the woods because of all the trees. Could someone get the latest code from here: http://code.google.com/p/gil-contributions/source/browse/#svn/trunk and try to compile the following code: #include <boost/gil/extension/io_new/tiff_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { typedef mpl::vector< gray8_image_t , gray16_image_t , rgb8_image_t , gil::detail::gray1_image_t > my_img_types; any_image< my_img_types > runtime_image; read_image( "C:/gil_contributions/test_images/tiff/test.tif" , runtime_image , tiff_tag() ); return 0; } Why do I have this static assertion in read.hpp[662]? I don't understand why the two buffer types are different. Any help is very welcome, Christian

2 4

Google Code-in 2010 (another Google program like Summer of Code)
by Boris Schaeling 27 Oct '10

27 Oct '10

Boost is invited to become a mentoring organization in the Google Code-in 2010 program. If you have never heard about it (like me :): It's basically Google Summer of Code for pre-university students (the most important requirement is that participants are between 13 and 18 years old). This program is organized as a contest though: It's not so much about mentoring but setting up tasks in eight categories (writing code, documenting, translating etc.). Students will pick then tasks, and judges from participating organizations decide who won. :) While I've no idea if there is any interest to participate in this new program (are there any pre-university students on this mailing list for example?) I wanted to forward the invitation at least. As the deadline to apply as a mentoring organization is 29 October there is not much time left to decide either. Boris

4 7

[interprocess] Documentation for containers is missing
by vicente.botet 27 Oct '10

27 Oct '10

Hi, the documentation for the containers is missing since 1.44. Ion, could you se what can be done? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

Review Request: Boost.Process
by Boris Schaeling 27 Oct '10

27 Oct '10

I would like to ask for a formal review of Boost.Process (draft version 0.4). * The source code can be found in the Boost Vault (search for process.zip or click on <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=proces…>). The source code can also be downloaded from <http://www.highscore.de/boost/gsoc2010/process.zip>. * The documentation can be found online at <http://www.highscore.de/boost/gsoc2010/>. If you wonder why the library looks like as it does today I recommend to read the thread at <http://thread.gmane.org/gmane.comp.lib.boost.devel/207594/> which was a kind of unofficial review. :-) Boris

5 8

[function] function wrapping and exception safety recap
by Daniel Walker 27 Oct '10

27 Oct '10

Hi all, While it's fresh on my mind, I just want to recap the previous discussion and to make sure this is brought to Doug's attention. http://thread.gmane.org/gmane.comp.lib.boost.devel/209304 To summarize, there have been several complaints from users who don't use RTTI about boost::function's dependency on Boost.Exception. boost::function has a strong exception safety guarantee and uses boost::throw_exception to implement it. This affords users sophisticated options as to how exceptions are actually thrown (or not thrown in RTTI-free environments), since boost::throw_exception can be defined/customized by the user. This is a great feature for some, but others would prefer a function object wrapper that behaved more like a function pointer; i.e. no exception safety guarantee and no RTTI dependency. The following feature request and patch try to answer this demand by adding a new function object wrapper to the Boost.Function family of wrappers: boost::unsafe_function. boost::unsafe_function is simple to generate with only slight modification to the code that generates the existing boost::function/functionN family. https://svn.boost.org/trac/boost/ticket/4720 Some concerns have been raised regarding the efficiency of the NULL pointer check in boost::function's operator(), but I believe this is a side issue at best and possibly a case of premature optimization. In optimized object code, the overhead of the pointer check is so small that it is difficult to detect (from simple benchmarks with MSVC Release mode and gcc -02). Regardless, in circumstances where aggressive compiler optimization is unavailable, unsafe_function could be used to address this concern as well. (I measured a ~15% reduction in time with gcc -01, for example.) Of course, as Peter and Emil pointed out, one could eliminate the pointer check in boost::function if its default "empty" state actually wrapped a valid function, e.g. throw_bad_function_call(). This may be a good idea by itself, but again, this is tangential to the present feature request to provide a function object wrapper that is independent of boost::throw_exception and RTTI. Finally, there have been suggestions to alter boost::function's exception safety guarantee directly through either policies or constructor options. These solutions are functionally similar to unsafe_function, so preferences between them may be a matter of personal taste. Personally, I like having two distinct class templates for two orthogonal levels of exception safety. Also, I like that anytime I encounter an instance of boost::function, I know it has the same strong exception safety guarantee it has always had, without having to wonder how it was instantiated or constructed. So, in this case, my preference is to expand the Boost.Function family of function object wrappers, rather than alter boost::function itself. Daniel Walker

7 22

[Backtrace] Any interest in portable stack trace?
by Artyom 26 Oct '10

26 Oct '10

Hello, Is there any interest in getting portable stack trace to boost - get something similar to Java's printStackTrace. Basics: 1. Getting stack trace of return pointers 2. Converting this pointers to human readable trace Extras: 1. Create exception classes that capture stack trace on throw (only pointers) 2. Print a trace on catch Supported Platforms: Linux, Mac OS X, Solaris and Windows >= XP using MSVC. Tested on: Linux x86_64, GCC, Linux x86, GCC Linux x86_64, Intel Windows XP 32bit, MSVC 2008 How implemented: Linux/Mac/Solaris with GCC: Capture trace using backtrace Convert trace using dladdr + with demangling Requires: compilation with -rdynamic for fetching symbols Linux/Mac/Solaris with Other compilers: Capture trace using backtrace Convert trace using backtrace_symbols (no demangling) Requires: compilation with -rdynamic for fetching symbols Windows/MSVC Capture trace using RtlCaptureStackBackTrace (XP and Above) Convert trace using dbghelp.lib using SymFromAddr Requires: debug info (PDB files) for fetching symbols All other: Create an empty trace For example: #include <boost/backtrace.hpp> #include <iostream> int foo() { throw boost::runtime_error("My Error"); return 10; } int bar() { return foo()+20; } int main() { try { std::cout << bar() << std::endl; } catch(std::exception const &e) { std::cerr << e.what() << std::endl; std::cerr << boost::trace(e); } } Prints: My Error 0x403fe1: boost::stack_trace::trace(void**, int) + 0x1b in ./test_backtrace 0x405451: boost::backtrace::backtrace(unsigned long) + 0x65 in ./test_backtrace 0x4054d2: boost::runtime_error::runtime_error(std::string const&) + 0x32 in ./test_backtrace 0x40417e: foo() + 0x44 in ./test_backtrace 0x40425c: bar() + 0x9 in ./test_backtrace 0x404271: main + 0x10 in ./test_backtrace 0x7fd612ecd1a6: __libc_start_main + 0xe6 in /lib/libc.so.6 0x403b39: __gxx_personality_v0 + 0x99 in ./test_backtrace Initial Source Code: http://art-blog.no-ip.info/files/backtrace.tar.gz Any interest? Artyom

14 27

Report # 29 (aka 1.45 blockers) is too narrow
by Jim Bell 26 Oct '10

26 Oct '10

I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months. A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that. I think they all need review.

8 15

Seek within a file stream using large offsets - reactivation
by Mateusz Loskot 26 Oct '10

26 Oct '10

Hi, I need to solve problem with seeking streams for large files. The problem leaks on Windows 32 and 64 bit, but the solution I'm looking for needs to be portable to Unix too. I have discussed this issue on #boost IRC and it looks Boost.IOStreams does not provide any cure for it. I've just found this problem was discussed 5 years ago. http://lists.boost.org/Archives/boost/2005/03/83087.php with some interesting suggestions: http://lists.boost.org/Archives/boost/2005/03/83140.php I'm wondering, has been there any motion on any level, Boost or C++ standard, to solve it? I'm looking for recommendation of any solution that would be sensible for this problem. (I can't ask my clients to move to STLport :-)) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Re: [boost] [Backtrace] Any interest in portable stack trace?
by Brian Wood 26 Oct '10

26 Oct '10

On Oct 20, 2010, at 3:47 PM, Artyom wrote: > > > Initial Source Code: > > http://art-blog.no-ip.info/files/backtrace.tar.gz > > > Any interest? I'm not able to access that link so far today. I'm getting a server not found error. Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Phoenix as a Boost library
by Edward Diener 26 Oct '10

26 Oct '10

I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ? I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.

9 31

[Boost.Serialization] Detecting if Boost.Serialization is supported for a type
by Ioannis Papadopoulos 25 Oct '10

25 Oct '10

Hi, I have two methods of serialization and I would like to choose between them. One is Boost.Serialization and the other is my hand-made one. Is there any (relatively) portable way that can allow to find out if Boost.Serialization is supported either through the intrusive or the non-intrusive way without requiring from the user to add more in her class to define the serialization method? Thanks

2 4

Interface for configuring third-party dependencies
by Vladimir Prus 24 Oct '10

24 Oct '10

Boosters, it seems that increasing number of upcoming libraries want to depend on third- party dependencies (Locale and GIL.IO being examples) and it would be nice to agree beforehand on an interface that is acceptable to everybody. This email attempts to suggest such interface. = Configuring location of dependencies = In general, for each external dependencies Boost.Build should try to check if it's available without configuration -- that is, in locations normally searched by the compiler/linker. If that fails, user has two way to help the search process. First, it will be possible to specify environment variables (either in OS environment, or using Boost.Build -sVAR=VALUE command-line option). For example, given a name of external dependency of 'zlib', the used variables are: - ZLIB_INCLUDE_PATH - ZLIB_LIBRARY_PATH - ZLIB_LIBRARY_NAME - ZLIB_ROOT The first two specify where the headers ahd libraries are located. The third specifies how the library file itself is named (and has sensible defaults most of the times). ZLIB_ROOT is a shortcut to set both include path and library path to $root/include and $roo/lib respectively. This approach is fairly easy to use for one-off builds of Boost by users. Second, it will possible to specify external dependencies in user-config.jam, or any other configuration file. This approach is slightly more complicated, as one has to edit a config file, but retains configuration and permits to specify multiple configuration for an external dependency -- which is not possible using environment variables. Roughly, the syntax will be: using zlib : condition <target-os>windows : include-path whatever : library-path something-else ; The 'condition' parameter specifies when this declaration will be picked up. Other parameters mirror the environment variables above. = Controlling use of external dependencies = Sometimes, it might be desirable to disable use of external dependency even when it's available. To than end, for each external dependency a new feature should be provided, for example: use-zlib When a value of "off" is specified, zlib won't be used by any boost component. Also, for every specific library that uses an external dependency, a more specific feature will be defined, for example: iostream.use-zlib to control use of that dependency in specific library. Does anybody have comments on this? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

8 17

[interprocess][iostreams] trac#4234
by Domagoj Saric 23 Oct '10

23 Oct '10

As part of my work on GIL.IO2 (https://svn.boost.org/svn/boost/sandbox/gil/boost/gil/extension/io2/detail) I've somewhat improved/generalized the original 'proof of claim' code from the post mentioned in the ticket (https://svn.boost.org/trac/boost/ticket/4234) However, in the same process I've gone through the Interprocess implementation of memory mapped files and AFAICT the various platform specific distinctions seem unnecessary: - AFAIK the POSIX 'anonymous inheritable' shared memory functionality is also available on Win32 - kernel-life time shared memory emulation with memory mapped files on Windows is also unnecessary. It can be either provided directly by bypassing the Win32 APIs using the native NT API (I volunteer to help with the implementation or can do it from scratch by myself) or a new distinction can be made (that does not have anything platform specific in its interface) such that a user can choose between a handle/process life time (which I suppose would be enough most of the time, because what use is there for a client to map a shared memory region after the server has already terminated) or kernel life time shared memory regions (which would then be emulated on Win32)...AFAICT the only thing the Win32 API lacks for this is getting the size of the mapped region which could perhaps be emulated by passing the size at the begining of the mapped region... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 4

Anyone have access to Sun Studio 12 compiler?
by Marshall Clow 23 Oct '10

23 Oct '10

I have a bug report on that compiler (Sparc, Solaris 9) that I don't have any way to reproduce. Thanks! -- Marshall There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

3 5

Git mirror
by Vladimir Prus 23 Oct '10

23 Oct '10

It seems like there's a git repo that is supposed to mirror SVN, at: http://gitorious.org/boost/svn/commits/master But the last commit there is from Sep 15. Is this the way it should be? - Volodya

4 5

Re: [boost] [Boost.Serialization] Detecting if Boost.Serialization is supported for a type
by Ben Hendrickson 23 Oct '10

23 Oct '10

Loannis Papadopoulos wrote: > I successfully made a template supports_boost_serialization<T> that > detects if T::serialize() exists. > > However, I cannot address the case of a stand-alone serialize() function > - since there is a generic boost::serialization::serialize(Archive&, T&, > const unsigned int), there is not way (that I know of) to figure out if > non-intrusive serialization exists for a specific T. Another hard case is inherited serialize methods - consider class T inheriting from class B, and B::serialize() exists. Does your implementation of supports_boost_serialization<T> detect that? If it does, I am interested in how. Ben

2 2

need to get boost compiled so I can get Shareaza built
by Kevin Simonson 22 Oct '10

22 Oct '10

I'm trying to get the Shareaza source code to build in my local directory. When I try to build the only error I'm getting now is "Cannot open include file: 'boost/cstdint.hpp': No such file or directory". So it looks like I need to compile Boost. Some time back I went to the sourceForge "Developers.GettingStarted.Boost" page (I'd been referred there by a document that said I needed to compile Boost to be able to build Shareaza), and followed its instructions to the point of copying "bjam.exe" into my "boost_1_44_0\boost_1_44_0" directory, next to "boost.css". The next thing it said to do was to open "a command prompt window, and navigate it to the boost_1_33_1 folder where bjam.exe is located," and then paste "the text below onto the command line, and press Enter." The text in question was "{{{1}}}". I assumed that what this meant was to execute "bjam {{{1}}}". But when I actually did execute "bjam {{{1}}}" I got the messages: warning: No toolsets are configured. warning: Configuring default toolset "msvc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: could not find main target {{{1}}} notice: assuming it is a name of file to create. nBuilding the Boost C++ Libraries.nn warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. don't know how to make <e>{{{1}}} ...found 1 target... ...can't find 1 target... The docs said executing this command would cause a "C:\Boost" directory to be created, but one wasn't, so even if the error messages didn't look discouraging, it's pretty clear that I didn't accomplish what I needed to to get Shareaza compiled. And running the Shareaza build afterwards generated the complaint about "boost/cstdint.hpp" anyway. So my question is, what do I have to do to get Boost compiled, so that I can go on and build Shareaza? I'd appreciate any information you can give me. Kevin S

4 4

[1.45] Thread issues
by Bryce Lelbach 22 Oct '10

22 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 https://svn.boost.org/trac/boost/ticket/3847 https://svn.boost.org/trac/boost/ticket/3882 https://svn.boost.org/trac/boost/ticket/4614 https://svn.boost.org/trac/boost/ticket/4632 https://svn.boost.org/trac/boost/ticket/4258 https://svn.boost.org/trac/boost/ticket/4736 A few of these are related or similiar in nature. Long story short, Boost.Thread has some rather serious issues on mingw. One report indicates that statically linking Boost.Thread with VC8 and VC10 is broken. These are quite serious. The library maintainers have not responded to any of these tickets. The mingw problems are reproducible for me, the supposed VC problem appears to work for me. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzAlJEACgkQO/fqqIuE2t65YQCeNKpTO1+9IdAGleAPY+3XFIeC wIQAoImdTt1vpQjvxc0+hJ4jyQ9G9QaA =vck0 -----END PGP SIGNATURE-----

6 8

[fusion] tuple missing from sequence models?
by Mateusz Loskot 22 Oct '10

22 Oct '10

Hi, The boost::tuple seems to be missing (intentionally?) from the models of conforming to the forward sequence concept: http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/sequence/c… Though, the later chapter states it's adapted: http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/adapted.ht… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 2

[test] export bug or [graph] test mis-configured?
by Jim Bell 22 Oct '10

22 Oct '10

Boost.graph's stoer_wagner_test won't link on mingw32, with multiple definitions of various unit_test::test_case::... symbols. All symbols seem to be found in test/impl/unit_test_suite.ipp. Dynamic libraries for both boost_test_exec_monitor and boost_unit_test_framework are linked in. The compile has: -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 So is this graph test's compile or link wrong (but being forgiven on other platforms), or is test (notably unit_test_suite.ipp) not exporting symbols as it should (and that's being forgiven on other platforms)? The same problem (conceptually) is happening on msvc8, though it calls out more than just unit_test_suite.ipp.

1 0

[quickbook] Lists with paragraphs
by Edward Diener 21 Oct '10

21 Oct '10

Is there any way to specify a list with paragraphs embedded in each list item, such as a final result of: 1. Some data here. Some more data here. Maybe some code here. 2. Other data here More code here. In other words I can normally do this with lists by not separating lines which form individual paragraphs, but I want the spacing and paragraphs for each list item.

2 2

Unify multi_array and ublas matrix
by Gonsolo 21 Oct '10

21 Oct '10

Hi! Is there a plan to unify Boost's multi_arrays and ublas matrices? It seems to me those concepts are very similar. g

1 0

Re: [boost] [Backtrace] Any interest in portable stack trace?
by nimaca2001＠libero.it 21 Oct '10

21 Oct '10

> Linux, Solaris and Mac OS X have functions backtrace and backtrace_symbols > in libc: See: http://linux.die.net/man/3/backtrace > > Windows starting from XP has RtlCaptureBackTrace in kernel32.dll: > See http://msdn.microsoft.com/en-us/library/ff552119(VS.85).aspx > > So the rest is translate symbols, under Unixes I have dladdr and under Windows > dbghelp. How difficult would be a separate translation made with the map file instead of PDB file? (My main goal is to get the backtrace with raw addressed and traslate them 'at home' without spreading around rarely used stuff) Marco

1 0

Re: [boost] [1.45] Beta final schedule
by Jim Bell 20 Oct '10

20 Oct '10

>> > >> > Can we petition to hold up this release for some important bug fixes to >> > catch up to it? > This idea has some traction with me. ... > Ticket numbers? So far... https://svn.boost.org/trac/boost/ticket/4736 https://svn.boost.org/trac/boost/ticket/4698 https://svn.boost.org/trac/boost/ticket/4747 Less important, but would remove more yellow from the regression table... https://svn.boost.org/trac/boost/ticket/4735

7 9

svn.boost.org down?
by John Maddock 20 Oct '10

20 Oct '10

SVN seems to be working Ok, but something has taken Trac down, any ideas anyone? Cheers, John.

3 3

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] [1.45] Beta final schedule
by Jim Bell 20 Oct '10

20 Oct '10

> Message: 5 > Date: Tue, 19 Oct 2010 15:09:50 -0700 > From: Eric Niebler <eric(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [1.45] Beta final schedule > Message-ID: <4CBE172E.90602(a)boostpro.com> > Content-Type: text/plain; charset=ISO-8859-1 > >> > >> > So far... >> > >> > https://svn.boost.org/trac/boost/ticket/4736 >> > https://svn.boost.org/trac/boost/ticket/4698 >> > https://svn.boost.org/trac/boost/ticket/4747 >> > >> > Less important, but would remove more yellow from the regression table... >> > https://svn.boost.org/trac/boost/ticket/4735 > Can you comment on whether these are regressions from previous releases? 1.44 had the first three, which is what (eventually) led me to this list (and pitching in to fix them).

2 1

Re: [boost] Understanding the test matrix
by Jim Bell 20 Oct '10

20 Oct '10

> The release test matrix seems to be telling me that there are many failures > on different platforms, and in fact > that there is no platform with no failures on all libraries, or libraries > with no failures on all platforms. We just > live with that, is that right? > > Do all the failures get fixed before an actual release is made, or noted in > the release notes? I think the original philosophy was that it should work on mainstream, modern compilers/platforms, but not necessarily on your old/outlier, and here's a matrix of what's been tested. I'm okay with that. Also, a single unexpected regression failure marks the whole library as fail/yellow on the main matrix. And something like serialization not linking cascades to several other libraries showing failed (e.g., date_time on mingw32). It should be that way, but it shakes the casual observer's confidence in all of boost. All this to say, maximizing the green on that regression matrix is worth the work, and worth holding up a release, IMHO. Also, many fixes are not as simple as just looking at the test results for a compiler/platform you have little experience with and can't test first-hand. (E.g., Ticket # 4736 -- it's clear the author was looking for the failure, but the only thing that made progress was my running it in gdb on that particular platform.)

1 0

Understanding the test matrix
by Robert Jones 20 Oct '10

20 Oct '10

Following on from some recent posts I had a look at the development area on the site, and would appreciate some clarification that I'm understanding it correctly. Firstly, I'm assuming that releases are made from area summarised under "Development -> Testing -> Release Summary" and development is carried out on trunk, so the release area is supposed to stable-ish and trunk not particularly? Is it correct that in some areas there are substantial divergence between trunk and release, sometimes reaching far back in time? The release test matrix seems to be telling me that there are many failures on different platforms, and in fact that there is no platform with no failures on all libraries, or libraries with no failures on all platforms. We just live with that, is that right? Do all the failures get fixed before an actual release is made, or noted in the release notes? Thx - Rob.

1 0

[system] Undocumented deprecated throws variable
by vicente.botet 20 Oct '10

20 Oct '10

Hi Beman, The documentation doesn't states explicitly that the throws variable is deprecated (see section "Deprecated names"). In addition the section "Semantics of throws object" explaining how this variable should be used must be rewritten to show the usage of the function throws(). Could this be changed for 1.45? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 2

Re: [boost] [1.45] Beta final schedule
by Jim Bell 19 Oct '10

19 Oct '10

Can we petition to hold up this release for some important bug fixes to catch up to it? I think gcc-mingw-4.x is an important platform (Qt SDK for Win32 ships with it), and it needs a few key ones.

2 1

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

[regex] Regex does not build current release branch with GCC
by Jeremiah Willcock 19 Oct '10

19 Oct '10

I am using GCC 4.1.2 (toolset "gcc"), and the current release branch produces the error: Performing configuration checks - has_icu builds : yes /dev/shm/release/tools/build/v2/build/feature.jam:485: in validate-value-string from module feature error: "msvc:<linkflags>delayimp.lib" is not a known value of feature <toolset> error: legal values: "gcc" (then a long backtrace) Removing the delayimp.lib line from libs/regex/build/Jamfile.v2 works around the problem but probably would cause problems on VC++. -- Jeremiah Willcock

1 0

[1.45] Beta final schedule
by Beman Dawes 19 Oct '10

19 Oct '10

Major changes should already have been merged to trunk. Last minute bug fixes should be merged to trunk by the end of Monday, October 25th. The beta will go out as soon after that as most release branch tests have cycled, typically three or four days later. --Beman

2 1

Re: [boost] What's so cool about Boost.MPI?
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 19-10-2010 14:59, Mathias Gaunard skrev: > On 18/10/10 23:41, David Abrahams wrote: >> >> Just wanted to call some attention to this article I wrote about >> Boost.MPI: >> >> http://daveabrahams.com/2010/09/03/whats-so-cool-about-boost-mpi/ >> >> I think it might be useful to link that from the Boost.MPI docs, too. > > While the library seems nice (it bridges serialization with MPI), I > don't really see anything in there that makes me think it's "so cool". > > So after reading it, I felt a bit like the question "What's so cool > about Boost.MPI?" remained unanswered. The semi-automatic, but very easy to maintain, way of creating/maintaining the MPI type maps (via Boost.Serialization), IIUC. -Thorsten

3 2

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0

Re: [boost] [review result] mini-review of update to Boost.Assign
by Thorsten Ottosen 19 Oct '10

19 Oct '10

Den 18-10-2010 21:01, Mathias Gaunard skrev: > On 18/10/10 19:38, Thorsten Ottosen wrote: >> I would like to thank Erwann for his hard work so far, and hope he >> submits a Boost.Assign v2 in the near future. > > I have a possibly silly question: > > Does it use Boost.Proto? I don't suspect it, but only Erwan can answer that. -Thorsten

1 0

[filesystem] temp_dir_path()
by Jeff Flinn 19 Oct '10

19 Oct '10

The need for portably obtaining 'the' temporary-directory-path has been brought up a few times(but never addressed AFAICT), and I am now in the need for this as well. Windows has the GetTempPath, which follows a specific order of looking for a temporary directory path. If GetTempPath returns 0, GetLastError provides a system error. Posix relies on getEnv("TMPDIR"), which returns 0 if the environment variable does not exist. The following windows and posix implementation would be in the detail namespace: BOOST_FILESYSTEM_DECL path temp_dir_path(system::error_code* ec) { # ifdef BOOST_POSIX_API const char* val = getenv("TMPDIR"); return val? path(val) : path(); # else // Windows std::vector<Path::value_type> buf(GetTempPathW(0, NULL)); if(GetTempPathW(buf.size(), &buf[0])) return path(buf.begin(), buf.end()); int errval(::GetLastError()); if (ec) ec->assign(errval, system_category()); return path() # endif } Questions: - should Posix return an empty path or an error when empty? - should Windows provide a more 'temp-path' centric error? - should both verify the path exists? - if the path does not exist should one be created? Thanks, Jeff

7 26

Fw: Interlibrary version cchecking
by Robert Ramey 19 Oct '10

19 Oct '10

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:<hsdfuq$prj$1(a)dough.gmane.org>... > Turns out that the idea of a single boost library deployment has come up a > couple of times here at BoostCon 2010. While preparing my presentation I > considered the problem of what would happen if one installed one library > which depended on an newer version of a different library than the user > already had installed. I actually woke up in the middle of the night > imagining someone would ask about that during my talk. I puzzled about it > for some time and the day before I found a way to address it - in my own > mind at least. It also seems that it turns out that there are tools that > can also manage this. > > It's not that I don't trust tools but I wear a belt AND suspenders. So I > would like a method which guarentees that when I build one library, I don't > accidently include code from a prerequisite library which is a version so > old that things won't work. I would also like to know that I'm not > accidently running with a DLL built with an old version. > > Basically each library includes a file "manifest.hpp". This get's included > when any header get's includes (once at most due to include guards). This > includes a static assert that checks that the prequiste libraries are of > sufficiently recent version that a dependent library (or user application) > requires. There is also a manifest.cpp file included in the library which > checks any prequiste DLLS. This would be an exheedingly small overhead to > avoid what could be an incredibly large headache. > > I just verified that the code compiles so at this point it's only an idea. > But it seems that some kind of check like this is un-avoidable of one want's > to deploy libraries as needed rather than as a monolithic distribution. > > FYI - no one asked me about this problem at my presentation. Add one more > confirmation of Murphy's law. > > Robert Ramey > > >

5 8

[accu london] Steve Love talks on Interface Versioning in C++
by Mateusz Loskot 19 Oct '10

19 Oct '10

Folks, I hope I'm not spamming and perhaps there are people on the list who are based in London and would find this talk interesting: What: Steve Love talks on Interface Versioning in C++ When: 21 October 2010 at 6.30pm for 7:00pm http://accu.org/index.php/accu_branches/accu_london/accu_london_oct_2010 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Accelerating algorithms with SIMD - Segmented iterators and alternatives
by Mathias Gaunard 19 Oct '10

19 Oct '10

Hi, I have, along with Joel Falcou, been looking a bit at how we can integrate SIMD into iterator-based algorithms to accelerate them. Unfortunately, there are a couple of issues. The basic idea is to provide a range adaptor that adapts of range of PODs, where N consecutive PODs are stored contiguously, into a range of vectors (or "packs") of those PODs of size N. Therefore, instead of: std::vector<float> tab(20); float sum = boost::accumulate(tab, 0); we can write something like: std::vector< float, simd::allocator<float> > tab(20); float sum = simd::sum( boost::accumulate( simd::packed_range<4>(tab), simd::zero_ ) ); Which does the same but using SSE instructions, adding four floats at a time, and typically providing a 4x speed-up. This can be applied to have the same result for any binary operation which is commutative and associative (which unfortunately isn't the case of many operations, but can still be useful). Here, however, it works because 1) the memory is well aligned thanks to the use of our custom allocator and 2) the size, 20, is a multiple of the pack size, 4. We'd be interested in providing a mechanism where we could also support ranges of data aligned at an arbitrary address and of an arbitrary size. The SSE would only be used in the middle, the borders being handled element per element. A first solution consists in padding the beginning and the end with zeroes. Say you have 1 2 3 4 5 6 7 with only 3 being aligned well enough for SSE usage. so we'd turn that into | 0 0 1 2 | 3 4 5 6 | 7 0 0 0 |. However, it is very important that the code to deal with borders does not affect the efficiency of the code in the middle. This is not possible with the normal iterator/range design. Our data is clearly cut into three segments: the beginning that is not aligned, the data that is rightly aligned and sized, and the data at the end that is not big enough to fill a whole pack. Therefore, segmented iterators could provide us with a solution to do this efficiently; but so could other solutions as well. Wouldn't it be better to be able to use the mechanism so that you could deal with the borders in an element-per-element way while you could deal with the middle bit in a vector-per-vector way? With C++ iterators, you pull data, but if we could use an iteration paradigm where you push data instead, such as calling a function object for each element, we could call an overloaded function that would be able to accept both a single element and a pack. Such a solution would also provide the speed benefits of segmented iterators, and all high-level standard algorithms can be expressed with this iteration paradigm just as well as with iterators. I have already suggested such an alternative to segmented iterators (where I had a few misconceptions about segmented iterators, I thought they broke compatibility, but they don't, they still maintain the legacy non-segmented interface) there: <http://thread.gmane.org/gmane.comp.lib.boost.user/61636/focus=61647>, with an example of how you could use that to iterate over a binary tree there: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=genera…> Converting from those things to a pair of iterators is possible through the use of a coroutine, as demonstrated in the example. I would like to have feedback on the general idea of providing tools to use SIMD with iterators and related algorithms, and ideas about whether there is sufficient interest in the alternative to iterators for me to develop them. The intent would be to submit both the alternative to iterators and the SIMD helpers to Boost.

24 120

boost utf-8 code conversion facet has security problems
by Patrick Horgan 18 Oct '10

18 Oct '10

I've been meaning to mention this for some time. The boost utf-8 code conversion facet implements an early spec of utf-8 that allows up to 6 byte representations but current specs, and security issues suggest it should only support up to four. See http://en.wikipedia.org/wiki/UTF-8 and in particular the section on invalid byte sequences. It also has some stuff wrong, like do_length() is supposed to only tell you length of valid code sequences, but the boost implementation doesn't check for validity. This has long since been superseded by newer specs that allow only 1-4 byte representations. The issue is that the longer representations let you alias characters, so if someone is filtering out certain chars for security reasons, for sql or http requests, for example, someone can bypass the filter by using a different representation of a character, and inject their naughty stuff just when you think you've got them stopped. In addition to no more 5 and 6 byte utf-8 chars, there are some other first and second byte codes that are forbidden because they would alias other characters. Current specs, see std 63 (also currently rfc 3629), and The Unicode Standard Version 5.2, specify how to correctly implement the conversion. I think that everything you need to know, however, to implement do_in() and do_length() correctly is in this table (notice that start and end of valid second byte range varies in different unicode code ranges): /* Table 3-7. Well-Formed UTF-8 Byte Sequences from version 5.2 of the Unicode Standard Code Points First Byte Second Byte Third Byte Fourth Byte U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF */ So, you have to do more checking, but it's still efficient. I have test code that checks all this. I'm willing to help in various ways. o I have an implementation of the utf-8 code conversion facet that implements do_in, do_out, and do_length that I did. You can have the source to jump start the fix. o I'm willing to make changes to the boost one and contribute a patch with a little guidance. o I'm willing to just figure that now that I've pointed it out, someone who owns this code will be motivated to fix it, it's not too hard. o Also willing to give you the test code to check with. Probably a lot different than how boost implements test code. o Willing to give peace a chance;) It should really be fixed. There's a lot of bad guys out there that know about these sorts of problems, plus, there aren't many open source implementations of utf-8 code conversion facets, so folks are likely to emulate/steal this. btw mine's freely available to anyone who requests it. wc -l * 232 codecvt_utf8_facet.cpp 29 codecvt_utf8_facet.hpp 14 Makefile 510 testcodecvt.cpp Funny the test code is twice the size of the code. Patrick

5 9

Fwd: [String algo] Breaking change between 1.41 and 1.44 in split
by Christophe Henry 18 Oct '10

18 Oct '10

As I got no answer on the user list, I try again. Is the library still maintained? ---------- Forwarded message ---------- From: Christophe Henry <christophe.j.henry(a)googlemail.com> Date: 2010/10/13 Subject: [String algo] Breaking change between 1.41 and 1.44 in split To: boost-users(a)lists.boost.org Hi, I noticed a breaking change in the split function when the input string is empty. Consider the following example: #include <string> #include <vector> #include <iostream> #include <boost/algorithm/string/split.hpp> #include <boost/algorithm/string/classification.hpp> int main() { std::vector<std::string> result; std::string empty_string; boost::algorithm::split( result, empty_string,boost::algorithm::is_any_of( "\t" ),boost::algorithm::token_compress_off); std::cout << "result size: " << result.size() << std::endl; return 0; } With boost 1.41 I get: result_size: 1 With 1.44 I get: result_size: 0 Meaning that splitting an empty string now has a new meaning. All I found to this subject was that 1 seems to be the correct answer (http://lists.boost.org/Archives/boost/2005/07/90266.php) Furthermore, there has been, according to the release notes, no change to string algo since the 1.41. This brings me to the question, before I start updating my code, is this change a design decision or an accident? Thanks, Christophe

2 2