April 2014 - Boost - lists.preview.boost.org

[GIT] Access
by Artyom Beilis 16 Apr '14

16 Apr '14

I hadn't committed changes for a while. >From what I've read in the mailing list there was a move to GIT and svn was closed. However I can't find information on the GIT at the boost site. Are we still using SVN? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 2

Re: [boost] -serialization- segfault on startup
by Biddiscombe, John A. 16 Apr '14

16 Apr '14

Andrey Thanks for the info. I purged every stray lib I could find - double checked all ld_library_path entries and discovered there was a shared lib from a previous build on my path which was almost certainly the culprit in this case. However, now the filesystem error has gone and I'm left with a very similar one which previously was bothering me from boost.serialization. This one I can't make disappear by cleaning paths because there's nothing bad left that might be a problem. I tried this time with boost_1.54 just to see if anything changed. does this stack trace look familiar to anyone? thanks JB #0 0x00000080a0b272f4 in ._dl_fixup () from /lib64/ld64.so.1 #1 0x00000080a0b2fd78 in ._dl_runtime_resolve () from /lib64/ld64.so.1 #2 0x00000fffb689869c in ._ZN5boost13serialization9singletonINS_7archive6detail22archive_serializer_mapIN3hpx4util24portable_binary_oarchiveEEEE12get_instanceEv () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_54_0/include/boost-1_54/boost/serialization/singleton.hpp:128 #3 0x00000fffb3a93008 in ._Z41__static_initialization_and_destruction_0ii () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_54_0/include/boost-1_54/boost/serialization/singleton.hpp:149 #4 0x00000fffb3a93064 in ._GLOBAL__sub_I_portable_binary_oarchive.cpp () at /gpfs/bbp.cscs.ch/home/biddisco/src/hpx/src/util/portable_binary_oarchive.cpp:207 #5 0x00000fffb3a969f8 in .__do_global_ctors_aux () from /gpfs/bbp.cscs.ch/home/biddisco/bgas/gcc/build/hpx/lib/hpx/libhpx_serializationd.so.0 #6 0x00000fffb3a89ae4 in ._init () from /gpfs/bbp.cscs.ch/home/biddisco/bgas/gcc/build/hpx/lib/hpx/libhpx_serializationd.so.0 #7 0x00000080a0b27bf0 in ._dl_init_internal () from /lib64/ld64.so.1 #8 0x00000080a0b154dc in ._dl_start_user () from /lib64/ld64.so.1

1 0

filesystem segfault on startup
by Biddiscombe, John A. 16 Apr '14

16 Apr '14

I’m using a BGQ machine and have compiled boost 1_55 using gcc4.8.2, the application I am testing does not use filesystem itself, but the libraries it pulls in do. On startup I have segfaults with a stack trace like this (below) Can anyone tell what is going wrong (lots of locale related problems on this machine it seems). I have no knowledge of boost.filesystem internals and I would like to work around this if possible. Thanks JB #0 0x00000080a0b272f4 in ._dl_fixup () from /lib64/ld64.so.1 #1 0x00000080a0b2fd78 in ._dl_runtime_resolve () from /lib64/ld64.so.1 #2 0x00000fffb6ef9384 in ._ZN5boost10filesystem18directory_iteratorC1Ev () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/include/boost/filesystem/operations.hpp:676 #3 0x00000fffb3aace44 in ._Z41__static_initialization_and_destruction_0ii () at libs/filesystem/src/operations.cpp:248 #4 0x00000fffb3aacf2c in ._GLOBAL__sub_I_operations.cpp () at libs/filesystem/src/operations.cpp:2230 #5 0x00000fffb3ab8a78 in .__do_global_ctors_aux () from /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/lib/libboost_filesystem.so.1.55.0 #6 0x00000fffb3aa32e4 in ._init () from /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/lib/libboost_filesystem.so.1.55.0 #7 0x00000080a0b27bf0 in ._dl_init_internal () from /lib64/ld64.so.1 #8 0x00000080a0b154dc in ._dl_start_user () from /lib64/ld64.so.1

2 1

filesystem segfault on startup
by Biddiscombe, John A. 16 Apr '14

16 Apr '14

I'm using a BGQ machine and have compiled boost 1_55 using gcc4.8.2, the application I am testing does not use filesystem itself, but the libraries it pulls in do. On startup I have segfaults with a stack trace like this (below) Can anyone tell what is going wrong (lots of locale related problems on this machine it seems). I have no knowledge of boost.filesystem internals and I would like to work around this if possible. Thanks JB #0 0x00000080a0b272f4 in ._dl_fixup () from /lib64/ld64.so.1 #1 0x00000080a0b2fd78 in ._dl_runtime_resolve () from /lib64/ld64.so.1 #2 0x00000fffb6ef9384 in ._ZN5boost10filesystem18directory_iteratorC1Ev () at /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/include/boost/filesystem/operations.hpp:676 #3 0x00000fffb3aace44 in ._Z41__static_initialization_and_destruction_0ii () at libs/filesystem/src/operations.cpp:248 #4 0x00000fffb3aacf2c in ._GLOBAL__sub_I_operations.cpp () at libs/filesystem/src/operations.cpp:2230 #5 0x00000fffb3ab8a78 in .__do_global_ctors_aux () from /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/lib/libboost_filesystem.so.1.55.0 #6 0x00000fffb3aa32e4 in ._init () from /gpfs/bbp.cscs.ch/home/biddisco/apps/gcc-4.8.2/boost_1_55_0/lib/libboost_filesystem.so.1.55.0 #7 0x00000080a0b27bf0 in ._dl_init_internal () from /lib64/ld64.so.1 #8 0x00000080a0b154dc in ._dl_start_user () from /lib64/ld64.so.1 -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82

1 0

[align] Review.
by Mostafa 15 Apr '14

15 Apr '14

For easier tracking by the Review Manager I am going to break up my review into multiple parts which will be top-level responses to this post.

3 10

[algorithm] any_of does not call std::find - bad performance
by Albert Yiamakis 15 Apr '14

15 Apr '14

Hello, Is there a particular reason why Boost.Algorithm's any_of does not call std::find? I have devised a simple benchmark that shows it to perform much worse (compiling with gcc): http://pastebin.com/nrgtTfPX boost::find is almost as fast as std::find - no surprises, as it calls it. any_of is considerably slower, whatever the optimization level. I have not dug in the implementation of std::find to determine why; perhaps the compiler recognizes this is a sorted range, perhaps it's even capable of doing the calculation at compile time. Whatever the case however, surely any_of should also call std::find to reap the same benefits? Albert

1 2

Re: [boost] [serialization] proposed improvements: forward-compatibility of serialization
by Andrzej Horoszczak 15 Apr '14

15 Apr '14

-------- Original Message -------- > From: Sohail Somani <sohail(a)taggedtype.net> > > This was a problem that interested me a few years ago so I made a > solution that worked with any archive and I presented it at BoostCon > (now CppNow). It was inefficient, hacky and required no modifications to > existing archives but forward compatibility did work so I know it is > completely possible. Do you have a specific link handy ? or do you perhaps remember project name so I could google it? > >My immediate question would be whether you already have released code >for the products in question which complicates things a bit. Fortunately we still have about 4-6 weeks before general release (-; > The proposal itself doesn't seem impossible, at a > glance. Thanks - that's promising (-; I believe that this approach should be more efficient and more elegant that Google's Protocol Buffers. And for us minimizing network traffic is of paramount importance. Andrew _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[serialization] proposed improvements: forward-compatibility of serialization
by Andrzej Horoszczak 15 Apr '14

15 Apr '14

Hello Everybody, (it seems that my previous post had contained only title - so I repeat the full posting below) We've started (again) using boost::serialization in our multi-platform distributed application about one year ago. However, we have arrived at a road block with forward-compatibility of serialization - which of major importance to us since we cannot force users to upgrade to the same/newer version of application all at the same time. Firstly, question is: perhaps you or someone that you know of - would be interested in such improvement work? We are small company rushed against some die-or-prosper deadlines - and simply do not have enough resources to do it on our own in time avialable - but we could sponsor such work. Secondly, the problem is: To avoid ambiguity I have put together the following description and our own suggestion for solution: The project requirement is centred on improving multi-version class compatibility in binary archives e.g. more flexibility in a situation when we are reading or transferring modified class in C++ code. We need to go beyond what current version of object versioning in boost offers: http://www.boost.org/doc/libs/1_55_0/libs/serialization/doc/tutorial.html#v… Specifically we need to add ability to skip reading unknown or unexpected fields in a non-XML archives we are parsing. Specific example: Version of the application (newer one) that saved the archive has the following code: struct extensionClass { std::string moreInfo; time_t date; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & moreInfo; ar & date; } } class gps_position { public: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees; ar & minutes; ar & seconds; ar & new_field } int degrees; int minutes; float seconds; extensionClass new_field; gps_position(){}; }; And now the version of the software that needs to read the archive is an older application that has the code that implements the gps_position class in the following way: class gps_position { public: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees; ar & minutes; ar & seconds; } int degrees; int minutes; float seconds; gps_position(){}; }; The purpose of the project is to gracefully allow for serialization in older version of application to continue reading the archive, by simply omitting information related to extensionClass new_field; e.g. to properly advance the read position to the beginning of next class in the archive. It is desirable to add to programming interface information that there was incompatibility detected, for further escalation to either to user interface, or higher level code logic that might decide, for instance, to change communication protocol. It is critically important for us to optimize archive size while adding this capability. We prefer to use eos::portable_iarchive which provides varinteger support for multi-OS compatibility (size of int, little vs big endian), therefore we prefer solution which would accept any archive, however, we will be ok with standard boost binary archive solution. Thirdly, the proposal is: The most promising solution that we envisage is to add recursive size information associated with the number identifying class (already placed in front of every data object). By recursive size information I mean size not in terms of bytes for raw data, but in terms of number of fields/objects in the class. The size information would than be expanded until it can be expressed in terms of C++11 standard predefined POD sizes. For instance for simple class example: class SimplePODs { uint32_t firstField, uint64_t int secondField; float thirdField; } The associated (leading) size information for the SimplePODs class is 3. Than within the class itself we already have identifiers of each field types. Since they are POD we can maintain global (and for the archive) dictionary of sizes for each identifier in this case: 4 than 8 and 4 And than it follows: class AggregateClass { SimplePODs first_field; char second_field; } In this case the size information (in the global dictionary) for identifier associated with AggregateClass is 2. Than within the class itself sizes for first_field would be 3 and for second_field it is of course 1. I believe this can be done as part of the version and object tracking process so the performance would still be high and most importantly, the incremental size overhead both in memory and in the archive will be relatively small (only one size information per each type of object contained in the archive - and no size overhead for POD fields). By the way this approach would also increase multi-OS compatibility for instance class on the source computer might be 32-bit compilation of : class CrossPlatform { int idont_care_about_size; } And during saving that field: idont_care_about_size would actually be saved and identified as uint32_t The same CrossPlatform class on destination machine would be compiled as 64-bit application - but since target int would be larger that source we can do silent promotion. Of course the other way around, we can throw exception if the actual value contained within idont_care_about_size exceeds the targets' compilation POD size. OK - I hope that my explanation is clear and I would appreciate any feedback that you might have. And finally let me state that we do greatly appreciate (and use) a lot of boost work and in particular, we consider boost.serialization approach to be probably the best possible under the current constrains of the language. Best regards, Andrew Horoszczak

6 5

[algorithm] LSD radix sort
by Jeremy Murphy 15 Apr '14

15 Apr '14

Dear community, I humbly offer you for perusal and review, LSD radix sort (and counting sort): https://github.com/jeremy-murphy/algorithm/tree/radix_sort The tests and docs are unfinished but the library code is as complete as I can manage without comment from others. The new files of interest are in include/boost/algorithm/integer_sort. I have more code with a speed test and CMake files in a separate repository: https://github.com/jeremy-murphy/integer-sort But perhaps I should move all those files into a branch off my Boost.Algorithm fork? Probably. Anyway, thanks in advance for any feedback and comments. Cheers. Jeremy

2 6

Amusing git pseudo-documentation
by Nat Goodspeed 15 Apr '14

15 Apr '14

Warning: this is not real. It just tickles me. http://git-man-page-generator.lokaltog.net/#72a7d7ff89dc3b268c857e3b2ddabff6 Apologies for the noise...

3 2