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

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

[preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
by lcaminiti 18 Jan '12

18 Jan '12

Hello all, Why does Boost.Preprocessor redefines BOOST_PP_VARIAIDCS instead of just using BOOST_NO_VARIADIC_MACROS from Boost.Config? Furthermore, GCC supports variadics also when C++11 extensions are not enabled so I think the following should not && __GXX_EXPERIMENTAL_CXX0X__: // File: boost/preprocessor/config/config.hpp # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && __GXX_EXPERIMENTAL_CXX0X__ # define BOOST_PP_VARIADICS 1 Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-variadic-BOOST-PP-VAR… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

Fwd: How to build the documentation
by Pedro Larroy 11 Jan '12

11 Jan '12

---------- Forwarded message ---------- From: Pedro Larroy <pedro.larroy.lists(a)gmail.com> Date: Sun, Dec 25, 2011 at 7:35 PM Subject: How to build the documentation To: boost-docs(a)lists.boost.org Hi I created a small patch for libs/python/doc/tutorial/doc/tutorial.qbk How can I check that it builds correctly and generates propper html? Regards. Pedro.

5 8

[thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Hartmut Kaiser 05 Jan '12

05 Jan '12

VC10, SVN trunk: #include <boost/move/move.hpp> #include <boost/thread.hpp> int main() { return 0; } Results in: .../boost/thread/detail/move.hpp(28) : error C2995: 'remove_reference<T>::type &&boost::move(T &&)' : function template has already been defined .../boost/move/move.hpp(466) : see declaration of 'boost::move' IMHO, Boost.Thread needs to be changed to rely on Boost.Move for move semantics instead of defining its own implementation for boost::move(). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 13

[thread] feature request priority
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, here they are a list of 26 feature requests for Boost.Thread. The features are classified as high, middle and low cost (form my point of view of course) I would like to know which features would you like to find on the next release. Please could you choose 3 features and if possible one for each category, the idea been to provide 1 high, 1 middle and 2 low features for the next release. High #2100 <https://svn.boost.org/trac/boost/ticket/2100> thread fails to compile with -fno-exceptions <https://svn.boost.org/trac/boost/ticket/2100> #6195 <https://svn.boost.org/trac/boost/ticket/6195> Provide the standard time related interface using Boost.Chrono <https://svn.boost.org/trac/boost/ticket/6195> #6217 <https://svn.boost.org/trac/boost/ticket/6217> Make uniform Boost.Thread and Boost.Interprocess synchronization interface <https://svn.boost.org/trac/boost/ticket/6217> #6230 <https://svn.boost.org/trac/boost/ticket/6230> Follows the exception reporting mechanism as defined in the c++11 <https://svn.boost.org/trac/boost/ticket/6230> #5150 <https://svn.boost.org/trac/boost/ticket/5150> boost::thread does not print or return the error value when creating a thread fails. <https://svn.boost.org/trac/boost/ticket/5150> #6194 <https://svn.boost.org/trac/boost/ticket/6194> Adapt to Boost.Move <https://svn.boost.org/trac/boost/ticket/6194> Middle #2741 <https://svn.boost.org/trac/boost/ticket/2741> proposal to manage portable and non portable thread attributes <https://svn.boost.org/trac/boost/ticket/2741> #2880 <https://svn.boost.org/trac/boost/ticket/2880> Request for Thread scheduler support for boost .. <https://svn.boost.org/trac/boost/ticket/2880> #3696 <https://svn.boost.org/trac/boost/ticket/3696> Boost Thread library lacks any way to set priority of threads <https://svn.boost.org/trac/boost/ticket/3696> #4710 <https://svn.boost.org/trac/boost/ticket/4710> Missing async() <https://svn.boost.org/trac/boost/ticket/4710> #4725 <https://svn.boost.org/trac/boost/ticket/4725> Synchronization and shared mutex's Get total_count <https://svn.boost.org/trac/boost/ticket/4725> #5173 <https://svn.boost.org/trac/boost/ticket/5173> boost::this_thread::get_id is very slow <https://svn.boost.org/trac/boost/ticket/5173> #5425 <https://svn.boost.org/trac/boost/ticket/5425> This patch will allow the user to obtain the users thread pointer from a thread group. <https://svn.boost.org/trac/boost/ticket/5425> #5956 <https://svn.boost.org/trac/boost/ticket/5956> Add optional stack_size argument to thread::start_thread() <https://svn.boost.org/trac/boost/ticket/5956> #6227 <https://svn.boost.org/trac/boost/ticket/6227> Use of variadic templates on Generic Locking Algorithms on compilers providing them <https://svn.boost.org/trac/boost/ticket/6227> #6228 <https://svn.boost.org/trac/boost/ticket/6228> Add promise and futures constructor with allocator following the standard c++11 <https://svn.boost.org/trac/boost/ticket/6228> #6229 <https://svn.boost.org/trac/boost/ticket/6229> Rename the unique_future to future following the c++11 <https://svn.boost.org/trac/boost/ticket/6229> Low #1789 <https://svn.boost.org/trac/boost/ticket/1789> thread_group not passing variables <https://svn.boost.org/trac/boost/ticket/1789> #1850 <https://svn.boost.org/trac/boost/ticket/1850> request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock <https://svn.boost.org/trac/boost/ticket/1850> #2361 <https://svn.boost.org/trac/boost/ticket/2361> thread_specific_ptr: nature of the key, complexity and rationale <https://svn.boost.org/trac/boost/ticket/2361> #2637 <https://svn.boost.org/trac/boost/ticket/2637> shared mutex lock <https://svn.boost.org/trac/boost/ticket/2637> #3567 <https://svn.boost.org/trac/boost/ticket/3567> Request for shared_lock_guard <https://svn.boost.org/trac/boost/ticket/3567> #6224 <https://svn.boost.org/trac/boost/ticket/6224> Add the use of standard noexcept on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6224> #6225 <https://svn.boost.org/trac/boost/ticket/6225> Add the use of standard =delete defaulted operations on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6225> #6226 <https://svn.boost.org/trac/boost/ticket/6226> add explicit bool conversion from locks <https://svn.boost.org/trac/boost/ticket/6226> #6231 <https://svn.boost.org/trac/boost/ticket/6231> Add BasicLockable requirements in the documentation to follow c++11 <https://svn.boost.org/trac/boost/ticket/6231> Patches are welcome for any feature. Note that a feature that have all the needed patches, code, doc and tests could be included soon. Thanks in advance, Vicente

3 7

[thread] Reducing the number of open tickets.
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, I have committed the following tickets in trunk. Fixed Bugs: * [@http://svn.boost.org/trac/boost/ticket/2639 #2639] documentation should be extended(defer_lock, try_to_lock, ...). * [@http://svn.boost.org/trac/boost/ticket/3762 #3762] Thread can't be compiled with winscw (Codewarrior by Nokia). * [@http://svn.boost.org/trac/boost/ticket/3885 #3885] document about mix usage of boost.thread and native thread api. * [@http://svn.boost.org/trac/boost/ticket/3975 #3975] Incorrect precondition for promise::set_wait_callback(). * [@http://svn.boost.org/trac/boost/ticket/4480 #4480] OpenVMS patches for compiler issues workarounds. * [@http://svn.boost.org/trac/boost/ticket/4819 #4819] boost.thread's documentation misprints. * [@http://svn.boost.org/trac/boost/ticket/5423 #5423] thread issues with C++0x. * [@http://svn.boost.org/trac/boost/ticket/5739 #5739] set-but-not-used warnings with gcc-4.6 * [@http://svn.boost.org/trac/boost/ticket/6168 #6168] recursive_mutex is using wrong config symbol (possible typo). * [@http://svn.boost.org/trac/boost/ticket/6200 #6200] patch to have condition_variable and mutex error better handle EINTR. These are tickets with a simple solution or that had associated a complete patch or a clear solution. Anthony I would prefer that you do the merge so that you can check what goes on the release version. I have not closed the tickets. These tickets have just release 1.49 as Milestone. Please, close them when you merge to release. There were 113 tickets two days ago. There are now 114 tickets associated to Boost.Thread. I have closed some duplicates, but some news tickets have been created since. I would like to reduce by 10% the number of tickets every month. I encourage the Boost users that have created tickets for Boost to provide a clear an complete patch when possible so that we can reduce together the number of tickets associated to this Boost library and make it more portable/usable. Don't forget to provide tests that make evident the bug, or to add doc when you are proposing a anew feature. There are a lot of tickets associated to move semantics emulation. I have created a ticket to adapt Boost.Thread to Boost.Move hoping most of these bugs will be solved. As posted in another thread there is already a patch using Boost.Move that could be a good starting point. Of course the help offered by Ion will be too much appreciated. I have created another to adapt the interface to Boost.Chrono, but I will prefer to take care of this once the one for Boost.Move adaptation is committed, as the chance of collisions is big. On the mean time I will continue with some tickets specific to Windows platform. Best, Vicente

4 12

How to get involved ?
by Vijeenrosh PW Vijeen 03 Jan '12

03 Jan '12

Good Morning , My name is Vijeenrosh P.W . Iam an Computer Science and Engineering student . I have knowledge in c,c++,python and linux , and an mind to extend my areas of knowledge. Recently while passing through the list of GSOC accepted organizations I met with boost libraries . it fits me since I have C++ && programming knowledge and is ready to work . I would like to know how to begin to contribute to the project . Where to begin . or is there any warm up excersices to get passed ? -- Vijeenrosh P.W CSE S3 blog : www.BlackJackVijeen.blogspot.com

4 3

RFC: Multiprecision arithmetic library
by John Maddock 03 Jan '12

03 Jan '12

Folks, I'd like to get some feedback on a multiprecision arithmetic library I've been preparing for possible Boost inclusion. The code is in the sandbox under the "big_number" directory. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… The main features are: * A generic front-end that's capable of wrapping almost any type that's a "number". The front end is expression template enabled and handles all the expression optimization and code reduction. For example it's possible to evaluate a polynomial using Horner's rule without a single temporary variable being created. * A series of backends that need only provide a reduced interface and set of operations, implement the actual arithmetic, currently supported backends are: Integer Types ~~~~~~~~~ 1/ GMP (MPZ). 2/ libtommath. Rational Types ~~~~~~~~~~ 1/ GMP (MPQ). [ But note that the integer types can also be used as template aruments to Boost.Rational ] Floating Point Types ~~~~~~~~~~~~~~ 1/ GMP (MPF) 2/ MPFR 3/ cpp_float - an all C++ Boost-licensed backend based on Christopher Kormanyos' e_float code. [ Note these three types are fully compatible with Boost.Math Trunk - so you get full standard library plus special function support ] There's still a bunch to do, but I'd like to see what folks think, and where the main priorities should be before submission. Thanks in advance, John.

12 19

boost modularisation status?
by Robert Ramey 02 Jan '12

02 Jan '12

https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years. Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this. What is the current status of this? Robert Ramey

9 22

[Graph] LEDA adapter - concept check VertexListGraph fails
by Jens Müller 01 Jan '12

01 Jan '12

Hi everyone, when running the tests for Graph, the first concept check in leda_graph_cc.cpp fails: gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:9:0: ../../../boost/graph/graph_concepts.hpp: In destructor 'boost::concepts::VertexListGraph<G>::~VertexListGraph() [with G = leda::GRAPH<int, int>]': ../../../boost/graph/graph_concepts.hpp:168:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::VertexListGraphConcept<leda::GRAPH<int, int> >]' leda_graph_cc.cpp:21:5: instantiated from here ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' ../../../boost/graph/graph_concepts.hpp:189:9: note: candidate is: ../../../boost/graph/graph_concepts.hpp:45:48: note: template<class T> typename T::ThereReallyIsNoMemberByThisNameInT boost::vertices(const T&) (among some further errors, but I'd like to ask just about this one now) Apparently it cannot find a vertices() function: ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' But there is one in leda_graph.hpp: template <class vtype, class etype> inline std::pair< typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator, typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator > vertices(const leda::GRAPH<vtype,etype>& g) { typedef typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator Iter; return std::make_pair( Iter(g.first_node(),&g), Iter(0,&g) ); } So, can someone enlighten me why it isn't found? Has it something to do with #ifdef BOOST_VECTOR_AS_GRAPH_GRAPH_ADL_HACK // dwa 2003/7/11 -- This clearly shouldn't be necessary, but if // you want to use vector_as_graph, it is! I'm sure the graph // library leaves these out all over the place. Probably a // redesign involving specializing a template with a static // member function is in order :( using boost::vertices; #endif ? Best regards, Jens

2 8

Many Boost.Test unit tests fail
by Barend Gehrels 01 Jan '12

01 Jan '12

Hi, Since today or yesterday, many regression tests fail. http://www.boost.org/development/tests/trunk/developer/summary.html I believe on platforms that are recently added, at last on platforms that were not present at December 17. 1) on clang/darwin, message ../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' 2) on clang/linux, message /usr/bin/ld: skipping incompatible /sierra/Sntools/extras/compilers/gcc-4.4.4/lib/libstdc++.so when searching for -lstdc++ We have these errors in Boost.Geometry but I also noticed them in many other libraries. Regards, Barend

2 2

[filesystem] path thread safety fix impact on POSIX systems
by Beman Dawes 01 Jan '12

01 Jan '12

Class path locale initialization has suffered from a data race for several releases. See https://svn.boost.org/trac/boost/ticket/6320 for an example of code that suffers as a result. The problem was introduced when locale initialization was changed from namespace scope initialization to function scope initialization. For Windows and Mac OS X, the fix is simply to change back to namespace scope initialization. For non-BSD based POSIX systems such as Linux, the problem is more complex. These system need std::locale(""), "the locale-specific native environment". Considerations: * std::locale("") will throw if environmental variables are configured incorrectly. For example, setting LANG=foo on my Ubuntu system causes std::locale("") to throw. * std::locale("") is only needed if conversions between wide and narrow character paths occur in the program, so it would be unfortunate to have programs throw that don't actually do any such conversion. * With GCC, std::locale("") at namespace scope will throw before main() has started! That prevents catching the exception in the user code, and was what led to moving the initialization to a function scope static. Initialization as a function scope static also meant that the exception only occurred if user code actually performed wide - narrow conversions. I can see two possible fixes: (A) Use function scope locale initialization, using boost/detail/lightweight_mutex.hpp to prevent data races. (B) Use namespace scope locale initialization, defaulting the codecvt facet to UTF-8 if std::locale("") throws. The advantage of (B) is that path always initializes without throwing, and that's what users seem to expect. The initialization is correct for all those whose environments are configured correctly, and for those uses who want UTF-8 even if their environments are misconfigured. The POSIX users who prefer an exception on a misconfigured environment can always add a std::locale("") at the start of main(). Comments or opinions? --Beman

4 6

Re: [boost] matrix and vector iterators
by Larry Evans 31 Dec '11

31 Dec '11

On 06/12/01 14:50, David Abrahams wrote: > > ----- Original Message ----- > From: "Larry Evans" <jcampbell3(a)prodigy.net> > > >> David Abrahams wrote: >> >>> One problem with this is that it requires much more of the iterator in > some >>> cases than it otherwise might. In an array stored as vectors of vectors >>> of... vectors, each iterator would need to have references to all of the >>> containing vectors. >> >> Couldn't the iterator just contain a vector of indices of length == rank, >> and a pointer to the vector of vectors of... vectors (VofV), and then just > index into >> the VofV with the vector of indices. > > When you start talking about iterators containing vectors, I get worried. > >> I guess bad thing about that is that it takes longer. > > That's putting it mildly. Iterators should be lightweight. > > -Dave > > Another type of iterator which essentially flattens a multi-dimensional array and *may* be more lightweight is implemented here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/b… and demonstrated here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… A more realistic demonstration is in the Partial Differential Equation example here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which uses an axes rotation feature that, IIUC, was requested by Petros here: http://article.gmane.org/gmane.comp.lib.boost.user/68017 Its also used here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which is probably a bit easier to follow than the array_dyn.diff_pde.cpp one ;) I've done no benchmarks; hence, I can't say how lightweight it is; however, since all it does is keep a stack of indices in a data structure instead of on the stack, I would think it wouldn't be that much more heavyweight than simply a nested for loop nested N deep where N is the array dimensionality. BTW, Petros, in a private email to me, has indicated he has some other method for solving the rotated axes problem; however, I've no idea if that's more or less lightweight than this one. -regards, Larry I've run no benchmarks to show how lightweight it may be. Petros, in a private email to me, says he has another way of

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 31 Dec '11

31 Dec '11

Dave Abrahams: > > No post-hock marshalling? You should be able to add marshalling to a > class without modifying its declaration. > If a class is popular enough, I often do. For example, the C++ Middleware Writer (CMW) has support for the standard containers, std::complex, multi_index_container, stable_vector and others. [...] > > No argument; I'm just sayin'. I don't have to go to any great lengths to find tests where the performance of executables that use Boost Serialization lags behind CMW based executables. I just think up a test and write it. The tests are quite basic. > > That's a fundamentally intrusive design; being able to add serialization > non-intrusively was a major design goal for Boost.Serialization. I see. One thing I didn't mention yesterday is support for stream- based constructors: class Base { template <typename R> explicit Base (ReceiveBufferFile<R>& buf); ... }; Does the Boost Serialization library have support for that? Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Pool lost singleton_default -- replacement?
by Steve M. Robbins 31 Dec '11

31 Dec '11

Hi, Prior to 1.48, Boost.Pool's singleton_pool class used a helper class singleton_default. This was hidden in a detail header <boost/pool/detail/singleton.hpp>, yet I found 3 programs in the Debian distribution that used it directly to instantiate their own singletons. I didn't find any direct replacement for singleton.hpp in Boost 1.48. Is there any plan to introduce this later? Thanks, -Steve

3 2

Boost 1_41 Binary archive exceptions
by KARAN 31 Dec '11

31 Dec '11

I am porting from Linux 32 bit to 64 Bit(x86_64)(Boost Version :1_41). I am facing an Binary archive exceptions mainly (std::bad_alloc,St12length_error-basic_string::resize). There are no exception during the file saving, but when I do a restore I am facing the above exceptions. The same works very well if I change it to text archives. How can I make it work with binary files? The exception is happening in the below code block .Any comments please template<class Archive> void Serialise (Archive & aArchive, const unsigned int aVersion=0) { aArchive & this->A; aArchive & this->B; aArchive & this->C this->p.Serialise(aArchive, aVersion); } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-41-Binary-archive-exceptions-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[interprocess] Timed locks
by Edward Diener 29 Dec '11

29 Dec '11

In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ? I think an end-user calculation is usually one in which he says that a certain lock needs to be acquired in so many seconds ( or milliseconds ) and a boost::posix_time::time_duration would fit that calculation better.

4 5

[MPL] "Unwrap" metafunction
by Robert Kawulak 29 Dec '11

29 Dec '11

Hi, I need a metafunction to check if a type is wrapped as an argument of a template and "unwrap" it if so. Something like: template <template <typename> class T, typename C> struct unwrap { typedef C type; static const bool is_wrapped = false; }; template <template <typename> class T, typename C> struct unwrap<T, T<C>> { typedef C type; static const bool is_wrapped = true; }; So both unwrap<x, int>::type and unwrap<x, x<int>>::type are int, while unwrap<x, y<int>>::type is y<int>. Of course I can use the code above, but I'm just curious - does Boost.MPL already provide a utility that can be used to achieve the same? Thanks and best regards, Robert

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

Robert Ramey: > This first came up several years ago and I spent a little time looking at > it. > I was sort of intrigued in that the usage of TMP driven inline code should > be optimal for cases where tracking wasn't involved. And in these test > cases there isn't any tracking. So I looked a little at the tests on the > page. > > a) first I couldn't compile them so I couldn't repeat the results. > Something > was missing (I forget what now). I believe you are referring to something from several years ago here. > b) so I inspected the code. My conclusion was that the being used was > that in the i/o itself rather than the serialization. Boost serialization > relies > on streambuf to do it's i/o and the time is sensitive to things like buffer > sizes > etc. It seems that brian's code uses some other method which whose > source isn't visible to me. (SendBuffer, etc). This sounds like the present. Did you download and build the archive here -- http://webEbenezer.net/build_integration.html ? (Also in an earlier note today I mentioned recent changes to the test archive here -- http://webEbenezer.net/comp/tests.tar.bz2 .) > c) Brian did point out some cases where boost serialize could be improved > particularly using hints in std collections. These were incorporated. I > also > implemented the binary i/o in terms of streambuf rather than stream which > was a noticible improvement. Yes, now it would probably not be difficult to add support for ::std::move. I'm asking for someone to open a ticket for that so someone doesn't ask me to. ;) [...] > e) So, given tat the timings aren't that far apart, and lacking any other > information, I'm inclined to attribute any discrepencies to the way i/o is > handled > in the different systems. If one had nothing else to do he could make > a replacement for streambuf which focused on fast i/o perhaps at the > expense of portability. In particular, an asyncronous memory mapped i/o > library might be an interesting addition to boost. And that would be cool > to plug in the serialization library. While true that the timings aren't real far apart, I note that the timings of the (slightly) more complicated tests are worse for the Boost Serialization library than the simpler tests. Real uses have more than a vector<deque<double> > of complication. So there may be a compounding effect, but I'm just speculating. > Finally, I think that the scale and breadth of brian's library is much, much > smaller than boost serialization library. The breadth is smaller. I don't support text or XML based serialization. > Then there is the fact that the > distribution model is totally different than that of boost and open source > libraries in general. I just don't see how these packages/approaches > could be considered comparable in any way. While the distribution models are different, I think the binary part of the Boost Serialization library is comparable to the Ebenezer approach. Thanks for mentioning the distribution model. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I found an error that affects two of my test cases -- not comparing apples to apples -- so have updated the page I linked to and the archive with the tests. Only one of the tests showed different results after the change. Rather than claiming the Boost Serialization version of the test was over 3 times slower than the Ebenezer version, I now claim it is over 2.3 times slower. Dave Abrahams: > A few: > > 1. The claim that you provide "full generation of marshalling functions" > is a little hard to swallow. In principle, it's impossible to know > based on a class declaration what to serialize, and how to serialize > it. True. In order to turn off the default generation of marshalling code, one can place a comment like this: // hand_written_marshalling_code in the body of a class. Instances of that class can still be marshalled if you provide the expected marshalling functions yourself. > 2. If you are going to compare yourself to Boost.Serialization, it would > be a good idea to replicate all of that library's tests with your own > system, to demonstrate that you cover the same expressive range. We don't cover the same range, but are working to add to the reperoire. We do have support for some things that the Boost library doesn't: iterator_range, sub_range, several Boost Intrusive containers, flex_string, segmented_array and a few others. To the best of my knowledge Boost Serialization doesn't take advantage of ::std::move. http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html I've checked the 1.48 code also. > It's usually very easy to build something that beats benchmarks of a > more-general system. Well, this is the first time I've had an archive with the tests that I link to, so at least think that is a step in the right direction. > 3. That "our approach writes marshalling functions based on the content > of the types involved" does not explain how you get past the private > member access barrier. The only legal technique I've seen for that > is at https://gist.github.com/1528856, and Boost.Serialization should > probably have support for that approach. C++ Middleware Writer users add function prototypes to their classes. The first two links on this page -- http://webEbenezer.net/rbtree_marshalling.html show an example. In that example the marshalling functions are virtual. In general they aren't required to be. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Extension - any plans?
by Klaim - Joël Lamotte 29 Dec '11

29 Dec '11

Hi, I'd like to know if there are plans from it's author to submit Boost.Extension library for inclusion in boost? ( http://boost-extension.redshoelace.com/docs/boost/extension/index.html) Or any other plans? I remember the development was paused until some C++11 features would be available (I don't know which ones). But maybe I'm wrong. In my opinion, this library would be an excellent addition to boost. Joël Lamotte

1 1

Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I've recently updated a page -- http://webEbenezer.net/comparison.html comparing results obtained using Boost Serialization (1.48) and the C++ Middleware Writer (1.13) on both Linux and Windows7. There's an archive that has all the test files mentioned on that page here -- http://webEbenezer.net/comp/tests.tar.bz2 . In order to build the tests, you would need to build the Boost Serialization library and an Ebenezer library yourself. There's an archive on this page that has the Ebenezer library -- http://webEbenezer.net/build_integration.html . To summarize the results, the Boost versions range from 1.1 to 3 times slower than the Ebenezer versions. And the sizes of the Boost executables range from portly to obese compared to functionally equivalent Ebenezer executables. Comments on the how to improve the tests/process/etc. are welcome. Shalom Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 6

Is there any interest in command line interpreter class templates?
by alexey.tsoy 29 Dec '11

29 Dec '11

Hello everybody, The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation. The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent. The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it. Regards Alexey -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Re: [boost] [Spirit-general] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules
by Jeroen Habraken 29 Dec '11

29 Dec '11

Hi, On 27 December 2011 00:51, Torsten Maehne <Torsten.Maehne(a)gmx.de> wrote: > Hello, > > I'm using Boost.Spirit.Karma to format the output of some nested structs > (direct access of the public member variables) and abstract data types > (ADTs) (access to the private member variables via getters and setters) > in my code. I'm using Boost.Fusion to adapt the ADTs into a sequence of > values of primitive data types for output with Boost.Karma. This worked > fine till Boost 1.44. Since Boost 1.45 up till 1.48 and the current > Boost trunk (I tested svn revs 75505, 75963, and 76196) the output of unsigned > integer members of Boost.Fusion-adapted ADTs doesn't work anymore -- > even though I took into account the change in the name of macro from > BOOST_FUSION_ADAPT_CLASS to BOOST_FUSION_ADAPT_ADT as well as the > additionally required header > boost/spirit/include/support_adapt_adt_attributes.hpp. > > The problem is demonstrated in the attached test case for rational > number ADTs and structs, which use signed integer member > variables. Compilation of this test case against Boost 1.44.0 will > succeed and it will run without any errors. Compilation of this test > case against Boost 1.45.0 and 1.46.1 will fail. Compilation against > Boost 1.47.0 and 1.48.0 will succeed, but the output of negative values > of signed integer members of Boost.Fusion-adapted ADTs will be > wrong. The minus sign is output correctly, but it is followed by a wrong > value, which seems to be yielded by a cast from a signed to an unsigned > integer value instead of taking the absolute value of the signed integer > value. This has been observed on Mac OS X 10.7.2 (x86_64) with Xcode 4.2 > using Apple's g++ 4.2.1, Apple's clang++ 3.0. Interestingly, compiling > the test case against Boost 1.47.0 or Boost 1.48.0 using MacPorts g++ > 4.5.3, will yield more output checks to fail for Boost.Fusion-adapted > ADTs used in Karma output rules. > > Compilation against Boost from the Subversion trunk (I tested > revs. 75505, 75963, and 76196) does only succeed using Apple's clang++ > 3.0 and execution will yield the same wrong output for negative values > of signed integer members of Boost.Fusion-adapted ADTs. Compilation > fails with Apple's g++ 4.2.1 and MacPorts g++ 4.5.3. > > I'm not able to locate the root cause for this problem, whether it is in > Boost.Fusion or Boost.Spirit.Karma. I would appreciate any help to > resolve this annoying issue. Until a solution is found, I'm stuck with > Boost 1.44.0. Several things seem to play a role, but I've had a look at as to why the code doesn't compile using boost-trunk and found the cause to be an ambiguity: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. > Please note that I also submitted a bug report on this issue more than 6 > weeks ago without any reaction so far: > > <https://svn.boost.org/trac/boost/ticket/6126> > > Best regards, > > Torsten Maehne Note: I've included boost(a)lists.boost.org in the discussion. Kind regards, Jeroen Habraken

2 6