- Boost - lists.boost.org

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

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 26 Dec '11

26 Dec '11

Hi everybody, I released a new version of the DE library based on feedback I received on the initial release - see the doc at http://www.amichel.com/de/doc/html. First of all, I updated the documentation to describe in more detail what DE is, its use in one specific case, and links to descriptions of several other use cases - see the Overview page at the link above. I hope this will help make the case why a DE library would be worth being included in boost. BTW, there are already implementations in several languages and for several free or commercial products: Java, C, Matlab, Scilab, Fortran90, Python, Labview, Pascal, C#, etc. As far as the library itself, Thomas Heller noted that requiring the objective functions to be derived from the de::objective_function abstract class limited the user options by not allowing arbitrary unnamed or plain functions to be passed as objective functions. I followed his suggestion and reimplemented parts of the library as template classes, in particular the de::processor class. It is now possible to pass objective functions as: named functions, unnamed functions, functors (all with the right prototype) or objective function factories which create local copies of the objective function. All of these can be passed as either references, plain pointers or boost::shared_ptr. This change should make it easier to integrate the library within existing code. Your comments will be appreciated. Adrian

1 0