January 2011 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 6

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

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

03 Nov '11

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

6 13

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

04 Oct '11

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

4 7

[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

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

04 May '11

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

10 20

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

[MPL] Maintenance, patch applciation etc
by Joel Falcou 10 Mar '11

10 Mar '11

As a huge user of MPL all along, i'm a bit saddened by the speed of patching/evolution of the thingy. Currently there is 36 trac item on MPL and I remember a page with a ncie list of future work to go to. Instead of bitching around, i want to propose me as a "co-maintainer" or w/e the proper term is. I have a small amount of free time i want to dedicate to this. So here is the proposal ;)

6 9

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

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 23 Feb '11

23 Feb '11

Hello Ion, I also need this functionality badly. Is there any chance of you implementing it? Basically, using unsigned int instead of size_t and int instead of ptrdiff_t, so the binary layout of shared memory is always like in 32 bit, would in practice do the trick. If we implement it ourselves, would you support getting this into boost? I cannot promise complete support. I already saw that rbtree_best_fit has a problem because the ring list containing the memory blocks needs to wrap around from the last block to the first. Would porting Doug Lea's allocator be an option? It will be hard to beat something that has been so thoroughly used and improved. Cheers, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 7

Which libraries on the review schedule are ready for review?
by vicente.botet 21 Feb '11

21 Feb '11

Hi, I would like the authors of the libraries on the review schedule state clearly if his libraries are ready for review. Lexer Ben Hanson - Eric Niebler - Shifted Pointer Phil Bouchard - Needed - Logging John Torjo - Gennadiy Rozental - Join Yigong Liu - Needed - Pimpl Vladimir Batov - Needed - Task Oliver Kowalke - Vicente Botet - Endian Beman Dawes - Needed - Conversion Vicente Botet - Needed - Sorting Steven Ross - Needed - AutoBuffer Thorsten Ottosen - Robert Stewart - String Convert Vladimir Batov - Needed - Containers Ion Gaztañaga - Needed - Type Traits Extensions Frédéric Bron - Joel Falcou - Interthreads Vicente Botet - Needed - Bitfield Vicente Botet - Needed - Lockfree Tim Blechmann - Needed - Fiber Oliver Kowalke - Needed - Creasing (Sequence Properties) Grant Erickson - Needed - Static Size Linear Algebra Emil Dotchevski - Needed - Locale Artyom Beilis - Needed - XInt Chad Nelson - Needed - Context Oliver Kowalke - Needed - Stopwatches Vicente Botet - Anthony Williams - Please could you replay to this mail for each one of your libraries? Thanks, Vicente

13 36

[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

Distributed Boost with CMake: proposal and volunteering
by Daniel Pfeifer 21 Feb '11

21 Feb '11

Hi all, I would like to propose my approach to a modularized build of the Boost C++ Libraries with CMake. The project is found on http://github.com/purpleKarrot/Boost.CMake The following features are currently implemented: * Aggregate modules from different sources (CVS, SVN, GIT, tarballs, ...). * Build, Test, Install * Create a binary installer with selectable components for Windows. * Create a source package (with the modules included) that can do everything in this list (except the first entry). * Create a Debian source package that can be uploaded to a Launchpad PPA where it is built and packaged into many binary Debian packages. * Build Documentation (the usual quickbook-doxygen-boostbook-chain). * Tested on Windows (Visual Studio 10) and Ubuntu (GCC). * Precompiled headers (currently MSVC only). * Build two Boost.MPI libraries on Debian: boost_openmpi and boost_mpich2. * Tests actually make use of Boost's autolinking feature. This tool would allow the following Boost development process: * Each Boost library uses it's own repository (no matter which VCS) * Boost.CMake has a list of modules (or multiple list: eg 'boost' and 'incubating') * A modules definition consists of the information about where to get the source code from. * Boost.CMake can be used to aggregate all modules, run tests, build release packages... * Incubating libraries can be tested before they become an official part of boost. Please note that I am not proposing a development process. I am just proposing a tool. I am volunteering to extend and maintain the tool so that it can (help to) drive the development process. If you decide that all libraries should use git, I can drop the support for all other VCSs, no problem. Also, I am happy to implement other missing features. In the next couple of days I was going to write some documentation and a tutorial how to migrate the libraries to CMake. Cheers, Daniel

7 13

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

[config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
by Mostafa 14 Feb '11

14 Feb '11

Hi, I propose the introduction of BOOST_SYMBOL_IMPORT_VISIBLE to Boost.Config that behaves like BOOST_SYMBOL_IMPORT in all cases except gcc (and like compilers?) where it expands to "__attribute__((visibility("default")))". I believe this is need to address the following two scenarios: (For gcc, assume all libraries are built with the following option: -fvisibility=hidden) ********** Scenario 1 ********** Export class MyException from Library A. Catch MyException in Library B, and be able to throw or rethrow it from Library B. Catch MyException in Library C. To be able to do this with gcc, MyException has to be visible from Library B since the exception handler in Library C will look for the class definition of MyException in Library B [1]. I don't believe it's possible to do this "out of the box" with Boost.Config and still support gcc and msvc libs. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef MYLIB_BUILD #define MYLIB_API BOOST_SYMBOL_EXPORT #else #define MYLIB_API_BOOST_SYMBOL_IMPORT #endif class MYLIB_API MyException ... { ... }; //------------- //End Library A //------------- But this technique fails to make MyException visible from Library B with gcc. And where I to use BOOST_SYMBOL_VISIBLE instead, it would fail to export MyException from Library A with msvc. ********** Scenario 2 ********** Export class MyShape from Library A. Import class MyShape from Library A into Library B and have Library B export the following the function: MyShape & foo(); Import MyShape and foo into Library C, and Library C export the function: MyShape & bar(); To be able to do this with gcc, MyShape has to be visible from Library B and Library C [2]. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef LIB_A_BUILD #define LIB_A_API BOOST_SYMBOL_EXPORT #else #define LIB_A_API_BOOST_SYMBOL_IMPORT #endif class LIB_A_API MyShape ... { ... }; //--------------- //Start Library B //--------------- #ifdef LIB_B_BUILD #define LIB_B_API BOOST_SYMBOL_EXPORT #else #define LIB_B_API_BOOST_SYMBOL_IMPORT #endif LIB_B_API MyShape & foo(); //--------------- //Start Library C //--------------- #ifdef LIB_C_BUILD #define LIB_C_API BOOST_SYMBOL_EXPORT #else #define LIB_C_API_BOOST_SYMBOL_IMPORT #endif LIB_C_API MyShape & bar(); But this leads back to the same problem/proposed solution as Scenario 1. Thanks in advance, Mostafa [1] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 2nd Paragraph. [2] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 3rd Paragraph.

7 22

Problem with boost::random seed
by Anton Skvorts 10 Feb '11

10 Feb '11

Testing boost::random with the following code boost::mt19937 gener(1); boost::normal_distribution<> normal(0,1); boost::variate_generator<boost::mt19937 &,boost::normal_distribution<> > rng(gener, normal); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; gener.seed(2); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; I'm getting unexpected values after gener.seed(2) -2.971829031 1.706951063 -0.430498971 -2.282022417 x -0.5887503675 0.2504171986 The value -2.282022417 is the forth number in the sequence originated by gener(1) and not the first number in the sequence originated by gener.seed(2) as one would expect (this number is actually -0.5887503675). If I reseed next with gener.seed(3)it works fine, but if after that I reseed again with gener.seed(1) I'll get the same problem, and so on and off... How can I reseed the random number generator to overcome this problem? Thanks in advance

3 10

[general] What will string handling in C++ look like in the future [was Always treat ... ]
by Matus Chochlik 10 Feb '11

10 Feb '11

The string-encoding-related discussion boils down for me to the following: What fill the string handling in C++ look like in the (maybe not immediate) future. *Scenario A:* We will pick a widely-accepted char-based encoding that is able to handle all the writing scripts and alphabets that we can think of, has enough reserved space for future additions or is easily extensible and use that with std::strings which will become the one and only text string 'container' class. All the wstrings, wxString, Qstrings, utf8strings, etc. will be abandoned. All the APIs using ANSI or UCS-2 will be slowly phased out with the help of convenience classes like ansi_str_t and ucs2_t that will be made obsolete and finally dropped (after the transition). *Scenario B:* We will add yet another string class named utf8_t to the already crowded set named above. Then: library a: will stick to the ANSI encodings with std::strings It has worked in the past it will work in the future, right ? library b[oost]: will use utf8_t instead and provide the (seamles and straightforward) conversions between utf8_t and std::string and std::wstring. Some (many but not all) others will follow library c: will use std::strings with utf-8 ... library [.]n[et]: will use String class ... library q[t]: will use Qstrings .. library w[xWidgets]: will use wxStrings and wxChar* library wi[napi]: will use TCHAR* ... library z: will use const char* in an encoding agnostic way Now an application using libraries [a..z] will become the developers nightmare. What string should he use for the class members, constructor parameters, who to do when the conversions do not work so seamlesly ? Also half of the cpu time assigned to running that application will be wasted on useless string transcoding. And half of the memory will be occupied with useless transcoding-related code and data. *Scenario C:* This is basically the status quo; a mix of the above. A sad and unsatisfactory state of things. *Consequences of A:* - Interface breaking changes, which will require some fixing in the library client code and some work in the libraries themselves. These should be made as painless as possible with *temporary* utilities or convenience classes that would for example handle the transcoding from utf8 to UCS-2/UTF-16 in WINAPI and be no-ops on most POSIX systems. - Silent introduction of bugs for those who still use std::string for ANSI CP####. This is worse than above and will require some public-relations work on the part of Boost to make it clear that using std::strings with ANSI may be an error since Boost version x.y.z. - We should finally accept the notion that one byte, word, dword != one character and that there are code points and there are characters and both of them can have variable length encoding and devise tool to handle them as such conveniently. - Once we overcome the troubled period of transition everything will be just great. No headaches related to file encoding detection and transcoding. Think about what will happen after we accept IPV6 and drop IPV4. The process will be painful but after it is done, there will be no more NAT, and co. and the whole network infrastructure will be simplified. *Consequences of B:* - No fixing of existing interface which IMO means no or very slow moving on to a single encoding. - Creating another string class, which, let us face it, not everybody will accept even with the Boost influence unless it becomes standard. - We will abandon std::string and be stuck with utf8_t which I *personally* already dislike :) - People will probably start to use other programming languages (although this may by FUD) *Consequences of C:* Here pick all the negatives of the above :) *Note on the encoding to be used* The best candidate for the widely-accepted and extensible encoding vaguely mentioned above is IMO UTF-8. - It has been given a lot of thought - It is an already widely accepted standard - It is char-based so no need to switch to std::basic_string<whatever_char_t> - It is extensible, so once we have done the painful transition we will not have to do it again. Currently utf-8 uses 1-4 (or 1-6) byte sequences to encode code points, but the scheme is transparently extensible to 1-N bytes (unlike UCS-X and i'm not sure about UTF-16/32). So, [dark-sarcasm] even if we dig out the stargate or join the United Federation of Planets and captain Kirk, every time he returns home, brings a truckload of new writing scripts to support, UTF-8 will be able to handle it. just my 0.02 strips of gold pressed latinum :) [/dark-sarcasm] Best regards, Matus

23 117

[process] FileSystem version
by vicente.botet 09 Feb '11

09 Feb '11

Hi, with witch version of Boost.FileSystem Boost.Process is working, V2, V3 or both? Best, Vicente

3 4

[random] geometric_distribution backwards compatibility
by Steven Watanabe 05 Feb '11

05 Feb '11

AMDG Over the last year I've been (slowly) updating Boost.Random to match the new standard. Unfortunately I just hit a problem that I don't have a good solution for. In the standard, the geometric_distribution is defined as $p(i) = p(1-p)^{i}$, with i >= 0. In the current Boost.Random code it is $p(i) = (1-p) p^{i-1}$, with i >= 1. The definition in the standard makes more sense, but I don't want to introduce a breaking change. I can see two options here: * Leave the implementation alone and put a big warning in the documentation saying that the behavior doesn't match the standard. * Since I'm also moving things into namespace boost::random, I can use the new definition and leave a version with the old behavior in namespace boost instead of having a using declaration. I'd still have to add a warning that boost::geometric_distribution isn't the same as boost::random::geometric_distribution. Neither one is particularly appealing. Any thoughts? Better ideas? In Christ, Steven Watanabe

5 10

Process discussions
by Vladimir Prus 02 Feb '11

02 Feb '11

As of recent, we had quite a lot of discussion about process. In true open-source spirit, it was a fairly open discussion, with everybody offering their perspectives and experience. However, while we surely learned many things, it does not seem like we're going anywhere. For a quick experiment, I tried to assess whether the discussion actually reflects the needs of Boost developers, so I created a table of Boost developers sorted by the number of commits in 2010. It is here: http://tinyurl.com/5suwfbn It seems that 5 top Boost comitters did not participate much in recent discussions. And going down the list, it seems like many of active developers did not say anything, while most of discussions is fueled by folks who don't commit much. Of course, everybody can offer valuable thoughts, but if the goal is to fix things for Boost developers, it would make sense if developers say that needs fixing, as opposed to other people doing it for them. Maybe I suggest that for some time, we outright ban freeform discussion about process, and instead, we restrict them to threads started by a Boost developers and saying this: "I am maintainer of X, and had N commits and M trac changes in the last year. I most hate P1, P2 and P3. I would propose that we use T1, T2, and T3 to fix that". Then, everybody could join to suggest better way of fixing P1, P2 and P3 -- without making up other supposed problems. Thoughts? -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

18 53

Kernel-level threads
by Tibor Szaboky 02 Feb '11

02 Feb '11

Does Boost support Kernel-level threads?

3 2

Re: [boost] boost::interprocess boost::interprocess xsi_shared_memory
by Ion Gaztañaga 01 Feb '11

01 Feb '11

El 12/01/2011 19:48, Daniel Neuberger escribió: > Hi Ion, > > I saw that you made a commit for XSI shared memory (https:// > svn.boost.org/trac/boost/changeset/67451) Could you confirm whether > it is ready to use? We're using Boost 1.43; do you think applying > that changeset would be sufficient to be able to use XSI shared > memory? Yes, I think it will be enough. > Lastly, do you think these changes will make it into the > upcoming 1.46 release? Yes, I see tests are ok. It seems that in FreeBSD 64 we have some ENOSYS error ("function not implemented"), but there is not much we can do if the platform does not support it ;-) I will merge to release ASAP, please it would be nice if you could test these new XSI functions to get more feedback. Best, Ion

2 3

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 01 Feb '11

01 Feb '11

[[ whoops! I double tapped the send keyboard shortcut on a foreground message and sent this before I'd finished cleaning it up. Apologies for the near-double post. The last few paragraphs are different ]] I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. As a retired FreeBSD committer (and a boost-digest lurker since 1.33), I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, but the use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage A schedule and handoff of hats/responsibilities for each of the branches is pretty well documented and is now time driven (it used to be feature driven, which didn't work as well as they'd hoped): http://www.freebsd.org/releng/ The way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message, commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html The above has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html A 'Reviewed by' commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag otherwise the commit will fail. If someone commits with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. Unlike boost, FreeBSD uses an abridged commit message that doesn't include the actual diff itself (if you're a committer, then you see the diffs to areas of the tree that you subscribe to). I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list and the diffs can sometimes be massive, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Links to each of the diffs is useful and lets people click through if reviewing the diff is of interest. I can't stress the organizational difference and peer pressure a widely used commit mailing list brings about. There are other bits worth noting, acls apply to different parts of the tree (doc commit bits and a doc-re@ hat vs a src-re@ hat and even ports@), but the mailing list/commit reviews and branching/merging are the biggies that I wanted to point out. Branching trunk in to a boost_1_46_prerelease branch three weeks before the release (or some sane interval) so that people can fix up the code seems like a pretty painless adjustment, then snapping/releasing boost_1_46_0 when the pre-release is ready. Post-1.46 release fixes could go in to 1.46.0 and (heaven forbid), maybe even a micro version with specific fixes for the .46 minor version. PostgreSQL ships with a contrib/ directory of "soon to be" or "possible candidates for being a core component" which serves the same purpose as FreeBSD's ports structure. This gets yet-to-be finalized modules out in the wild and helps garner interest. PostgreSQL's autovacuum went from being a fringe project to a contrib/ module and a core feature in 2 minor releases because of the huge interest in its use/adoption. Boost.Log or Atomic or any of the other "we all really want this but it's not quite finalized" modules seem like ideal candidates for inclusion in such a directory because it could generate additional interest/eyes. A contrib/ or proposed/ would go a long way towards keeping boost lean-ish, too. At present it seems like boost-*.tar.bz2 is on track to including boost/kitchen/sink.hpp and boost/bath/water.hpp and that's something that is a bit concerning to me on the long-term scale. Me personally, I keep running 'svn ls http://svn.boost.org/svn/boost/branches/' to see if a branch pops up for release but I haven't yet. The structure on the server is largely there, but it the svn tree looks pretty disorganized with lots of legacy clutter so it doesn't look like it's being used well. And lastly re: VCSs, lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask on or offline (CC if online since I'm a digest subscriber). Cheers. -Sean -- Sean Chittenden sean(a)chittenden.org

12 46

Functors created by boost::bind and move semantic
by Marat Abrarov 01 Feb '11

01 Feb '11

Hi, Boost Users and/or Developers. Does anybody know why functional objects created by means of boost::bind have no move constructors? It would be rather useful especially when such functional objects consist of some smart pointers (like boost::shared_ptr). For example, move constructor of boost::shared_ptr is very light (comparing to its copy constructor) - it doesn't use any CAS at all (which is the main overhead of boost::shared_ptr). May be someone know the reason of move constructor absence or maybe someone know any plans of implementing it. Regards, Abrarov Marat.

2 1

Boost Modularization
by Robert Ramey 01 Feb '11

01 Feb '11

I believe that eventually we will want have feel the need to address some issues in directory structure, namespaces etc. However, I'm thinking that it's premature to do anything but set a few policies for new libraries and submissions. The only specific one that comes to mind is: a) libraries should not place any header files directly in the boost directory or in the boost namespace. The only exception would be a "convience header" in the boost directory which would include the headers in the library directory. b) The library name should be the same as the namespace name and the same as the subdirectory name in the boost directory. .... Robert Ramey

6 5

Re: [boost] [string] proposal
by Ivan Le Lann 01 Feb '11

01 Feb '11

----- "Patrick Horgan" <phorgan1(a)gmail.com> a écrit : > On 01/28/2011 09:59 AM, Dean Michael Berris wrote: > > On Fri, Jan 28, 2011 at 7:20 PM, Dean Michael Berris > > <mikhailberis(a)gmail.com> wrote: > >> So the interface I was thinking about (and suggesting) is a lot > more > >> minimal than what rope or std::string have exposed. I think when I > do > >> finish that design document (with rationale) it would be clear why > I > >> would like to keep it immutable and why I would prefer it still be > >> called a string. > >> > >> Let me finish that document -- expect something over the weekend. > :) > >> > > And I stopped before I write too much -- the initial version is > > already up: > https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > -- I'll give it more information and the actual interfaces and > > implementation as soon as I get some Z's. :) > > > You mention that your string is thread safe by design, but you only > solve the problem of mutating the data of a string, your references to > the pieces from which you compose a string are not thread safe, since > they are mutable, right? I don't think so. Isn't the easiest way towards proper composition to consider that the whole is the same as the part? I see the "chain" (I voted for that one!) as an immutable tree of immutable leafs. I think this can be naïvely seen as the following recursive boost::variant: boost::make_recursive_variant < boost::shared_ptr <const std::basic_string <code_unit_type>>, boost::shared_ptr <const std::list <boost::recursive_variant_>> >::type Ivan

3 3

One thing at a time: let's move to Git
by Mathias Gaunard 01 Feb '11

01 Feb '11

Many people wish for Boost to move from svn to git. Other people are fine with svn, but are not opposed to a change to git. So how about we just make it happen? Clearly Ryppl is trying to do too many things at once (modularize Boost, change the build system, the testing system, etc.). I offer we take one step at a time: let's simply move from svn to git, and not do anything else. I think there is already a non-modularized version of Boost on git somewhere. What else needs to be done? Do we just need to set up a scheme to transfer over all accounts and that's it?

8 9

How to specify return policy for object returned as part of a tuple in boost python
by Eddie C. 31 Jan '11

31 Jan '11

Hi all, I have a function that creates a C++ object. Before the refactor, I was returning a pointer from the C++ function, and in the boost python wrapper declaration, I would use boost::python::return_value_policy<boost::python::manage_new_object>. Now I need to return not only just the object, but also some error messages, and the refactor basically changes the C++ function to let it return a tuple: boost::python::tuple create_object_from_description(std::string& description) { ... return boost::python::make_tuple(myObject, errmsg); } How should I specify the return policy with this change? Thanks, Eddie

1 0

[1.46.0 beta 1] Release 1.46.0 beta 1 available
by Beman Dawes 31 Jan '11

31 Jan '11

Boost release 1.46.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains one new library, Interval Containers, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_46_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

9 13

[Boost Graph Library] larger neighborhood in grid_graph
by Hannes Schulz 31 Jan '11

31 Jan '11

Hi all, i recently discovered grid_graph and found it quite useful so far. However, I would prefer a larger neighborhood in the graph (e.g. 8 instead of 4 for 2D; 26 instead of 6 in 3D). I already started looking into copying and modifying grid_graph.hpp accordingly, but cannot entirely anticipate the complexity of the problem. Therefore I decided to ask here first: - Why did the developers restrict grid_graph to "orthogonal" neighborhoods? - Is a modification of grid_graph worth it, or am I going to throw away everything anyway and should start over anew instead? (without the wrapping overhead, which I do not need) Thank you very much! Hannes

2 1

Git vs SVN - review
by Robert Ramey 31 Jan '11

31 Jan '11

Here's my take on Git vs SVN All VCS systems are an extra layer of hassle. Once I learn enough about them to do the job, I'm happy to forget about them. I'm mostly happy with SVN. I only commit/update occasionally. Most of my time on boost is spent testing on my own machine with windows VC and gcc. I love the windows interface - it's great for someone with my attitude about this. I hate the merging process - it's slow and cumbersome and wastes a lot of my time - when I do it which is only once every three months. So - I don't really have strong feelings about this topic and I'm happy to go along with what ever is decided. I'm just hoping that those who make the decision take into account those of use who are VCS luddites. Robert Ramey

6 9

Testing procedure
by Robert Ramey 31 Jan '11

31 Jan '11

John Maddock wrote: > * I think we could organize the testing more efficiently for faster > turnaround and better integration testing, and much to my surprise I'm > coming round to Robert Ramey's suggestion that we reorganize testing > on a library-by-library basis, with each library tested against the > current release/stable branch. +1 of course, > * I think the release branch is closed for stabilization for too > long, and that beta's are too short. I would hope that implementing the above would make this a non-issue. > Here's a concrete suggestion for how the testing workflow might work: > > * Test machine pulls changes for lib X from version control (whatever > tool that is). > * Iff there are changes (either to lib X or to release), only then > run the tests for that library against current release branch. > * The testers machine builds it's own test results pages - ideally > these should go into some form of version control as well so we can > roll back and see what broke when. > * When a tester first starts testing they would add a short > meta-description to a script, and run the script to generate the test > results index pages. ie there would be no need for a separate machine > collecting and > processing the results. > * The test script should run much of the above in parallel if > requested. > The aim would be to speed processing of testing by reducing the cycle > time (most libraries most of the time don't need re-testing). > +1 to all of the above. Robert Ramey

2 2

[GSoC] Conservancy encourages member projects to apply for 2011
by Dave Abrahams 31 Jan '11

31 Jan '11

This message is forwarded from our umbrella nonprofit, the Software Conservancy:

1 0

[bind] class template 'value' can corrupt compilability of sound code: Ticket #5141
by Joachim Faulhaber 31 Jan '11

31 Jan '11

Hi Peter, list, two days ago I encountered the following situation For a new project I combined some code like: #include <boost/my_lib/my_robust_portable_code.hpp> with some other code #include <boost/malicious/side_effect_code.hpp> #include <boost/my_lib/my_robust_portable_code.hpp> with the effect, that 'my_robust_portable_code.hpp' did not compile anymore. Although I found a fix, applicable to 'my_robust_portable_code.hpp', I think that such a <boost/malicious/side_effect_code.hpp> should generally not be acceptable for independent components of boost. In the concrete case <boost/tread.hpp> has this malicious potential to confuse msvc-[8..10] when it preceded some of my boost/icl code. <boost/tread.hpp> has the potential to break the code of any other boost library and any user code, if those accidentally use certain legal expressions. As the example below shows the corrupted code is not extremely nuts and might occur else were. Fortunately I was able to locate the problem: It's at boost/bind/bind.hpp(112): namespace _bi{ ... template<class T> class value { ... }; ... } //namespace _bi This is a minimal program to demonstrate how 'class value' can confuse msvc: //========================================================= #include <boost/config.hpp> //--- from boost/bind/bind.hpp(112) namespace _bi{ template<class T> class value{}; } //--- affected code --------------------------------------- template <class Type> struct some_attribute { BOOST_STATIC_CONSTANT(int, value = 0); }; template <class Type> struct some_predicate { BOOST_STATIC_CONSTANT(bool, value = ( some_attribute<Type>::value < 0) //error C2059: syntax error : ')' //IF class template value defined before ); }; //========================================================= Although I frankly don't know, how exactly msvc is derailed, it seems to have problems with 'value' in some_attribute<Type>::value < 0 a construction that is extremely frequent due to meta programming conventions introduced by Dave's and Aleksey's boost::mpl. So for a fix I tried to rename 'class value' by something else like 'class _value'. Fortunately this is possible, because the class template is a local implementation object used in boost/bind/bind.hpp only. After renaming, I successfully ran all tests from boost/bind. Find the patch file attached. I have also filed a ticket https://svn.boost.org/trac/boost/ticket/5141 Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 9

Interest in a simple buffer abstraction?
by Boris Kolpackov 31 Jan '11

31 Jan '11

Hi, While working on the Boost profile for ODB C++ ORM[1], I was looking for a Boost type to map the database BLOB type to. I hoped to find something that would encapsulate the memory management and provide basic operations like copy (memcpy), append, set all bytes in a buffer to a specific value (memset), etc. Something that I could use like this: class packet { address to_; boost::buffer payload_; public: packet (const address& to, const void* data, std::size_t size) to_ (to), data_ (data, size) { } const boost::buffer& payload () const { return payload_; } }; class socket { public: void send (const packet& p) { ... s_.send (p.payload ().data (), p.payload ().size ()) } }; I found a number of buffer types in asio (asio/buffer.hpp) but they don't do memory management. I also found auto_buffer in implementation details of signal2 (signal2/detail/auto_buffer.hxx) and buffer in implementation details of iostream (iostream/detail/buffer.hxx). But they appear to be purpose-built for the libraries in question. So, unless I missed something obvious, I would like to propose a simple buffer abstraction for inclusion into Boost. Here are some additional motivations: - Seeing that there is a number of library-specific implementations, it is quite clear that such a class is often needed. - If we have a "top-level" buffer class, various i/o libraries could use it in their interfaces which would lead to better library interoperability (i.e., one could receive data from a socket into a buffer using asio and then pass that buffer to iostream or interprocess without any conversions). - A top-level buffer class will be fairly light-weight (perhaps even header-only). Right now, if I am to use a buffer implementation from say, asio, I need to install and potentially link to that library. If the community believes this is a good idea, I will next send the buffer interface for review/discussion. Let me know what you think. [1] http://www.codesynthesis.com/products/odb/ Boris

7 29

Process discussions
by Christophe Henry 31 Jan '11

31 Jan '11

> As of recent, we had quite a lot of discussion about process. In true > open-source spirit, it was a fairly open discussion, with everybody > offering their perspectives and experience. However, while we surely > learned many things, it does not seem like we're going anywhere. > > For a quick experiment, I tried to assess whether the discussion actually > reflects the needs of Boost developers, so I created a table of Boost > developers sorted by the number of commits in 2010. It is here: > > http://tinyurl.com/5suwfbn > > It seems that 5 top Boost comitters did not participate much in recent > discussions. And going down the list, it seems like many of active developers > did not say anything, while most of discussions is fueled by folks who > don't commit much. > > Of course, everybody can offer valuable thoughts, but if the goal is to fix > things for Boost developers, it would make sense if developers say that needs > fixing, as opposed to other people doing it for them. > > Maybe I suggest that for some time, we outright ban freeform discussion about > process, and instead, we restrict them to threads started by a Boost developers > and saying this: "I am maintainer of X, and had N commits and M trac changes > in the last year. I most hate P1, P2 and P3. I would propose that we use T1, > T2, and T3 to fix that". Then, everybody could join to suggest better > way of fixing P1, P2 and P3 -- without making up other supposed problems. > > Thoughts? *sigh* I usually try to stay out of this kind of discussions like svn vs git for 3 reasons: - I very fast stop following what it is about as it goes into depth without explanations. Actually I have the feeling it is more about "being right" than explaining for dolts like me. - I have no problem with svn - I have no time. Really. I don't. But it seems I have to say my word to avoid being faced with a matter decided without me. So my situation is simple. I have no time (I might have mentioned that already ;-) ). And the time I have is costly because any distraction goes at the cost of MSM. I use all my free time to code or imagine cool new features I can add. So either someone can make me get what I'd gain by investing time in switching to git (I repeat, I have no problem with svn, it does what I need with little cost) or for all practical matters, count me against switching. Right now, all I do is commit my development changes into the trunk, then once every 3 months start a long merge operation (which I do in the background, so no cost). How simpler than that can it be? If all I gain is avoiding getting all of boost on my (big) hard disk, then I will happily prefer paying the 1$ / 10GB and keep the time, thanks.

3 3

template-defined regexp proposal
by Vit Stepanek 31 Jan '11

31 Jan '11

Hi, I've implemented the basic regexp functionality using few simple template classes. Any regexp can be created by inserting the template classes one into another in the required order. Although it's in the design state, I'd like to find out if there's any interest in providing this functionality. Let me present you some short introduction to the topic. Some basic classes include - String Match (full string matching) - Is-in Match (matches any character in the list) - Or Match - Quantity and so on. These are the "building blocks" of the regexp. Each class does a very little bit but when combined in the specific order, you gain a clearly defined string matching algorithm of any kind and any complexity. In addition, it's quite simple to add any missing functionality. You just need to define you're desired algorithm and mix it with the others. I add few examples that should describe how's it all done. Regexp: ^[a-z]+ is implemented as: Quantity< Range< char_a, char_z >, 1 > re; (sorry if you don't like the indentation, but that's just to ease the reading) Regexp: ^0(x|X)[a-fA-F0-9]+ (matching the hexadecimal number) The required strings are hardcoded using macro "STRHOLDER", which generates a simple struct containing the given string (to avoid the need of pushing strings in the runtime and thus splitting the matching logic into two levels). STRHOLDER( 0, "0" ); STRHOLDER( xX, "xX" ); MultiTie< StrMatch< StringHolder_0 >, IsIn< StringHolder_xX >, Quantity< OrMatch< DigitChar, OrMatch< Range< char_a, char_f >, Range< char_A, char_F > > >, 1 > > re; The "MultiTie" ties the match parts to the consecutive sequence. Some other examples I tested include - email address regexp - quoted string matching (containing escaped quoting chars) Currently the implementation counts 21 template classes, which are enough to implement (I hope) almost any regular expression. Each "brick" is called using operator ()(). That allows to pass it as an argument to the standard algorithms (like std::replace_if etc). I've already implemented the availability to push parameters to the regexp in the runtime (but that's not the major feature). Some rationale for the defense: String matching is widely applied part of the coding. Often it's also one of the problematic domains (especially when using self-implemented matching functions without any general solution). Once it's done, it can be hard to change it, because all what can be seen is HOW is the match done, but not WHAT does it do. Even when using some higher-level methods, it still isn't self-descriptive. Template-defined regexp provides one solution for this issue by hiding the HOW under the mask of WHAT, and taking the advantage of compile-time check. Only to mention that - the performance is not touched by any kind of interpreting - everything is prepared after compilation (but I don't want to touch anybody's baby here!). Please don't look at: - the proposed name "template-defined regexp", I use it as the temp. name - the naming of the classes - implementation details (yes, they aren't here, because it's not necessary for now) - term "regexp" - I'm not sure if this can be called so... Your opinions are welcomed! Vit Stepanek ------------

3 7

[date_time] Active Maintainer? Patches on Trac, Cleaned-up, and Tested.
by Dean Michael Berris 31 Jan '11

31 Jan '11

I don't know where to look for this kind of information -- anybody maintaining Boost.Date_Time now? There are a few patches that have been languishing which might be good to look at and/or apply to trunk: https://svn.boost.org/trac/boost/ticket/1574 https://svn.boost.org/trac/boost/ticket/1674 https://svn.boost.org/trac/boost/ticket/1726 I've verified these locally to not cause any regressions with GCC 4.5 on Ubuntu 10.10 64-bit Linux locally. /me doesn't have commit powers on trunk (yet); maybe someone can apply? TIA, HTH -- Dean Michael Berris about.me/deanberris

1 0

Immutable data structure survey results
by Gregory Crosswhite 31 Jan '11

31 Jan '11

Hey everyone, Here are the results of the survey that I ran for the name of a potential immutable byte sequence data structure; each line contains the name that was entered and the number of times that it appeared: chain: 9 boost::text: 3 sequence: 2 string: 2 atomic_buffer: 1 blob: 1 buffer: 1 bytes: 1 chord (from the Latin chorda meaning string): 1 const_buf: 1 const_string: 1 data_block: 1 fixed_sequence<char>: 1 frame: 1 immutable::string: 1 immutable_sequence: 1 imstring: 1 rod: 1 rope: 1 sequence<char>: 1 strand: 1 tier: 1 whole_buffer: 1 wire: 1 yarn: 1 TOTAL: 37 To be transparent, I have also attached the script that I used to generate the above, which includes the raw results pasted inside a multi-line string. (Yes Artyom I included your vote in the tally.) I apologize for any problems you might have had with this service. I considered using another free service online which would be better suited for this purpose, but I wasn't sure of how many responses there would be and most services put a cap on 100 responses for their free services, whereas the service I have access to through my university has no such restriction. Since the actual number of responses was less than half of 100 I will know for future reference that one of the other free services should work just fine for this purpose. Thanks to everyone who responded! Cheers, Greg

3 2

[1.46.0 beta 1] Release candidate files available
by Beman Dawes 31 Jan '11

31 Jan '11

Release candidate files for the 1.44.0 beta are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

6 7

[string] Realistic API proposal
by Artyom 31 Jan '11

31 Jan '11

Hello All, I'd like to provide a realistic string API proposal: 1. It is Unicode aware extension of std::string 2. It is fully compatible with std::string giving an ability to be included in C++XYZ 3. It can be implemented today! Basically it extends std::string with a) const_code_point_iterator - for iterating over string - bidirectional b) code_point_iterator - back inserter c) provides Unicode and Locale functionality: - normalization - case handling - comparison - search d) marks non const operator[],at() as deprecated Advantages: ----------- 1. It can be implemented easily (when boost.locale is given) 2. It **is** compatible replacement of std::string 3. It allows to use std::string meanwhile under the hood as storage giving high efficiency when assigning boost::string to std::string when the implementation is COW (almost all implementations with exception of MSVC) 4. It is full unicode aware 5. It pushes "UTF-8" idea to standard C++ 6. You don't pay for what you do not need. Proposed API: ------------- namespace boost { // Fully bidirectional iterator template<typename UnitsIterator> class const_code_point_iterator { public: const_code_point_iterator(UnitsIterator begin,UnitsIterator end); // begin const_code_point_iterator(UnitsIterator begin,UnitsIterator end,UnitsIterator location); // current pos const_code_point_iterator(); // end #ifdef C++0x typedef char32_t const_code_point_type; #else typedef unsigned const_code_point_type; #endif const_code_point_type operator*() const; ... }; /// Output iterator template<typename BackInserter> class code_point_iterator { public: code_point_iterator(BackInserter out); // begin code_point_iterator(); // end #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif code_point_type operator*() const; ... }; template<typename Char,typename Traits=std::char_traits<Char>, typename Alloc=std::allocator<Char> > class basic_string { public: // { boost specific typedef std::basic_string<Char,Traits,Alloc> std_string_type; // } boost specific // All std::string standard functions based // Deprecated interfaces that exist for backward compatibility // as they not Unicode aware value_type &at(size_type indx); value_type &operator[](size_type indx); iterator begin(); iterator end(); // { boost specific compatibility functions with std::string, they would go // as std::string becode extended with boost::string new interfaces // basic_string(std_string_type const &other) : data_(other) {} basic_string(std_string_type const &other,size_type index,size_type len) : data_(other,index,len) {} ... operator std_string_type() const { return data_; } // } boost specific compatibility functions // // Unicode Support // // ------------------------ // // // UTF Codepoint iteration // #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif typedef boost::const_code_point_iterator<const_iterator> const_code_point_iterator; const_code_point_iterator code_point_begin() const { return const_code_point_iterator(begin(),end()); } const_code_point_iterator code_point_end() const { return const_code_point_iterator(begin(),end(),end()); } typedef boost::code_point_iterator<std::back_inserter<basic_string> > code_point_iterator; code_point_iterator back_inserter() { return code_point_iterator(std::back_inserter<basic_string>(*this)); } basic_string &operator+=(code_point_type code_point); basic_string operator+(code_point_type code_point) const; void append(code_point_type code_point); // // Lexical operations on string // // Case handling basic_string upper_case(std::locale const &l=std::locale()) const; basic_string lower_case(std::locale const &l=std::locale()) const; basic_string title_case(std::locale const &l=std::locale()) const; basic_string fold_case() const; // locale independent // Unicode normalization typedef enum { nfc, nfkc, nfd, nfkd } normalization_mode; basic_string normalize(normalization_mode mode = nfc) const; // normalized string constructor basic_string(basic_string const &,normalization_mode mode); basic_string(Char const *,normalization_mode mode); basic_string(Char const *,size_t n,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,normalization_mode mode); void append_normalized(basic_string const &other,normalization_mode mode = nfc); void append_normalized(Char const *,normalization_mode mode = nfc); void append_normalized(Char const *,size_t n,normalization_mode mode = nfc); basic_string concat_normalized(basic_string const &other,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,size_t n,normalization_mode mode = nfc) const; // Unicode validation bool valid_utf() const; typedef struct validate_utf{}; // Unicode validation tag // Create string validating it basic_string(basic_string const &,validate_utf const &); basic_string(Char const *,validate_utf const &); basic_string(Char const *,size_t n,validate_utf const &); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &); // Create string validating and normalazing it basic_string(basic_string const &,validate_utf const &,normalization_mode mode); basic_string(Char const *,validate_utf const &,normalization_mode mode); basic_string(Char const *,size_t n,validate_utf const &,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &,normalization_mode mode); // Search and comparison typedef enum { primary = 0, ///< 1st collation level: base letters secondary = 1, ///< 2nd collation level: letters and accents tertiary = 2, ///< 3rd collation level: letters, accents and case quaternary = 3, ///< 4th collation level: letters, accents, case and punctuation identical = 4 ///< identical collation level: include code-point comparison } level_type; // // search(...) return pair of index and size as string you search for may have different size // std::pair<size_type,size_type> search(basic_string const &other) const; std::pair<size_type,size_type> search(basic_string const &other,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,std::locale const &l) const ; std::pair<size_type,size_type> search(basic_string const &other,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *) const; std::pair<size_type,size_type> search(Char const *,level_type level) const; std::pair<size_type,size_type> search(Char const *,std::locale const &l) const ; std::pair<size_type,size_type> search(Char const *,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level) const; std::pair<size_type,size_type> search(Char const *,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(basic_string const &other) const; int compare_to(basic_string const &other,level_type level) const; int compare_to(basic_string const &other,std::locale const &l) const ; int compare_to(basic_string const &other,level_type level,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other) const; int compare_to(size_t index,size_t size,basic_string const &other,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,std::locale const &l) const ; int compare_to(size_t index,size_t size,basic_string const &other,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(Char const *) const; int compare_to(Char const *,level_type level) const; int compare_to(Char const *,std::locale const &l) const ; int compare_to(Char const *,level_type level,std::locale const &l) const; int compare_to(Char const *,size_t size) const; int compare_to(Char const *,size_t size,level_type level) const; int compare_to(Char const *,size_t size,std::locale const &l) const; int compare_to(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *) const; int compare_to(size_t size,Char const *,level_type level) const; int compare_to(size_t size,Char const *,std::locale const &l) const ; int compare_to(size_t size,Char const *,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size) const; int compare_to(size_t size,Char const *,size_t size,level_type level) const; int compare_to(size_t size,Char const *,size_t size,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size,level_type level,std::locale const &l) const; // UTF validation bool is_valid_utf() const; private: std_string_type data_; }; } // boost

4 8

Re: [boost] [1.46.0 beta 1] Release candidate files available
by Cromwell Enage 30 Jan '11

30 Jan '11

When running "bjam --toolset=gcc stage" on the command line, I get the following message: tools/build/v2/build/configure.jam:145: in builds-raw *** argument error * rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? ) * called with: ( <pbin.v2/libs/regex/build/gcc-4.2.1/debug>has_icu : : ignore-minus-n : ignore-minus-q ) * extra argument ignore-minus-q (builtin):see definition of rule 'UPDATE_NOW' being called It's the same error that's been preventing me from building auto-index. Cromwell D. Enage

3 4

Boost-1.46.0-beta1 fails to build in tools/regression/
by Philipp Reh 30 Jan '11

30 Jan '11

tools/regression expects boost::filesystem to be version 2 but version 3 is now the default. The attached patch fixed the build for me.

1 0

Re: [boost] RE process (prospective from a retired FreeBSD committer)...
by Brian Wood 30 Jan '11

30 Jan '11

Dave Abrahams wrote: >At Sun, 30 Jan 2011 16:43:17 +0300, > Vladimir Prus wrote: > > >> whereas most of the core (which is half-zillion times bigger than >> Boost), lives in two modules, which contain wildly different >> functionality, are updated by multiple people, and then built and >> used and tested by users all the time. So, this proves that Boost >> has a lot of grows ahead before having all code in place place will >> becomes, even in theory, a problem. > > The problem isn't where the code is located, it's: > > a. how much coordination is required to get things done > > b. the mental drag of having to deal with all the parts of Boost that > simply aren't relevant to you. > I've recommended to "chew the meat and spit the bones," when it comes to Boost since at least 2007. This approach sounds like it will make it easier to produce a tasty Boost according to one's understanding. So I'm in favor of it, though I rather expect achieving it will be difficult. This *less taxing* approach (in terms of hard drives, download times, ...) will be a breath of fresh air. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Stack-based vector container
by Gregory Crosswhite 30 Jan '11

30 Jan '11

Hey everyone, In the course of my work as a computational scientist I have written a container that emulates std::vector, but which is backed by an array whose size is fixed at compile time. Concretely, the class looks something like the following: template<typename T,unsigned int buffer_size> class static_vector { ... protected: T data[buffer_size]; T* end_ptr; size_t current_size; } where in the [...] there are methods that emulate (at this time, partially) the interface of std::vector, save that the size of the static_vector is not allowed to grow beyond the buffer_size. The advantage of using a static_vector over vector is performance. In my code I have performed benchmarks that show up to a 30% performance boost of static_vector over vector; the benefit occurs most stongly when working with lots of arrays of small objects, so that the use of dynamic memory rather than stack memory appears to add significant overhead to the computation. (Note that I when running these benchmarks I would use std::vector::reserve() to pre-allocate the array so that std::vector would not perform multiple allocations as the container grew, so that should not have been a source of overhead.) It seems to me that it would be useful to have this functionality generally available as a library, and in particular it might be a good fit for the boost family of libraries. Is there any interest out there for having such a library in boost? If so, I would be happy to do the work of taking what I have and fleshing it out so that it can function as a drop-in replacement for vector, which means modeling the Random Access Container and Back Insertion Sequence concepts as well as adding capacity() and reserve(size_t) (no-op) methods. Thoughts? Cheers, Gregory Crosswhite

17 53

GIL io_new review
by Phil Endecott 30 Jan '11

30 Jan '11

Back in 2006 I had some code that used ImageMagick's Magick++ library to read and write images in various formats and do some basic processing. That library works well and is very feature-full, but is not what you would call "Boost like", so I was excited when GIL came along. I looked at it at the time of its review, and I thought at first that I must have missed a big chunk of the documentation where all the algorithms were described! Of course, it has no image processing algorithms; it's just a layer; if you want to scale or rotate or merge images, you have to do that yourself. I don't think I wrote a review in the end; my feeling was - in comparison with ImageMagick - "come back when you've finished" - but I didn't want to say that in public. So it's great that now, 4 years later!, we are finally getting some GIL extensions. Thank you Christian for - I hope! - getting the ball rolling. I hope we'll see more. Having said that, I suspect that even with lots of extensions GIL might not really be what I need. Here's a typical problem that I will have to address in the next few weeks: I have a 1e12 pixel image - a map - which is supplied as a few thousand 5000x5000 TIFF tiles; I have to join them together, tweak the colours, draw some lines on top, and re-chop it into a few million 256x256 PNG tiles. The issue of course is that that image can't be held in RAM. I will do this with my own wrappers around libtiff and libpng, in rows or chunks. So, do the image concepts (and concrete classes) that GIL defines accommodate that sort of problem? Even if they do, is a "virtual image" of some sort a good way of doing it? I suspect not. But even if the image concept is not useful, presumably other GIL concepts like pixel formats and algorithms in future extensions (pixel format conversion, blending) could still be useful. So, along comes Christian's IO extension. Wrapping the "legacy" image libraries is something that I have done a few times now and it can be painful, not least because of the need to read a lot of documentation; the libraries all differ and it would be great to get a unified set of wrappers that provide a sane C++ interface. But as you can see, I don't really want something that reads and writes complete GIL images, and that is what Christian's extension does. Ideally, this extension would have separated out the wrapping of the libraries from the actual GIL image integration, with the GIL image integration just being a layer on top of the image library wrappers. Since it doesn't do that, it's not much use to me. It is, however, better than what GIL currently has. So for that reason I suggest that it should be accepted. > - What is your evaluation of the design? In addition to my comments above, I note that it's necessary to jump through hoops (using Boost.IOStreams) just to read an image from memory. Surely this should be a fundamental operation; it would be much better to have a ctor that takes begin and end pointers for the encoded image data. > - What is your evaluation of the implementation? When I first looked at the library I noticed that the error handling was clearly broken. Although that seems to have been resolved, it has given me a poor impression of the quality (i.e. likely correctness) of the implementation. It seems that this error handling has received almost no testing. Thorough testing will be difficult for this library because as well as all the usual permutations of platform features, compilers etc. the variations in the image libraries must also be considered. The library version and compiler settings could both affect the correct operation of this code. I have some concerns about the likely performance of the code due to excessive copying of the data both in and out of the image library. Although I've not measured the performance impact, I feel it would be very desirable (and is certainly possible) for this library to have zero copying. > - What is your evaluation of the documentation? Satisfactory. (As a meta-comment - I think libraries being reviewed really should have their docs available online somewhere, and preferably also their source code in a source browser of some sort. In fact, I thought this was already a requirement. Can it be added to the review managers' checklist for future reviews?) > - What is your evaluation of the potential usefulness of the extensions? It's better than what was there before. > - Did you try to use the extensions? With what compiler? Did you have > any problems? No, I've not compiled anything. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Probably half a day during the review, and a similar amount of time a few months ago. > - Are you knowledgeable about the problem domain? I've written a few wrappers for libjpeg, libpng and libtiff. I've never used GIL though I've read extensively about it. > And finally, every review should answer this question: > - Do you think the extensions should be accepted as a part of Boost.GIL > library? On the grounds that this is better than what is currently there, and on the assumption that Domagoj Saric is not imminently going to post something else that would supersede this, I believe that it should be accepted. (I have not looked at the "toolbox" at all, and I've not seen it mentioned in any other reviews yet. My "yes" is just for the io_new functionality.) Regards, Phil.

7 39

[gil][io_ew] performance test
by Christian Henning 30 Jan '11

30 Jan '11

Hi there, I did a little performance test of io_new vs io2. The code is here. http://pastebin.com/eCeFZuMS On my machine io_new runs in 1.15sec for 2658 jpegs. IO2 run in 1.005sec. All jpegs are the same image but they are a different file. This way I'm sure I don't have to convert the image into a different color space. I did that since io2 doesn't support any_image, I believe. Thanks, Christian

3 5

[fiber] Mac OS X
by Daniel Larimer 30 Jan '11

30 Jan '11

I am attempting to use Boost.Fiber on Mac OS X, but it always crashes in makecontext() which is now deprecated on Mac OS X. Is there any plan to get asm working for OS X? include <boost/fiber.hpp> boost::fiber* fi; void fib() { for( int i = 0; i < 10; ++i ) fi->yield(); }; int main( int argc, char** argv ) { boost::fiber f( boost::bind(fib), boost::fiber::default_stacksize, boost::protected_stack_allocator()); fi = &f; f.run(); return 0; } Reason: KERN_INVALID_ADDRESS at address: 0x0000000000010fa0 0x00007fff80820f89 in makecontext () (gdb) bt #0 0x00007fff80820f89 in makecontext () #1 0x000000010001f3a3 in boost::contexts::context::impl_t::impl_t (this=0x100100210, fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, vp=0x100100190, stacksize=65536, nxt=0x1001001c0, alloc_=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:58 #2 0x000000010001f183 in ~auto_ptr [inlined] () at /usr/include/c++/4.2.1/memory:59 #3 0x000000010001f183 in boost::contexts::context::init_ (fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, nxt=0x1001001a0, vp=0x100100190, stacksize=65536, alloc=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:77 #4 0x00000001000017db in boost::contexts::context::create<boost::contexts::protected_stack_allocator> () #5 0x0000000100001a96 in boost::fibers::detail::fiber_base::fiber_base<boost::contexts::protected_stack_allocator> () #6 0x0000000100001b65 in boost::fibers::detail::fiber_object<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0> >::fiber_object<boost::contexts::protected_stack_allocator> () #7 0x0000000100001bdd in boost::fibers::fiber::make_fiber_<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #8 0x0000000100001c54 in boost::fibers::fiber::fiber<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #9 0x00000001000010be in main () Boost 1.45 Boost.Fiber 0.7.0 from Valut i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) Mac OS X 10.6.6

3 2

[CfP] Reminder: 5th Annual BoostCon, Aspen (CO, USA), May 15-20, 2011
by Hartmut Kaiser 30 Jan '11

30 Jan '11

Please note the extended deadline: February 10th, 2011 ------------------ Please distribute. ------------------ 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on research. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it changes life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations ------------- Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ------------- Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ------------- Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ------------- Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ------------- These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations ------------- We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon2011. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2011 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon2011(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. IMPORTANT DATES New proposal submissions due: January 10th, 2011. Proposals decisions sent (tentative program): February 17th, 2011. Fully scheduled program available: February 25th, 2011. Session materials due: April 15th, 2011. Hartmut Kaiser: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

type traits extension: progress status
by Frédéric Bron 30 Jan '11

30 Jan '11

I have been able to make the binary operator traits work with pointers. It has been a hard job but I think it is now working well (thank you Jeffrey for pointing to that particular issue). I still have to do the same for unary operators but this should be much easier. The current list of supported operators (35) is now: * 28 binary operators: . ==, !=, <, <=, >, >=, . +, -, *, /, %, +=, -=, *=, /=, %=, . &, |, ^, &=, |=, ^=, . <<, >>, <<=, >>=, . &&, ||, * 5 prefix unary operators: . ! . -, + . --, ++ * 2 postfix unary operators: . --, ++ Here are the links to the updated code and documentation: * http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… * http://svn.boost.org/svn/boost/sandbox/type_traits/ Frédéric

3 4

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 30 Jan '11

30 Jan '11

>> > // UTF validation >> > >> > bool is_valid_utf() const; >> >> See, that's what makes the whole thing pointless. > >Actually not, consider: > > socket.read(my_string); > if(!my_string.is_valid_utf()) > .... This, and many of these functions, work much better as standalone functions: // with a string-aware function socket.read(my_string); if (!is_valid_utf8(my_string.begin(),my_string.end())) .... // with a C interface std::vector<char> vec; vec.resize(MY_BUFSIZE); int len = recv(socket, vec.data(), MY_BUFSIZE, 0); if (len >= 0) { vec.resize(len); if (!is_valid_utf8(vec.begin(), vec.end())) .... } // conversion for Windows API std::vector<wchar_t> vec; vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); HRESULT hr = WriteFile(handle, vec.data(), vec.size(), &dwBytesWritten, NULL); ... Joe

6 5

One small step for mankind - was Re: What's happened to Ryppl?
by Robert Ramey 30 Jan '11

30 Jan '11

Dave Abrahams wrote: > Robert, great questions. Could you post them to the boost developers' > list? They really don't belong here. > > Thanks. > > On Sat, Jan 29, 2011 at 12:57 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> Dave Abrahams wrote: >>> On Fri, Jan 28, 2011 at 4:35 PM, Robert Ramey <ramey(a)rrsd.com> >>> wrote: >> >> In the interest of moving toward a better modularization of boost >> and decoupling of libraries, I would like to make a suggestion: >> >> Can we change library testing so that each library is tested against >> the current release branch of all the other libraries? >> >> When I test on my own machine, I don't test against the trunk. I >> test against the current release tree. Another way of saying this is >> that on my current machine I have my directory tree set to the >> the boost release branch. ONLY the serialization library directories >> are set to the trunk. So when I test on my local machine I KNOW that >> when I merge >> into the release branch I won't have any unexpected problems. >> >> a) I don't think this would be a huge change. >> b) It would better test what the user does >> c) It would isolate each library from another so that >> errors in the trunk (wild west) in one library don't impact >> on development of other libaries. >> d) It would promote decoupling of libraries. >> e) as an intermediate step, not all testers would have >> to make the change - some could use the old script. >> >> It would be a small, not too difficult step on the path >> we think we want to travel. >> >> Robert Ramey >>

2 1

Re: [boost] [string] proposal
by Ivan Le Lann 30 Jan '11

30 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> a écrit : > > From: Dean Michael Berris <mikhailberis(a)gmail.com> > > > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> > > >> No, it's not obvious. Here's why: > > >> > > >> fd = creat(file.c_str(), 0666); > > >> > > >> What does c_str() here imply? It implies that there's a buffer > > >> somewhere that is a `char const *` which is either created and > > >> returned and then held internally by whatever 'file' is. > > > > > > It implies that const file owns const buffer that holds null > terminated > > > string that can be passed to "char const *" API. > > > > > > > Yes, which is the problem in the first place. Every instance of > string > > would then need to have that same buffer even if that string is > just a > > temporary or worse just a copy. > > > > It would not happen if it holds the data as linear single chunk :-) > > > >> Now let's say > > >> what if file changed in a different thread, what happens to the > buffer > > >> pointed to by the pointer returned by c_str()? Explain to me > that > > >> because *it is possible and it can happen in real code*. > > > > > > I'm sorry but string as anything else has value semantics > > > that is: > > > > > > - safe for "const" access from multiple threads > > > - safe for mutable access from single thread > > > > > > I don't see why string should be different from > > > any other value type like "int" because following > > > > > > x+=y + y > > > > > > is not safe for integer as well. > > > > > > The code I had shown is **perfectly** safe with > > > string has has value semantics (which std::string has) > > > > > > > Now the point I was making was, in the case of a string that is > > immutable, you don't worry about the string changing *ever*, don't > > need a contiguous buffer for something that isn't explicitly > required. > > It's value semantics *plus* immutability. > > > > So you either should forbid > > your_string const &operator=(your_string const &) > > Which makes it even more useless (IMHO) > > Or your statement is wrong because assignment > can happen for example from other thread like > > str = str + " suffux" > > And this would change the string in run time. > Think str as a shared_ptr<const string_beast> with wrappers. This line does not mutate the structure previously pointed to, just like assigning a shared_ptr does not mutate the object previously pointed to. It makes str points to a newly created chain, which here happens to share data with the original chain but that's another story. Of course, this suppose that you got str by value. If you got it by non-const reference, you can have race issues with other threads, just like any assignment, regardless of the type. Ivan

1 0

[string] proposal
by Matus Chochlik 30 Jan '11

30 Jan '11

Dear list, following the whole string encoding discussion I would like to make some suggestions. >From the whole debate it is becoming clear, that instant switch from encoding-agnostic/platform-native std::string to UTF-8-encoded std::string is not likely to happen. Then it was proposed that we create a utf8_t string type that would be used *together* (for all eternity) with the standard basic_string<>. While I see the advantages here, I (as I already said elsewhere) have the following problem with this approach: Using a name like utf8_t or u8string, string_utf8, etc. at least to me (and I've consulted this off the list, with several people) suggests, that UTF-8 is still something special and IMO also sends the message that it is OK to remain forever with the various encodings and std::string as it is today. We should *IMO* endorse the opposite. My suggestion is the following: Let us create a class called boost::string that will have all the properties that a string handling class in 2011+ A.D. should have, basically what std::string should have been. Then there are two alternatives: a) When all the zillions lines of legacy code in FORTRAN, COBOL, BASIC, LOGO, etc. :) are fixed / ported / abandoned, and UTF-8 becomes a true standard for text encoding widely accepted by the whole IT industry and markets, and all the issues that prevent us from doing the transition now are resolved, this string becomes the standard, like many other things from Boost in the past, and replaces the current std::string. b) As some (having much more insight into how the standardizing comitee works than I do) have pointed out, it will never become a true standard. But with the Boost's influence it at least becomes a de-facto standard for strings and it is (hopefully) adopted by the libraries that currently feel the need to invent string-classes themselves (with a good reason). Also I've uploaded into the vault file string_proposal.zip containing my (naive and un-expert-ly) idea what the interface for boost::string and the related-classes could look like (it still needs some work and it is completelly un-optimized, un-beautified, etc.). /me ducks and covers :) The idea is that, let std::string/wstring be platform-specifically- -encoded as it is now, but also let the boost::string handle the conversions as transparently as possible so if in case the standard adopts it, std::string would become a synonym for boost::string. It is only partially implemented and there are two examples showing how things could work, but the real UTF-8 validation, transcoding, error handling, is of course missing. Remember it is aimed at the design of the interfaces at this point. If you have the time, have a look and if my suggestions and/or the code looks completely wrong, please, feel free to slash it to pieces :), and if you feel up to it, propose something better. If this or something completely different and much better that comes out of it, will be agreed upon, we could set up a dedicated git repository for Boost.String and maybe try if the new suggested collaborative development in per-boost-component repositories really works. :) If some of the people that are skilled with unicode would join or lead the effort it would be awesome. Best, Matus

28 233

Re: [boost] [string] proposal
by Artyom 30 Jan '11

30 Jan '11

> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > >> No, it's not obvious. Here's why: > >> > >> fd = creat(file.c_str(), 0666); > >> > >> What does c_str() here imply? It implies that there's a buffer > >> somewhere that is a `char const *` which is either created and > >> returned and then held internally by whatever 'file' is. > > > > It implies that const file owns const buffer that holds null terminated > > string that can be passed to "char const *" API. > > > > Yes, which is the problem in the first place. Every instance of string > would then need to have that same buffer even if that string is just a > temporary or worse just a copy. > It would not happen if it holds the data as linear single chunk :-) > >> Now let's say > >> what if file changed in a different thread, what happens to the buffer > >> pointed to by the pointer returned by c_str()? Explain to me that > >> because *it is possible and it can happen in real code*. > > > > I'm sorry but string as anything else has value semantics > > that is: > > > > - safe for "const" access from multiple threads > > - safe for mutable access from single thread > > > > I don't see why string should be different from > > any other value type like "int" because following > > > > x+=y + y > > > > is not safe for integer as well. > > > > The code I had shown is **perfectly** safe with > > string has has value semantics (which std::string has) > > > > Now the point I was making was, in the case of a string that is > immutable, you don't worry about the string changing *ever*, don't > need a contiguous buffer for something that isn't explicitly required. > It's value semantics *plus* immutability. > So you either should forbid your_string const &operator=(your_string const &) Which makes it even more useless (IMHO) Or your statement is wrong because assignment can happen for example from other thread like str = str + " suffux" And this would change the string in run time. Your statement is false unless I miss something or you want to put a mutex inside a string or some other atomic variable. I don't see any reason to not to treat a string as any other value. > > > > I think we both and 95% of C++ programmers that use STL > > know what is the semantics of std::string::c_str() > > > >> I like this better: > >> > >> char * filename = (char *)malloc(255, sizeof(char)); // I know I > >> want 255 characters max > >> if (filename == NULL) { > >> // deal with the error here > >> } > >> linearize(substr(file, 0, 255), filename); > >> fd = creat(filename, 0666); > >> > > > > Sorry? Is this better then: > > > > fd=create(filename.substr(0,256).c_str(),O_EXCL...) > > > > Which by the way is 100% thread safe as well (but still may throw). > > Even thou I can't see any reason to cut 256 bytes before create > > > > No, not better because std::string's substr() will return a temporary, > which means it will be a copy -- meaning another allocation and a call > to memcpy(...). You don't get the benefit of COW on this one because > you need to cut the string down to a "maximum size". > Actually small notice you will have to copy because C API expects NULL terminated string, so you can't avoid memory copy if the last byte is not NULL. So no difference there > I don't know if you know, but them C APIs from OSes have a defined > maximum on the lengths of filenames and things like that... > Not exactly maximal length is something much more complicated, run-time and specific OS dependent, but this is other story. > >> And then the problem is not addressed then of the unnecessary contiguous > >>buffer. > >> > > > > There is good idea to have some non-linear data storage but > > it should used in very specific cases. > > > > Also what is really large string for you that would have > > performance advantage not being stored lineary. > > > > Talk to me in numbers? > > > > Say on a machine+OS combo that has 4kb pages, a large string would be > something that spans more than one memory page -- i.e. >4kb. > > Now a "short" string is one that can fit within a page. For > concatenated strings, it's fine to compact/copy the substrings into a > growable/shrinkable block. The overhead for a short string would be > constant, as the concatenation tree would be a pointer and a length > with a reference count integer. Actually I actually mean benchmarks how long string should be that it would be more efficient to use as chunks. So you suggest 4k Which: 1. Covers almost all full file path names on every operating system 2. Covers almost all messages in text dialogs around 3. Covers all possible user data etc. So basically a single memory chunk is efficient for 99% of use cases. Now lets take it to extreme: - Longest Wikipedia article: 388k = ~ 39 pages - Book: War and Peace: text size... 3.1MB = 800 pages. How frequent this case? Very rare. See text is basically something quite short, long books were successfully written in days where 640K was more then enough. So the real benefits of non-linear data structure are rare, on the other had they add too much complexity for every day use. So basically: 1. 99% of use cases fit to single page. 2. Very few cases would actually make a use of multi-page architecture. 3. The extreme cases that may benefit of this data structure are very rare and probably should use their own structures. Just to clean up all the things 1. I do think that what you suggest is interesting and fine data structure. 2. I do think that in certain cases it would be very useful. 3. I do think that you have good experience with situations were such structure may be very useful. 4. I know your works (netlib) and I really appreciate what you do . However I still think: 1. Such structure does not give much benefits in main stream cases for string data structure in its text meaning (which what string for 99% programmers is). I mean non-linear memory is not really so useful for common use case. 2. I think you should take a look on major string use cases to decide what is better for "next C++ string" if you want to develop some. Also as you probably know I'm author of several projects most of them are strongly tied to text processing and handing: 1. Boost.Locale - strongly text and Unicode oriented. 2. CppCMS - C++ web framework that deals with strings and networking in most of its code. That by the was was the reason for Boost.Locale to be developed. 3. BidiTeX - bidirectional support for LaTeX/Hebrew which is mostly deals with text. So I do have some basic view on what are the use cases of strings, I don't say I know them all but I developed some "feeling" about what text processing needs and in my opinion you just miss the major use case. I think I'll stop trying to convince you that it is wrong way to look at string just because I think that users would know what to pic in real applications. Best Regards and Good Luck, Artyom

1 0

[1.46] Last few merges needed?
by John Maddock 29 Jan '11

29 Jan '11

I've been sifting through what needs to change on the release branch (for 1.46) in Boost.Config to revert some of the changes made by Bryce which have already been reverted in Trunk. Specifically: The patches to the pathscale config need to be merged to Release (unfortunately it took until now to get these working on Trunk): --- boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 +++ ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" -#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) +#elif defined __PATHSCALE__ // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp" And also the Boost.Config docs need to be merged to release so that the new BOOST_*_NIX macros that were added and then removed are no longer documented in 1.46 (the actual changed headers can wait till 1.47 for merging). Is there likely to be a window when these changes can be merged - maybe between beta and release? Also are there any other pending reverts in Trunk but not release? Regards, John.

7 22

[network] Bagged, Tagged, New Release 0.8.1
by Dean Michael Berris 29 Jan '11

29 Jan '11

Hi Everyone, Just a quick note, there's an update to the 0.8 line which addresses issues that have been identified with the previous 0.8 release. It's recommended that people using the 0.8 release upgrade to 0.8.1. This release is still a header-only release, with some features back-ported from the 0.9-devel branch. You can get the 0.8.1 release at https://github.com/cpp-netlib/cpp-netlib/downloads Have a good day everyone and I hope this helps. PS. The 0.9 release should come out soon, final documentation updates are just getting done; the 0.9 line will be the version that shall be submitted for review, looking for interested review managers at this time. -- Dean Michael Berris about.me/deanberris

1 0

Re: [boost] [string] proposal
by Brent Spillner 29 Jan '11

29 Jan '11

On Jan 29, 2011, at 8:43 AM, David Bergman wrote: >There are four layers in play here: >1. The sequence of characters/symbols, as in CS string; totally abstract but precise... (one such CS string can be represented as Unicode or Latin-1 at #2, for instance.) >2. The sequence of code points, in a given character set. Yes, one CS string (as in #1) can have multiple distinct manifestations at this level. They could be identical in >integral sequences. >3. The sequence of code values, using an encoding form such as UTF-8 or UTF-16 for a Unicode code point. >4. The byte storage representing the code values; could be a contiguous sequence of bytes or chunks, etc. Which, IMHO, is exactly why it's (past) time to radically rethink the standard string interface. Your four layers share the properties that: (a) They can all be physically represented within the same data structure (i.e. layer #4), and (b) For any layer, there already exists a lot of legacy code that conceptualizes passed-in strings at that layer and that makes corresponding assumptions. To me, these facts imply that a 'view'-based approach is the right way to go. Furthermore, views should not be concrete data structures themselves, but simply iterator pairs (ranges) that internally point to some arbitrary data structure, and externally present a model of a linear sequence of atomic characters/codepoints/etc. In software development Nirvana, APIs and algorithms will operate on iterator_ranges at the appropriate conceptual level, rather than intruding into the underlying data structures, and at the interfaces with reality we'll just copy data to and from more concrete representations using the chosen encoding. Some of those interfaces (with low-level device drivers or with memory-mapped hardware itself) might never go away, but many (e.g. a GUI API that accepts a string and returns a texture of its glyphs) would hopefully eventually migrate to the iterator model. For example, one might write std::string underlying_data = obtain_validated_data_from(somewhere); text<ucs4, codept_view, decltype(underlying_data)> codepoints(assume_utf8(underlying_data)); text<utf8, char_view, decltype(underlying_data)> characters(assume_utf8(underlying_data)); if (codepoints.length() > characters.length()) contains_multipoint_characters = true; // converse not necessarily true if there are codepoints for multi-character ligatures const char *byteptr = linear_representation(underlying_data); // may or may not accurately track later changes, especially if the underlying data is non-contiguous, but that's really a usage protocol question and not for the data structure to solve--- anyway, strdup() if you want a snapshot from a given point in time text<utf8, char_view, characters::internal_representation> substring = all_after(characters.begin(), characters.end(), "phrase to match"); std::vector<wide_char_t> char_array; std::copy(substring.begin(), substring.end(), char_array.begin()); etc. When you think your usage pattern favors a rope or a chain over a std::string, you only have to change the declaration of the underlying_data object and the rest works seamlessly. I think Dean favors immutability because that makes it easy for the iterator-adaptors to cache data in the representation they need (or in more local storage in a NUMA environment), but like specifying a particular byte encoding for the underlying data this would be more for convenience and performance optimization than a firm requirement. When the underlying representation is a mutable type, read-only view adapters are still free to cache chunks of data as long as they check for a fingerprint that writable view adapters leave on the underlying structure whenever they commit a change. Consider the underlying data structure as a sequence of arbitrary 'tokens' (bytes, characters, codepoints, variable-length compressed bitstrings... whatever makes sense); a read-only substring cache that depends on tokens i though j (inclusive) of version v of the underlying representation can be described by the tuple r(v, i, j), while a serialized write operation that changes the tokens in positions i though j from version v to version v+1 can be described by the tuple w(v+1, i, j). A write w(v, x, y) invalidates all or part of a read cache r(v', x', y') if and only if v' < v && x' <= y && y' >= x (and if partially invalidated, we know exactly which segment(s) are still OK.) The dereference operator of the read-only iterator then needs to check its cached v' against the underlying data structure's latest version, and if necessary skim through a small ring buffer of recent w(v, x, y) tuples to see if part of its cache must be invalidated (if v' + 1 is less than the earliest v in the ring, the reader can conservatively invalidate its entire cache.) This is a negligible amount of overhead (in the common case, a single fetch, compare, and predictable branch, and in the worst case a new transcoding that you would have had to perform anyway) per character/codepoint/byte access, and when even that is unacceptable you can simply cache a representation of the string in a buffer of known encoding and make everything else adapt to /your/ data layout. I'm intentionally not delving into the details of synchronizing reads and writes between different threads, as std::string and char[] don't provide that either, but if you really need some views to provide their own synchronization this is a (relatively) straightforward place to build it in. >1. Why can't this byte storage type not be used for all kinds of things; is not 'string' a quite bad name for it, since it is neither a string according to most programming >languages (see above) nor according to that CS definition that you are alluding to (unless you consider uninterpreted bytes to be symbols, but be quite aware that those >'symbols' would have nothing - or very little - to do with the symbols of the text represented through your construct.) Wholeheartedly agree; the view should have a name like 'text' (or 'characters', 'codepoints', 'bytes', etc.) and the underlying data structure can be string, rope, vector<char>, or boost::not_invented_yet. Sure, views don't completely solve the problem of legacy APIs that require a persistent, writable reference to a block of text (e.g.a text entry widget that maps its input to a character buffer); if you're lucky to can map the widget to the underlying_representation structure and create the views you need for other parts of the program. If you're not lucky, you might have to make a separate copy for each legacy interface and check periodically or on-demand for changes, but I'd still much rather use a data structure that forces me to make explicit copies than one that encourages me to risk sharing a single buffer between APIs that may not make the same encoding assumptions.

1 0

Survey: What should an immutable byte sequence data structure be named?
by Gregory Crosswhite 29 Jan '11

29 Jan '11

Hey everyone, To gather more data about what the community thinks an immutable byte sequence data structure should be called (given that "string" has already been taken), I have created the following poll: https://catalyst.uw.edu/webq/survey/gcross/123312 If you have an opinion on the matter, please consider visiting the above link and submitting your favorite name. Some names that have been tossed around are istring, immutable_string, chain, rope, yarn, twine, cord, but don't feel limited to these choices. Cheers, Gregory Crosswhite

7 7

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Dean Michael Berris" <mikhailberis(a)gmail.com> wrote : > On Sat, Jan 29, 2011 at 8:07 PM, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > Dean Michael Berris wrote : > > > >> > >> But c_str() doesn't have to be part of the string's interface. > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for > "boost::chain" > > > > And this is precisely my point as well: the one that uses boost::chain > is perfectly suited for this kind of use case in both efficiency and > clear-cut semantics. I for one don't like to make to_string() a member > either -- I much rather make it a conversion operator so boost::chain > (if we're going to call it that) can be used where interfaces take a > std::string. > [Note: I'm all for chains/ropes/etc, only looking for corner cases] I definitely agree for my example, which is a pure rope demo. linearize(chain) can give a c_str at no cost for trivial chains, and is not heavier than std::string::operator+ for non-trivial chains. Cool. Now looking at Artyom example makes me consider the quite common case where the desired output is not c_str but std::string itself. Add move optimizations on top of that: func_taking_std_string ( /*linearize*/ (my_chain_func ())); func_taking_std_string ( (my_string_func ())); No matter the way you put it, you have one unnecessary allocation, because std::string has no move constructor from chain (yet). For people eventually throwing their boost::chain into std::string, we're basically killing all move/RVO optimizations. Am I missing something? Ivan

2 1

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 29 Jan '11

29 Jan '11

Anders Dalvander wrote: > On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: >> // conversion for Windows API >> std::vector<wchar_t> vec; >> vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); > >I spy with my little eye a potential crash waiting to happen. >Code-points != Code-units. Dang, you're right. I used the wrong term. This is why Unicode correctness is so hard. So much for my graceful introduction to the mailing list. :-) Joe

1 0

Re: [boost] Survey: What should an immutable byte sequence data structure be named?
by Andrew Sutton 29 Jan '11

29 Jan '11

I agree with Dave. Buffer. Python uses "frozen" to describe the same (similar?) property for sets. On Jan 28, 2011 3:10 PM, "Dave Abrahams" <dave(a)boostpro.com> wrote:

5 7

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Yakov Galka" <ybungalobill(a)gmail.com> wrote: > On Sat, Jan 29, 2011 at 14:07, Ivan Le Lann <ivan.lelann(a)free.fr> > wrote: > > > > > *My* *guess* is that Artyom think that: > > > > os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for > std::string > > > > is dramatically faster than: > > > > os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c > for > > "boost::chain" > > > > Aren't they perform the same? Actually with lazy evaluation the latter > will > be faster. > For this example, I agree. I'm only stressing the marketing issue. Eventually, we'll need figures here. Big-sized font figures. Ivan

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

Dean Michael Berris wrote : > On Sat, Jan 29, 2011 at 5:24 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > > - > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> > >> On Sat, Jan 29, 2011 at 3:02 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > > >> > It would turn away 90% of users. > >> > > >> > >> It might turn you away because you obviously love std::string. > >> Generalizing is a different matter and is largely a hot-air blowing > >> exercise that is futile for convincing anybody. > >> > > > > I would say it more clear: > > > > 1. All users that use C libraries and need c_str() at boundaries > > And this is a huge amount of users that need to communicate > > with modules that are already working and ready but written in C. > > > > And this is about of half of libraries there is C is the lowest > > level API that allows easy bindings to all languages. > > > > But c_str() doesn't have to be part of the string's interface. *My* *guess* is that Artyom think that: os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string is dramatically faster than: os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain" Regardless of the validity of my present guess, I'm quite sure that this concern (and other similar ones) will be shared many developpers. Ivan

3 2

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 20:12, Joe Mucchiello<jmucchiello(a)yahoo.com> wrote: > // conversion for Windows API > std::vector<wchar_t> vec; > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); I spy with my little eye a potential crash waiting to happen. Code-points != Code-units. vec has room for N code-units, but 2*N code-units may be written to it if mystring contains non-BMP characters. "Corrected" code: std::vector<wchar_t> vec; vec.resize(count_codeunits<wchar_encoding>(mystring.begin(), mystring.end())); convert<wchar_encoding>(mystring.begin(), mystring.end(), vec.begin()); I think a lot of these potential crashes could be prevented if the iterator of the new string-type (chain,text,tier,yarn) would only expose (const) code-points. Actual code-units would be hidden, and only accessed using a facade/adapter view/iterator. auto u8v = make_view<utf8_encoding>(mystring); auto u16v = make_view<utf16_encoding>(mystring); for (auto codepoint : mystring) {...} for (auto u8codeunit : u8v) {...} for (auto u16codeunit : u16v) {...} I also think there isn't a reason that the new string-type *has* to be UTF-8 internally. It could be UTF-16, UTF-32, SCSU, or CESU-8 internally for that matter. Making a view from the internal encoding to an external encoding when both encodings are the same should be a no-op. Regards, Anders Dalvander -- WWFSMD?

1 0

Re: [boost] [string] Realistic API proposal
by Anders Dalvander 29 Jan '11

29 Jan '11

On 2011-01-28 23:04, Artyom<artyomtnk(a)yahoo.com> wrote: >> > // conversion for Windows API >> > std::vector<wchar_t> vec; >> > vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); >> > convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); >> > HRESULT hr = WriteFile(handle, vec.data(), vec.size(),&dwBytesWritten, >> > NULL); >> > ... >> > > Notice vector is not string and it requires additional copy If std::string is UTF-8 encoded (as you are suggesting, correct?), then you also requires additional copy: // conversion for Windows API std::string u8s = ...; std::wstring u16s = convert_to_utf16(u8s); HANDLE h = CreateFileW(u16s.c_str(), ...); Regards, Anders Dalvander -- WWFSMD?

2 1

[web] Broken link.
by Mostafa 29 Jan '11

29 Jan '11

FYI: on https://svn.boost.org/trac/boost/ , the following link is broken: "http://svn.boost.org/trac/boost/browser", see "You can browse the Boost Subversion repository online or retrieve Boost via ...". Mostafa

1 0

Re: [boost] [string] Realistic API proposal
by Ivan Le Lann 29 Jan '11

29 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> wrote : > Hello All, > > I'd like to provide a realistic string API proposal: Thanks for your contribution. I do have a naïve question: What happens to your extensions when "Char" template argument is not char? Do they still have a meaning ? Ivan

2 1

Re: [boost] [string] proposal
by Joe Mucchiello 28 Jan '11

28 Jan '11

On Jan 28, 2011, at 12:59 PM, Dean Michael Berris wrote: > > And I stopped before I write too much -- the initial version is > already up: >https://github.com/downloads/mikhailberis/cpp-string-theory/cpp-string-theo… > > > -- I'll give it more information and the actual interfaces and > implementation as soon as I get some Z's. :) > Hi, I have a question. You keep saying that the string (or chain) has no encoding the string is "just a sequence of bytes" but that doesn't make sense. The bytes have to have some form of encoding otherwise how do the adapter classes know how to convert the sequence of bytes into an encoded sequence? When you say the string has no encoding do you simply mean the default encoding is implementation dependent? Did I miss where you said this somewhere? Oh, and I see the value in an immutable string. I just think you are still at such a high level that it's hard to see where you are going for some people. Joe

2 1

Re: [boost] [Boost-users] Git vs SVN (was: Re: What's happened to Ryppl?)
by Dave Abrahams 28 Jan '11

28 Jan '11

[moved to developers' list] On Fri, Jan 28, 2011 at 8:48 AM, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > May I suggest that to keep signal/noise ratio on the list to acceptable > level, we don't have a general VC shootout discussion. It will never lead > to anything. +1, but I don't think anyone intended to do that. > Rather, the parties interested in having Boost switch to any > version control system that is not SVN should propose a specific plan, > including hosting, administration, adjustment of all scripts, new workflows > for Boost maintainers and authors of proposed libraries, etc? > > If would be seriously not funny if 1000 messages later we'll find that > git is about to solve every problem on earth, but there's nobody to > do *complete* transition and onging maintenance. I think what you've just said is an important part of the discussion we should be having right here and now. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[mpl] Using transform problem and solution
by Edward Diener 28 Jan '11

28 Jan '11

I have a boost::mpl::vector of nullary metafunctions and I need to transform it into a sequence of the metafunction's inner types. As in: typedef boost::mpl::vector<boost::mpl::identity<int> > tvec; typedef boost::mpl::vector<int> tvecinner; So I try boost::mpl::transform: typedef typename boost::mpl::transform<tvec,_1>::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); But that does not work and the assert fails. Evidently my _1 is not working by itself although it seems as if it should because it is a placeholder expression and its inner type is what I want. So I try: template <class T> struct tself : T { }; and now instead: typedef typename boost::mpl::transform<tvec,tself<_1> >::type ttrans; BOOST_MPL_ASSERT((boost::mpl::equal<tvecinner,ttrans>)); works fine and the assert succeeds. But that 'tself' hack seems like it should be really unnecessary. Have I missed something cleaner and easier ?

3 3

Trac down?
by Beman Dawes 28 Jan '11

28 Jan '11

I'm getting a blank page when I try to access svn.boost.org/trac/boost/ That's a serious impediment to building the 1.46.0 beta. I really need the release manager's checklist from the trac. Are others able to access Trac? --Beman PS: The good news is that SVN seems to be running really well, with none of the slowness and server errors that were a problem several weeks ago.

5 8

[Boost.Algorithm] Proposal for addition of a new algorithm: ThreeWayMerge
by Aleric Inglewood 28 Jan '11

28 Jan '11

Greetings everyone. I don't think that Boost.Algorithm exists: I only saw it refered to on mailinglists. I looked at the existing libraries, but I'm not sure where this would fit in. I'd like to propose the addition of a new algorithm, very much like std::set_union and companions, that I came up with recently. This algorithm does a three-way merge of containers. Comparing it to std::set_union, which needs five iterators to be passed, and a compare functor (two iterators for the range of input 1, two iterators for the range of input 2 and one output iterator), the three_way_merge algorithm takes three iterator ranges and one output iterator, so it takes seven iterators. The algorithm also takes two functors: a compare and an is_equal. The former should be the ordering Predicate used with the containers (they must be ordered containers, like std::set or set::map), while the is_equal functor is usd to compare the "payload" of the data (which is not part of the sorting key). The algorithm applies trivial merge rules in all cases where the merge is trivial, and calls a third functor to perform the three-way merge of the payload in those cases that a three-way merge is not trivial. In it's current form, my algorithm looks as follows: https://github.com/AlericInglewood/contribmerge/blob/master/src/three_way_m… I used it (in that project) to three-way-merge a file with a specific format: a list of contributors, each with a list of contributions. The algorithm is used recursively (which is very neatly showing it's true power, of course). For this usage example, please see https://github.com/AlericInglewood/contribmerge/blob/master/src/contribmerg… Aleric

1 0

Re: [boost] [string] proposal
by Anders Dalvander 28 Jan '11

28 Jan '11

On Thu, 27 Jan 2011 12:51, Nevin Liber <nevin(a)eviloverlord.com> wrote: > I'd like to see this broken up into three discussions: > > 1. Immutable strings. Immutable or not, I don't see a direct use for modification of individual code-units (e.g. char, wchar_t) in a string. Too many things can go wrong. Some kind of manipulation of code-points, yes, but not code-units. Anyway, code-points are not the end either. Multiple code-points may be needed to represent a grapheme, using combining characters. And sometimes a single code-point can represent several graphemes, such as ligatures. > 2. utf8 strings. Although I personally prefer UTF-8 encoded strings, the internal encoding is more or less irrelevant for an implementation based on rope or similar non-contiguous data structure. I believe this is what Dean Michael Berris is suggesting. I think this is especially true if direct access to individual code-units are prevented. For an implementation using a contiguous data structure and providing a constant time c_str member function I'd really want to see some option to set the internal encoding of strings. Performance-wise it may be preferred to use UTF-16 internally when using for example Win32 API, if an extra copy can be avoided. > 3. Unrealistic pipe dream about replacing std::string. Replacing std::string will never happen. Deprecating std::string in favor of std::text/std::unicode/std::xstring may happen in the long run. Regards, Anders Dalvander -- WWFSMD?

2 1

[signals2] -no instance of overloaded function
by Tal Agmon 28 Jan '11

28 Jan '11

Hi All, I get error no instance of overloading ... when using <memory> shared_ptr can anyone explain why? tested on: windows7 vc100 // not working //#include <memory> // fail to compile //using std::tr1::shared_ptr; // works #include <boost/shared_ptr.hpp> // works find using boost::shared_ptr; [code] #include <iostream> #include <boost/signals2/signal.hpp> class Reporter { public: explicit Reporter(const std::string& s) : s_(s) {} void says() const { std::cout<< "news : " << s_ << std::endl; } private: std::string s_; }; class NewsStation{ public: void displayNews(const Reporter& r) const { r.says(); } }; int main() { using namespace boost::signals2; typedef signal<void (const Reporter&) > signal_type; shared_ptr<signal_type> signalPtr(new signal_type); typedef shared_ptr<NewsStation> news_station_ptr; Reporter tal("when using std:tr1::shared_ptr --> no instance of overloaded function, matches the argument list) "); news_station_ptr newsStationPtr(new NewsStation); signal_type sigNews; sigNews.connect( signal_type::slot_type( &NewsStation::displayNews, newsStationPtr.get(), _1).track(newsStationPtr)); sigNews(tal); } [code]

1 1

Re: [boost] [signals2] -no instance of overloaded function
by Ivan Le Lann 28 Jan '11

28 Jan '11

----- "Tal Agmon" <tal.boost(a)gmail.com> wrote : > Hi All, > > > I get error no instance of overloading ... when using <memory> > shared_ptr > can anyone explain why? > > tested on: > windows7 vc100 > > (snip) > sigNews.connect( signal_type::slot_type( > &NewsStation::displayNews, newsStationPtr.get(), > _1).track(newsStationPtr)); > sigNews(tal); > } Just a bet : I suspect the track method exspects a boost::shared_ptr. Or something a boost::shared_ptr can convert to. Ivan.

2 1

[iterator] Unmerged changes
by Daniel James 28 Jan '11

28 Jan '11

Hi, I've been looking through the unmerged changes in the iterator library. I think it should all be merged/fixed/reverted for 1.47. These seem to be the outstanding changes: An old fix from David Abrahams: https://svn.boost.org/svn/boost/changeset/58012 function_input_iterator from Dean Michael Berris: https://svn.boost.org/svn/boost/changeset/62615 https://svn.boost.org/svn/boost/changeset/62710 The result_of changes (partially merged, but will be reverted for 1.46): https://svn.boost.org/svn/boost/changeset/62625 https://svn.boost.org/svn/boost/changeset/68205 Any comments on these? Anyone willing to take charge, or shall I deal with them? Daniel

2 1

[string] --> [text] ?
by Gregory Crosswhite 28 Jan '11

28 Jan '11

Hey everyone, Since there has been a lot of talk about what the name of a new immutable string class should be, may I toss the name "boost::text" into the ring? The advantage of this name is that it explicitly conveys what it is meant for: working with human-readable text encoded in some implementation-specific form. The name "string" would then continue to have its current interpretation as a string of contiguous 8-bit chars. It has also been suggested that different classes be created for different UTF encodings. I propose that boost::text have the internal encoding be an implementation (and potentially platform-specific) detail. Since at the end of a serious of manipulations with the rope-like data structure one will have to do a final transformation to convert the text into a string of bytes anyway, that provides a natural point at which the desired encoding of the string of bytes can be specified. That is, given a boost::text object "t", one could convert it into a UTF-8 string by calling "t.utf8_c_str()", a UTF-16 string by calling "t.utf16_c_str()", and so on, depending on what the underlying API is expecting. Some of these calls might require recoding the text to a different encoding, so the internal encoding of boost::text could be optimized to whatever is most likely to be needed on that platform so that it is least likely to need recoding. Alternatively, the encoding could be specified as a parameter to the constructor and be carried around as a runtime parameter since nobody needs to know what it is until the final encoding of the string. Thoughts? Cheers, Greg

4 3

[Review][GIL] Boost.GIL IO and Toolbox extensions have been ACCEPTED into Boost
by Mateusz Loskot 27 Jan '11

27 Jan '11

Dear All, The formal review of IO and Toolbox extensions for Boost.GIL [1] ended on December 17th, 2010 [2] The review subject was not a standalone library but a part of whole - an extension to existing Boost.GIL. The review result: ACCEPTED Number of received discussion and feedback posts is ~140. I consider most of them in-topic, significant and also insightful. Reviewers pointed issues already known from previous discussions on the mailing list as well as new topics regarding the design and implementation of the extensions. Also, issues related to the library itself (Boost.GIL) were addressed. Some of them could be considered ideas for future works and improvements. It is remarkable, most (if not all) of the discussions were focused on the IO extension. None of the submitted reviews include comments to the Toolbox extension. Formally, the review concluded with 1 NO and 7 YES votes. Some of the YES votes are considered as conditional and number of changes were requested by the reviewers. The following changes should be addressed before the extensions appear in the Boost mainstream: 1. Documentation is adequate, but requires clean-up and fixing of lots of typos. 2. Additional tests are added to exercise currently untested error cases that result in a longjmp should be added. They should pass on all platforms officially supported by Boost. 3. Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. 4. The requirements for adding new file formats / backends to be made more explicit. This means defining concept for a file format reader/writer, etc. and adding new file formats would constitute providing models for these concepts. 5. Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the file name. 6. Support for different backends for the same image formats. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. 7. Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. The reviewers also posted a few suggestions that could improve quality of the two extensions, 1. Name of functions like read_int8, read_int16, read_int32, write_int8 in Device models suggest they return and accept signed integers, but they return and accept unsigned integers. The naming could be improved.. 2. Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. 3. Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. 4. It would be great if Christian and Domagoj could join their efforts to take the best of their libraries (IO extension implementations) to the IO extension included in Boost.GIL and collaborate for the advanced features discussed in reviews. I would like to thank Edd Dawson, Zach Laine, Domagoj Saric, Roland Bock, Lubomir Bourdev, Tom Brinkman, Phil Endecott, Kenny Riddile for reviews and others who participated in discussions. Thanks also go to Christian Henning for great work. I would like conclude recalling short comment Lubomir Bourdev included in his review. In my opinion, it is a good summary of the Boost.GIL IO and Toolbox review and generally all discussions on this subject: *** The problem with I/O is that you can never declare success. All we can hope for is push the boundary as much as we can, and leave the rest for the next update. *** [1] http://lists.boost.org/boost-announce/2010/11/0273.php [2] http://lists.boost.org/boost-announce/2010/12/0279.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 1

[context] other version with stack
by Oliver Kowalke 27 Jan '11

27 Jan '11

I've uploaded another version (0.5.0) which accepts an stack (instead of an stack-allocator) which will be stored (moved) inside boost::context. the implicit interface of the stack looks like: class my_stack { public: void * address() const; std::size_t size() const; }; boost::protected_stack stack( 1024); boost::context ctx( boost::context::create( my_fn, 0, stack) ); Oliver

1 0

[static_assert.hpp] Add BOOST_STATIC_ASSERT_MSG?
by Beman Dawes 27 Jan '11

27 Jan '11

BOOST_STATIC_ASSERT predated C++0x static_assert, so it doesn't take advantage of static_assert's message argument when static_assert is available. It would break too much code to change BOOST_STATIC_ASSERT, but we can add a new macro that does take advantage of C++0x static_assert if available. After adding this to <boost/static_assert.hpp>: + #ifndef BOOST_NO_STATIC_ASSERT + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) static_assert(B, Msg) + #else + # define BOOST_STATIC_ASSERT_MSG( B, Msg ) BOOST_STATIC_ASSERT( B ) + #endif This test program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT_MSG( true, "should never fire" ); BOOST_STATIC_ASSERT_MSG( false, "should always fire" ); return 0; } Compiling with VC++ 10, which supports static_assert, produced: temp.cpp(7) : error C2338: should always fire Compiling with VC++ 9, which does not support static_assert, produced: temp.cpp(7) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] Comments? --Beman

6 6

[mpl] Metafunction to extract type
by Edward Diener 27 Jan '11

27 Jan '11

Does MPL already have a metafunction which takes a type, which is a nullary metafunction, and returns the nullary metafunction's nested type ? As in: template < class T > struct get_type : T { };

2 3

RE process (prospective from a retired FreeBSD committer)...
by Sean Chittenden 27 Jan '11

27 Jan '11

I originally sent this to Eric but am cleaning it up and reposting here per his suggestion. From an outsider's perspective it appears as though the lack of branching/merging tied to release management is the biggest issue for Boost at present. I'm a retired FreeBSD committer, I wanted to point out how the FreeBSD community deals with release engineering and see if there are a few nugget policies that could be cherry picked for boost. FreeBSD's process has been in place and refined for the last 15 years and comes with already written documentation as a starting point. It's not perfect, but there's a pound of prevention that comes via policy that no tool can replicate. head/trunk/tip is known as the -CURRENT branch. Released versions for production used (or are in prep for being released) are known as -STABLE branches. When FreeBSD 8 was being developed, people committed to HEAD (aka -CURRENT). When the re@ team called for a freeze for release and -CURRENT was in sufficiently good condition, they branched HEAD in to RELENG_8_STABLE. Everything in RELENG_8_* is expected to be production quality (or nearing it). Upon release of 8.0, RELENG_8 was branched again to RELEASE_8_0. 8.1, 8.2, etc were all created from RELENG_8_STABLE. Fixes for things in stable go to -CURRENT first, then are back patched to the appropriate stable releases, colloquially known as MFC's or Merge From -CURRENT. -CURRENT is the wild west of OS development and repo trash. Use at your own risk. Stability and likelihood of all tests passing is marginal, at best. Towards the end of a given major version -CURRENT becomes more stable, but once -STABLE has been branched it quickly degenerates some as people implement the impetus to checkin new features. -STABLE should always be passing 100% of the regression tests present in the branch at all times. A quick doc on merging between branches: http://wiki.freebsd.org/SVN_Merging I don't know how wide spread it is and despite svk having gone in to maintenance mode, use of svk has merit (partial checkouts): http://svk.bestpractical.com/view/HomePage http://www.freebsd.org/releng/ Anyway, the way that FreeBSD handles its permissions and merging from one branch to the next is via the commit message and commit hooks and approvals from different people wearing different hats. A few examples: http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008657.html has an MFC line in there to denote the changes included. The commit handler verifies that the diffed files largely match (at least it used to back in the day when I was committing via CVS). http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008683.html Reviewed by commit header. This gives greater latitude in terms of what can be included in the commit. http://lists.freebsd.org/pipermail/svn-src-stable/2011-January/008808.html And the 'Approved by' commit header. Once a release is frozen, all commits need to have this tag. The commit will fail without it and if someone commit with that line and didn't have permission to do so, as a policy, the commit is always reverted 100% of the time as a matter of principle. Frequently it's re-committed, but it's a big slap to the back of the hands to have to go through the process again. Needless to say, the commit mailing list is the most active and widely read list as a result. And tons of code gets reviewed with many eyes viewing it as a result. There are other bits worth noting, acls apply to different parts of the tree (doc-re vs src-re), but I don't know how many people actually follow boost's commit log on a per commit basis, but given 100% of all commits go to a single mailing list, it seems like the current list infrastructure makes that kind of review process unsustainable for Joe Reviewer (vs. the shorter abridged commit messages w/ a link to the actual diff). Lots of people fork FreeBSD to do experimental work out of the tree via git and hg, but the monolithic and serialized commit/review process seems to be working quite well from my perspective. A little bureaucratic but very stable and democratic without reliance on any one person to push the release forward. Anyway, food for thought. Hopefully there's something there that you can pick out of value. If you have questions, feel free to ask. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

----- "Robert Stewart" <Robert.Stewart(a)sig.com> wrote : > > That's a bad analogy. std::auto_ptr was deprecated, but not in favor > of another std::auto_ptr but rather by std::shared_ptr. That's off-topic but I think you meant unique_ptr instead of shared_ptr. Ivan.

2 1

[V1.46] [Iterator] Ask for release notes modification
by Michel MORIN 27 Jan '11

27 Jan '11

Hi, I have some comments on the Boost 1.46 release notes for Boost.Iterator. (http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_…) Here are the release notes for Boost.Iterator: * fixed problem with `implicit_cast` ([@https://svn.boost.org/trac/boost/ticket/3645 #3645]) * added `function_input_iterator` ([@https://svn.boost.org/trac/boost/ticket/2893 #2893]) * `transform_iterator` now uses `boost::result_of` to determine functor result type ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) The first item seems OK :) The second item needs to be deleted, since `function_input_iterator` is not merged into release branch. The third item also needs to be changed. As the release notes say, `transform_iterator` now uses `boost::result_of` to determine functor result type (in prior versions, it uses `result_type`). But there is a bug: it should use `boost::result_of<Iterator::reference>` as the documentation says, but it uses `boost::result_of<Iterator::value_type>`. (This was fixed in trunk a week ago, but it was too late to merged to release.) This bug makes subtle errors and confuses the users. Is it better to mention the bug in the release notes explicitly? Something like: * BUG: `transform_iterator` uses `boost::result_of<Iterator::value_type>` to determine functor result type instead of `boost::result_of<Iterator::reference>` ([@https://svn.boost.org/trac/boost/ticket/1427 #1427]) Or simply delete this item? Regards, Michel

6 11

Re: [boost] [string] proposal
by Ivan Le Lann 27 Jan '11

27 Jan '11

Artyom wrote : > > > > So you do not consider the fact the following code compiles (and > runs!) > > cleanly as a painful problem? > > > > std::string s = get_utf8_string(); > > s[42] = '?'; > > > > It is fine code. Why? Because if you assign s[42] you probably > know why you are do it and you most likely know that there is > a some ASCII character there. > I want more safety. And opacity is one way to it. I consider that stating "The code is OK because you know what you're doing" is an offense to all safety efforts put into C++ and its standard library. Sorry for the tone, but I failed to express my views in another way. Non throwing failures somewhat disturb me. Especially if you can design a failsafe interface. > > > I consider that std::string is cool as an internal for a > Boost.Locale > > implementor, not as a standard API for encoded strings that should > be > > used by all C++ developpers. > > > > Seems to me you hadn't seen Boost.Locale code and what does it > does. > I've seen it and toyed with it, and it's great. I have no problem with Boost.Locale, I have a problem with all the mess than can be done with the string type it has to publicly use today. And by the way, you're the one who stated that encoded string processing should be done by a domain expert library. I'm only exspecting you to translate this into : we need a more opaque string. Ivan

1 0

[threads] namespace & externs
by scot shinderman 27 Jan '11

27 Jan '11

Boosters, In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage? When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper. thanks! -s-

3 3