- Boost - lists.boost.org

[serialization] Technique used for registration of derived through base ( Abrahams wizardy )
by Sebastian Karlsson 11 Oct '11

11 Oct '11

A good while ago I got interested in how the registration process works in boost::serialization, I was never able to understand how the technique works, even if the gist of it is contained in 2 fairly small headers ( boost/serialization/export.hpp & boost/archive/detail/register_archive.hpp ). It would seem the creator of the technique is David Abrahams, so I'm hoping he or anyone else which understands how the registration process works could explain the technique used. >From my understanding it solves the problem of having 2 different sequences of types, and then being able to operate on all the combinations. All the techniques I've seen used previously for this requires the maintenance of some sort of compile time vector of one of the sequences. This is very cumbersome, not only does it needs to manually managed, but the file that defines the vector turns into a large dependency bottleneck. From my understanding the technique used in boost::serialization currently one sequence simply adds an overload to a free function, then at the registration point of the other sequence just having the overloads considered at compile time causes the magic to happen when the return type needs to instantiated. Unless I'm missing something obvious I think it would make for a very interesting subject of an article or discussion on the mailing list. Kind regards, Sebastian Karlsson

1 0

operator traits: ready for addition
by Frédéric Bron 11 Oct '11

11 Oct '11

Dear John, Included is are 2 patches vs trunk with operator traits additions: - boost_type_traits.patch.bz2 to be applied in boost/type_traits - libs_type_traits.patch.bz2 to be applied in libs/type_traits I have also updated the sandbox: :http://svn.boost.org/svn/boost/sandbox/type_traits/ This new version addresses all review comments. Tested with gcc 4.6.1 and intel-linux 12.0. Could be nice if somebody could run the tests with msvc. Hope everything is fine. What would be the best way to add it to the trunk? Regards, Frédéric PS: sorry for the long delay but it is very hard to find some free time with a job and a family.

2 2

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 11 Oct '11

11 Oct '11

On 10/10/2011 4:50 PM, Joel de Guzman wrote: > Everything's green now, Eric. The problem was not pervasive after > all; just a couple of fixes solved everything. Whew! > There's no need to revert. It makes me wonder though if we've missed > something that will blow up in the future. I'll probably have to > scrutinize classes that use proto::extends and check for overloads. The problem is that Spirit defines its own operator overload(s) that compete with Proto's. The officially sanctioned way of doing this with Proto is to use a grammar to restrict Proto's overloads, and then define your own. Admittedly, Proto's docs could be more clear about best practice here. > You might want to warn other proto users of this potential > breaking change. This will need to be mentioned in the release notes, yes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 11 Oct '11

11 Oct '11

On 10 Oct 2011 10:32:53 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: > Den 07-10-2011 20:45, Joe Mucchiello skrev: >> On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten > Ottosen<thorsten.ottosen(a)dezide.com> wrote: >> >>> Den 06-10-2011 18:27, Phil Endecott skrev: >>>> Thorsten Ottosen wrote: >>>>> Even better, don't use vector<const char*>. What o > you need that for? >>> [snip] >>>> >>>> Here's a real motivating example where I want to use > vector<const >>>> char*>. I have a large file containing null-terminated strings > which I >>>> memory map. After opening the file, I construct some sort of index > of >>>> those strings in a sorted vector. Then I search for things using >>>> std::equal_range, std::lower_bound, or similar. >>> >>> That's a good example, I grant you. >> >> >> I actually have a helper class for this called cstrptr which is a typedef > for the template class >> >> basic_cstrptr<char>. It is a "dumb" wrapper around const > char * that provides some std::string >> > > Also, something like iterator_range<const char*> might be somewhat more > handy to store in the vector. Perhaps in the generic case, but as I said, my class is for magic text found in programs and you practically never need to run generic algorithm against lists of magic text. The value in my class is that it is basically the same size as a pointer to char and has a near nop constructor. But my class might be too specific for boost based on the lack of any reaction to the concept. It is just a little fluff class. Joe

1 0

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 10 Oct '11

10 Oct '11

On 10/10/2011 2:08 AM, Joel de Guzman wrote: > On 10/10/2011 1:52 PM, Joel de Guzman wrote: >> On 10/10/2011 12:38 PM, Eric Niebler wrote: >>> >>> Bummer. I suggest adding an rvalue ref overload of operator%= that >>> shares an implementation with the const lvalue one. Should just be a few >>> lines of code. Is that a problem? >> >> Not really a problem. But, %= is just an example of the problems >> (plural with an s). We suspect that it is more widespread. I'll >> see how pervasive the changes need to be and get back to you. > > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. > > Hartmut, I committed the fix for Qi and Karma. Can you please > take a look at the Lex regressions? There's a good chance > that the problem with the examples is also related to the Lex > problem. I just ran the spirit_v2/lex and spirit_v2/lex_regressions test suites on msvc-10.0, and everything passed for me. Is this fixed already? Let me know asap so I know whether to revert my Proto changes. (Note: If they don't make it in this time, these Proto changes will eventually go back in for next release, so Qi/Karma/Lex will need to be fixed eventually.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Mathias Gaunard 10 Oct '11

10 Oct '11

On 10/10/2011 11:08, Joel de Guzman wrote: > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. Does it work without errors when enabling optimizations? It could be a problem with the lifetime of references.

1 0

multi_index bug?
by Olaf van der Spek 10 Oct '11

10 Oct '11

Hi, I've got this container: typedef boost::multi_index_container< torrent_t, boost::multi_index::indexed_by< // boost::multi_index::hashed_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::ordered_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::sequenced<> > > torrents_t; I'm using the find() member to find elements. When I use hashed_unique, it seems to be unable to find some elements, while it finds all if I use ordered_unique. This is with Boost 1.46.1.1 (Debian) and gcc version 4.6.1 (Debian 4.6.1-4) Is this a known issue? Olaf

2 2

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 10 Oct '11

10 Oct '11

On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >Den 06-10-2011 18:27, Phil Endecott skrev: >> Thorsten Ottosen wrote: >>> Even better, don't use vector<const char*>. What o you need that for? >[snip] >> >> Here's a real motivating example where I want to use vector<const >> char*>. I have a large file containing null-terminated strings which I >> memory map. After opening the file, I construct some sort of index of >> those strings in a sorted vector. Then I search for things using >> std::equal_range, std::lower_bound, or similar. > >That's a good example, I grant you. I actually have a helper class for this called cstrptr which is a typedef for the template class basic_cstrptr<char>. It is a "dumb" wrapper around const char * that provides some std::string functions to the normally even dumber bare pointer to char. It's designed for holding those magic strings that creep into production code all the time. sizeof cstrptr == sizeof const char* is always true so the constructor has very little overhead. The calling code is responsible for ensuring the lifetime of the ptr exceeds the lifetime of the cstrptr instance. It implements all the comparison operators against std::basic_string and const char*. It implements a const operator[] and an O(N) length() function. It only implements assignment and copy constructor to allow containers to hold them. I've wondered whether it was worth submitting to boost. It is so small I can't imagine it sitting on its own as a "library".

2 1

[test] backward compatibility issue
by Jürgen Hunold 10 Oct '11

10 Oct '11

Hi Gennadiy, I'm getting some compiler errors when using the new trunk version of Boost.Test with our sources. I'm getting error: ‘global_fixture_impl’ in namespace ‘boost::unit_test::ut_detail’ does not name a type when using BOOST_GLOBAL_FIXTURE and only #including "boost/test/unit_test_suite.hpp" This file #defines at line 179: static boost::unit_test::ut_detail::global_fixture_impl<F> BOOST_JOIN( gf_, F ) ; a simple #include <boost/test/tree/global_fixture.hpp> fixes this. Patch attached. Okay to commit? yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

Boost.Algorithms request
by Zoltán Tóth 10 Oct '11

10 Oct '11

I ask to change the name of function is_ordered(). The "is_" prefix suggests that it is a boolean function which it is not. Also, there are other functions there with prefix "is_" and which are boolean functions, and this non-uniformity hurts the eye. I suggest the name "first_misordered".

4 3