January 2010 - Boost - lists.boost.org

Trac administration procedures
by Vladimir Prus 10 Jan '10

10 Jan '10

Hi, Looking at https://svn.boost.org/trac/boost/wiki I see instruction for requesting a new account, but I don't see instructions for requesting various other administrative changes -- for example adding/removing components and milestones. Could somebody please add such information (so that I can make a request without spamming this mailing list). Thanks in advance, Volodya

1 0

[log] Release Candidate 4 released Options
by Jesse Perla 10 Jan '10

10 Jan '10

Andrey: I am excited to get logging into boost! I may have mentioned this before, but I see logging support for distributed applications as being my essential usecase. For applications distributed by MPI, the interface is MPE: http://www.mcs.anl.gov/research/projects/mpi/www/www4/MPE.html You can see an example here: http://beige.ucs.indiana.edu/I590/node112.html There are a few quirks about this interface, and I wanted to do a sanity check that it was possible to implement as a backend: * You need to have event numbers for different log events. And you need to call an API to get the number: MPE_Log_get_event_number() * There is a way to describe states and their transitions: MPE_Describe_state(.) after you generate them. This allows you to track the duration between state changes... with associated colors. * There is a viewer called "jumpshot" that shows these logs, colors, etc. Anyways, I just wanted to bring this to your attention as an important usecase to think through in the interfaces. And if you happen to write an MPE backend to be packaged with boost::mpi, it would be an amazing addition. -Jesse

2 1

Re: [boost] [multi_index][serialization]save_construct_data not called for multi_index collection
by JOAQUIN M. LOPEZ MUÑOZ 09 Jan '10

09 Jan '10

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Robert Ramey [ramey(a)rrsd.com] Enviado el: sábado, 09 de enero de 2010 21:42 Para: boost(a)lists.boost.org Asunto: Re: [boost] [multi_index][serialization]save_construct_data not called for multi_index collection > > Joaquin M Lopez Munoz wrote: > > > Hi Felipe, I still haven't received an answer to my question > > about Boost.Serialization, so, given the sensible nature > > of serialization code > > lol - thank you for such a charitable characterization. Don't get me wrong, I'm not referring to Boost.Serialization code, but to the code (in this particular case, inside Boost.MultiIndex) devoted to serializing a particular type: if one makes a wrong/bad decision within it, great care has to be taken so as to fix this decision while being backwards compatible with archives created with prior versions of the lib. In no way were I referring to any particular aspect of Boost.Serialization, being this problem absolutely inherent to any serialization framework one could use. Besides, I much appreciate the work you put in B.S. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[variant] Common base type of variant sub-types
by Adam Badura 09 Jan '10

09 Jan '10

Unions of POD types have a special case of allowing to access union value members through any union value which has those members. This is exemplified by following code: ---------- struct base { int shared; }; struct derived_1 : base { int shared_as_well; int not_shared_1; }; struct derived_2 : base { int shared_as_well; int not_shared_2; }; union union_type { derived_1 value_1; derived_2 value_2; } void f() { union_type v; v.value_1 = derived_1(); v.value_2.shared = 1; // This is OK. v.value_2.shared_as_well = 1; // This is OK as well. //v.value_2.not_shared_2 = 1; // This is not OK. } ---------- Such feature is quite useful. Sadly it is not supported by boost::variant. However a similar feature might be supported if boost::get was changed a bit. Lets consider another example: ---------- #include <boost/variant.hpp> struct base { int shared; }; struct derived_1 : base { int almost_shared; // If union was used this would be shared as well. int not_shared_1; }; struct derived_2 : base { int almost_shared; // If union was used this would be shared as well. int not_shared_2; }; typedef boost::variant<derived_1, derived_2> variant_type; void f() { variant_type v; v = derived_1(); assert(boost::get<base>(&v)); // This will fail. v = derived_2(); assert(boost::get<base>(&v)); // This will fail. } ---------- As can be seen boost::get fails if we specify a base type of a type which object is stored in variant. However if it would not fail but succeed we would have a feature similar to that special case with unions. And I know this can be done with visitor (just like boost::get is implemented) however I think it would be useful to wrap this functionality in a function. I think it is unlikely that such feature would break existing code. However it possibly might. To avoid breaking existing code a function similar to get could be introduced. I think I might implement this but I would prefer someone else to do this. :) Adam Badura

2 4

Closed for major changes; release freeze approaching
by Vladimir Prus 09 Jan '10

09 Jan '10

Boosters, Per release calendar, the release branch is closed for major changes now. On next Monday, Jan 11, the branch will be closed for all changes except by permission. What constitutes major change is up to you, but please exercise caution with commits. Now, I believe we have two outstanding issues: - uuid is still not merged to release branch - we still have issues with Boost.Test, see: http://permalink.gmane.org/gmane.comp.lib.boost.devel/198282 - release branch has 20 regressions, and 138 new failures. functional/hash, numeric/interval and regex are the libraries with regressions. I'd appreciate if maintainers of those libraries act on regressions, and other maintainers examine "new" failures. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

4 9

[variant] Why boost::get uses simple throw instead of BOOST_THROW_EXCEPTION
by Adam Badura 09 Jan '10

09 Jan '10

Is there any reason for boost::get to use simple "throw" to throw bad_get rather then BOOST_THROW_EXCEPTION? I thought BOOST_THROW_EXCEPTION is supposed to be used in all Boost libraries... Adam Badura

2 1

[log] Review manager wanted
by Andrey Semashev 08 Jan '10

08 Jan '10

Guys, I know you are all very busy persons, probably even more busy than I am. :) But the situation with the review queue is getting really daunting. Boost.Log (as well as many other good libraries) is hanging in the queue for a quite long time, and it desperately needs a review manager. There has been a few active discussions of this particular library and logging in general, so I can't count this situation to a lack of interest to a logging library in Boost. Logging is not something domain-specific. I'm sure most of us have worked with a tool like this, so virtually anyone can manage this review. I'm asking someone to step forward and make this library a part of Boost, if it deserves so, or make it RIP otherwise. You will not be forgotten by thankful users and me. Thank you.

3 4

[patch] first_iterator, second_iterator?
by Daniel Colascione 08 Jan '10

08 Jan '10

Iterating over the first and second elements of a collection of pairs is a pretty common problem. Would it be possible to get something like the following into boost? #include <boost/iterator/iterator_adaptor.hpp> /* For testing, below */ #include <map> #include <string> #include <iostream> #include <iterator> template<typename BaseIt> struct first_iterator : boost::iterator_adaptor< first_iterator<BaseIt>, BaseIt, typename BaseIt::value_type::first_type > { first_iterator() : first_iterator::iterator_adaptor_() {} first_iterator(const BaseIt& bi) : first_iterator::iterator_adaptor_(bi) {} operator const BaseIt&() { return this->base_reference(); } private: friend struct boost::iterator_core_access; typename BaseIt::value_type::first_type& dereference() const { return this->base_reference()->first; } }; template<typename T> first_iterator<T> make_first_iterator(const T& it) { return first_iterator<T>(it); } template<typename BaseIt> struct second_iterator : boost::iterator_adaptor< second_iterator<BaseIt>, BaseIt, typename BaseIt::value_type::second_type > { second_iterator() : second_iterator::iterator_adaptor_() {} second_iterator(const BaseIt& bi) : second_iterator::iterator_adaptor_(bi) {} operator const BaseIt&() { return this->base_reference(); } private: friend struct boost::iterator_core_access; typename BaseIt::value_type::second_type& dereference() const { return this->base_reference()->second; } }; template<typename T> second_iterator<T> make_second_iterator(const T& it) { return second_iterator<T>(it); } int main() { typedef std::map<int, std::string> testmap; testmap t; t.insert(std::pair<int, std::string>(5, "middle")); t.insert(std::pair<int, std::string>(2, "first")); t.insert(std::pair<int, std::string>(8, "last")); std::copy(make_first_iterator(t.begin()), make_first_iterator(t.end()), std::ostream_iterator<int>(std::cout, " ")); std::cout << "\n"; std::copy(make_second_iterator(t.begin()), make_second_iterator(t.end()), std::ostream_iterator<std::string>(std::cout, " ")); std::cout << "\n"; first_iterator<testmap::iterator> x = t.begin(); ++x; t.erase(x); }

4 5

Re: [boost] Boost library submission (stldb - poll for interest)
by Bob Walters 08 Jan '10

08 Jan '10

On Wed, 6 Jan 2010 09:10:57 +0100, Stefan Strasser <strasser(a)uni-bremen.de> wrote: >> .... A map implementation >> which internally segmented itself into sections under independent mutexes >> in order to permit highly concurrent modifications of any kind would be a >> big help. Anyone know of any such implementations? > > any implementation based on shadowpaging, e.g. this open source one: > http://1978th.net/tokyocabinet/ > > I don't know any internals of Berkeley DB, but it also supports concurrent > modifications. > > the containers I describe here: > https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html… > > also support concurrent modifications, since their container nodes are > implemented as MVCControlled objects. > but they are much less efficient in absolute terms than a low-level container > implementation. There's a problem with this approach to concurrency. I don't like the unavoidable chance of exceptions forcing retry. The company I work for had a problem like this with BerkeleyDB. We had a map which was typically very small, but subject to a constant load of insert/update/delete activity. Under such a load, the prospect of page-level contention increases, and in BerkeleyDB's case we got a lot of 'deadlock' exceptions, which could recurr 5+ times despite retries. The rety-based approach can be a death spiral, in that once contention occurs, the fact that threads are then having to try 2+ times to complete their transactions only increases the load against the containers, thereby also increasing the probability of contention. I think I can digress to the arguments which led to RDBMS'es doing blocking. So I probably have a bias here, but I don't like the notion of the container failing thread A simply because thread B inserted a record which causes some rebalancing which touched the node pointers on the node that A wants to modify. The container should be predictable so that end users can optimize according to its behavior. The STLdb map does not have this problem. Inserts with different key values will never cause a contention exception. Even when two processes do modify the same entry, blocking is possible, as an alternative to retry logic, because that can be more efficient overall. All of this is reinforcing my hope for trans_map<key,locator> - you address the chief persistence related problems I would have if I just put 10 gigs of values into the STLdb database, and I think I can keep these container implementations fast and predictable, and meet your desire for low-level containers.

1 0

[rdb] 0.2.04 - date, time and datetime
by Jean-Louis Leroy 08 Jan '10

08 Jan '10

I have uploaded a new version to the vault. It introduces support for three new sql types : datetime, date and time. I have been busy with other things recently, sorry for not taking part to the discussions about Persistent and other libs. Jean-Louis

1 0