- Boost - lists.boost.org

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