August 2008 - Boost - lists.boost.org

enable_shared_from_this changes since 1.35
by Michael Marcin 15 Aug '08

15 Aug '08

The changes made to enable_shared_from_this since 1.35 cause classes to be larger than they were before. I created a small test that I ran against 1.35 and the current trunk. These are the results for VC9 SP1 release mode. BOOST_VERSION = 103500 sizeof(SharedFromThisEnabled) = 8 sizeof(MultipleInheritanceDerived) = 12 sizeof(ChainedBaseDerived) = 12 BOOST_VERSION = 103600 sizeof(SharedFromThisEnabled) = 12 sizeof(MultipleInheritanceDerived) = 16 sizeof(ChainedBaseDerived) = 12 Did the changes made offer functionality worth the extra space? The MultipleInheritanceDerived pattern is recommended in most of the Boost.Asio examples. If the changes made truly offer some value perhaps a base class chaining version of enabled_shared_from_this should be provided. Thanks, Michael Marcin #include <iostream> #include <boost/enable_shared_from_this.hpp> #include <boost/version.hpp> class SharedFromThisEnabled : public boost::enable_shared_from_this<SharedFromThisEnabled> { public: }; class AbstractBase { public: virtual void Foo() = 0; }; class MultipleInheritanceDerived : public AbstractBase , public boost::enable_shared_from_this<MultipleInheritanceDerived> { public: virtual void Foo() {} }; #if (BOOST_VERSION==103500) template< class T, class Base > class enable_shared_from_this_chained_base : public Base { public: typedef T _internal_element_type; // for bcc 5.5.1 mutable boost::weak_ptr<_internal_element_type> _internal_weak_this; }; #elif (BOOST_VERSION==103600) template< class T, class Base > class enable_shared_from_this_chained_base : public Base { protected: // virtual destructor because we need a vtable for dynamic_cast from base to derived to work virtual ~enable_shared_from_this_chained_base() { } private: mutable boost::detail::weak_count _weak_count; mutable boost::detail::shared_count _shared_count; }; #else #error "Update enable_shared_from_this_chained_base implementation and version number" #endif class ChainedBaseDerived : public enable_shared_from_this_chained_base<ChainedBaseDerived,AbstractBase> { public: virtual void Foo() {} }; int main() { std::cout << "BOOST_VERSION = " << BOOST_VERSION << std::endl << "sizeof(SharedFromThisEnabled) = " << sizeof(SharedFromThisEnabled) << std::endl << "sizeof(MultipleInheritanceDerived) = " << sizeof(MultipleInheritanceDerived) << std::endl << "sizeof(ChainedBaseDerived) = " << sizeof(ChainedBaseDerived) << std::endl ; }

1 0

[1.36] Status?
by Michael Marcin 14 Aug '08

14 Aug '08

It looks like 1.36 is released on sf.net and tagged in subversion but there is no news or announcement of it and the boost.org website says the current version is 1.35. This leaves me a bit confused. Is 1.36 released or not? Thanks, Michael Marcin

2 1

[assign] syntax for creating an initially empty list --- request for feedback
by Thorsten Ottosen 14 Aug '08

14 Aug '08

Dear all, A user of boost.assign was doing the following: array<bool, N> temp = list_of<bool>().repeat(N, true); The problem in this context is that that list_of<T>() inserts a default constructed element, and that there is no way to avoid that. I proposed that we use the following syntax: boost::assign::list_of(boost::none) to say that the initial list is empty. Comments? -Thorsten

1 0

[interprocess] promoting boost::interprocess::detail::get_current_process_id
by JOAQUIN M. LOPEZ MUÑOZ 14 Aug '08

14 Aug '08

Hello, boost::interprocess::detail::get_current_process_id is a very nice utility to have. Would it be a good idea to promote it to the public interface of Boost.Interprocess? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Can multi-index do this?
by JOAQUIN M. LOPEZ MUÑOZ 14 Aug '08

14 Aug '08

Hi Daryle, ________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Daryle Walker [darylew(a)hotmail.com] Enviado el: jueves, 14 de agosto de 2008 8:08 Para: boost(a)lists.boost.org Asunto: [boost] Can multi-index do this? > > Is it possible for Boost.Multi-index, or anything else in Boost, to > make a container that is generally random-access (like vector or > deque) but efficiently allows removals anywhere (like list)? As Sebastian has already pointed out, it does not seem possible to have O(1) lookup and O(1) insertion/removal simultaneously. That said, Boost.MultiIndex has so-called random-access indices: http://www.boost.org/libs/multi_index/doc/tutorial/indices.html#rnd_indices which have O(1) lookup and very fast removal: although erasing an element is O(n), it does not actually incur any element shifting, as it is only an internal vector of pointers that gets adjusted. This can be much faster than std::vector removal when the elements are of moderate size (though, still, it is not O(1)). A drawback of random indices in comparison with std::vector is that elements of multi_index_containers are immutable. Incidentally, I happen to have recently implemented a *stable* vector, a container that mimics the interface of std::vector with the differences that element contiguity is not observed and, in exchange, the container is stable, i.e. iterators and references to the elements remain valid regarldess of the insertions/removals being performed. This container, again, has O(n) removal but no element shifting. If this is of your interest I plan to publish this little work in my blog (http://bannalia.blogspot.com ) during September. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 1

Boost.threads: Setting stack size
by Rajpal Dangi 14 Aug '08

14 Aug '08

Is it possible to set Boost thread stack size? How much is the default thread stack size? In the past also this question has been asked and I saw some answers which indicates that some work was in progress to set thread attributes at the time of its creation. http://lists.boost.org/Archives/boost/2002/06/30327.php Thanks

3 2

[fusion][parameter] a solution for named parameters / parameter packs using fusion maps
by Stjepan Rajko 14 Aug '08

14 Aug '08

Hello, I just realized that named parameters can be implemented rather nicely using fusion maps (I'm not sure whether this has been explored before). I threw together an implementation for two particular parameters/names, but the method could be easily generalized. Here are examples of functions taking parameter packs (label is a string, and size is a guigl::size_type which is a gil::point2 type) (...and don't worry about what guigl is): using namespace guigl::parameter; const std::string &function_taking_label(const pack<field::label>::type &args) { return args.label(); } const guigl::size_type &function_taking_size(const pack<field::size>::type &args) { return args.size(); } const guigl::size_type &function_taking_both(const pack<field::label, field::size>::type &args) { return args.size(); } Now you can do things like: function_taking_label(label("hello")); const guigl::size_type size_one(1,1); function_taking_size(size(size_one)); // parameters can be passed in any order function_taking_both(label("hello").size(size_one)); function_taking_both(size(size_one).label("hello")); // size has a default value function_taking_both(label("hello")); // extraneous parameters will be ignored function_taking_label(label("hello").size(size_one)); // empty parameter pack can be used for no parameters (all default values) function_taking_size(empty()); Here is the full test code: http://pastebin.com/f6b128a4b and the relevant implementation: http://pastebin.com/f584c7967 Compared to Boost.Parameter, I have a hunch that the Fusion approach would be faster to compile (haven't tested that though), and is a little bit less convoluted (esp. for certain cases like constructors using named parameters). I've never used Boost.Parameter so I'm not sure what other comparisons might apply. Any feedback welcome. Kind regards, Stjepan

7 22

Re: [boost] Unordered Link on beta.boost.org doesn't work
by Michael Goldshteyn 14 Aug '08

14 Aug '08

"Michael Goldshteyn" <mgoldshteyn(a)comcast.net> wrote in message news:<00c701c8fd9e$f8aa4e70$e9feeb50$@net>... > "Daniel James" <daniel_james(a)fmail.co.uk> wrote in message > news:<31f5f6790808130005s4b9df349xe34d161df2ba4bc3(a)mail.gmail.com>... > > On 13/08/2008, Hansi <hansipet(a)web.de> wrote: > > > > > the link under "New Libraries" "Unordered" doesn't work. > > > > Thanks for reporting this. A lot of the 1.36 documentation is > > currently missing. We're working on it. Until it's fixed, you can find > > the unordered documentation at > > http://www.calamity.org.uk/1.36/doc/html/unordered.html (I will change > > this to a redirect once the 1.36 documentation is fine). > > Speaking of Boost.Unordered, what is the reallocation strategy once a hash > table gets full, if that even makes sense (i.e., I suppose it depends on the > mechanism for collision resolution)? Is chaining used or some sort of open > addressing, in which case the hash table does need to be resized? Well, after reading the docs some more, it seems that: http://www.calamity.org.uk/1.36/doc/html/unordered/buckets.html answers most of my questions, already. Thanks

1 0

Re: [boost] Unordered Link on beta.boost.org doesn't work
by Michael Goldshteyn 14 Aug '08

14 Aug '08

"Daniel James" <daniel_james(a)fmail.co.uk> wrote in message news:<31f5f6790808130005s4b9df349xe34d161df2ba4bc3(a)mail.gmail.com>... > On 13/08/2008, Hansi <hansipet(a)web.de> wrote: > > > the link under "New Libraries" "Unordered" doesn't work. > > Thanks for reporting this. A lot of the 1.36 documentation is > currently missing. We're working on it. Until it's fixed, you can find > the unordered documentation at > http://www.calamity.org.uk/1.36/doc/html/unordered.html (I will change > this to a redirect once the 1.36 documentation is fine). Speaking of Boost.Unordered, what is the reallocation strategy once a hash table gets full, if that even makes sense (i.e., I suppose it depends on the mechanism for collision resolution)? Is chaining used or some sort of open addressing, in which case the hash table does need to be resized? Thanks, Michael Goldshteyn

1 0

Data-processing and serialization design questions
by Daryle Walker 14 Aug '08

14 Aug '08

If no one has noticed, I'm trying out a MD5 system on our Subversion server under "$ROOT/sandbox/md5/", hopefully to succeed Boost.CRC. (Let's use the skills & experience gained over the past... 7 years.) I'm sharing my design ideas to make sure I'm not missing anything. 1. The results of a MD5 run are encapsulated in the md5_digest class. It's actually a POD type, and the only supported operations are equality and streaming standard I/O. I couldn't think of anything else you would/could want to do with this type. 2. Although "everyone" writes MD5 functions as byte-running algorithms, it's actually a bit-running one. I've constructed my classes around bit-oriented operation, so maybe this'll bring a new perspective. I also use 64-bit integer types directly, instead of a pair on 32-bit integers like the "standard" implementations. (All the recent work on Boost.Integer was to enable this library.) 3. The computation of MD5 runs was completely encapsulated in the md5_computer class. Like Boost.CRC's design, this lets a run be done in piecemeal. There's also a function that does a single run over a buffer, that internally calls the computation class. Besides the actual computation work, the class had accessors to the current state of computation. I noticed that a lot of this code could be reused for other coding schemes, so I tried to create a hierarchy that spread the functionality. I felt that it got too unwieldy. I determined that the problem was that presentation and computation parts of the class burden each other. So I divided the class into the current md5_computer (presentation) and md5_context (computation) classes. The presentation class has a different hierarchy behind it, with more generics over OOP, but still contains a computation object. The computation class publicly has a producer-generator & consumer-functor interface, and its attributes cannot be accessed except for the associated presentation class, which is a friend. The system is like the I/O-streams' separation into stream and stream- buffer classes. Is this separation a good idea? 4. The presentation and computation classes have Boost.Serialization functionality. I originally planned to have serialization for the back-up classes, but I read a thread from May 2007 suggesting that the serialization model should match the user's model, not the implementation details, so those were skipped. 5. Note that the presentation and computation types only support Boost.S11n while the digest type only supports standard streams. Besides keeping the digest type POD, I didn't see a need to make the p/c types printable. (Now I just realized that you may want to save a MD5 in a data file. Maybe I'll work on serializing digests.) 6. Should the serialization routines be in the classes' headers, or move to separate implementation somewhere within Boost.Serialization (assuming this gets accepted, of course)? I think that Boost.Multi- Index puts s11n in its own headers, but that's because the design must be intrusive. It could be non-intrusive for the digest and presentation classes, but probably not the computation class. 7. I'll probably try out the framework on at least one more coding type. (I've read that a framework with only one concrete class is probably locked to just that class due to the programmer never having to confirm separation of concerns during testing.) 8. The usual byte-wise MD5 implementation probably does have a speed advantage over this library, since it can just dump bytes directly into a buffer until hashing time, then compute everything a byte at a time. This library forces CHAR_BIT calls for each byte submission, getting worse for buffer submissions. The library currently wastes space in the computation class, since it stores a 512-Boolean array. (A "bool" could rip off an unsigned-char, wasting CHAR_BIT - 1 bits, or an "int," wasting more space! This is probably why std::vector<bool> was invented.) Maybe switching to an unsigned-char array can fix both problems. 8a. After the switch at the end of [8], a byte-oriented wrapping variant of md5_context could be made that copies bytes directly into the inner object's buffer, and calls the hash-updater as needed. Note that the wrapping type would still do hash updates bit-wise; could/should they be byte-wise too? A byte-wise hashing optimization only works if CHAR_BIT is 8 (not even for higher integral powers of two), so is the potential effort worth it? How would I test both cases (octet-sized bytes and not)? Should I test both cases? Note that the direct-byte-copying part also has problems if 512 % CHAR_BIT != 0. 9. There's only Doxygen comments (which take up most of each file) for documentation. I guess that any Quickbook files would be more like general user guides. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0