December 2009 - Boost - lists.boost.org

New libraries deadline approaching
by Vladimir Prus 08 Dec '09

08 Dec '09

Boosters, the deadline for merge of new libraries to 1.42 is Dec 14. So far, the only library that was added to trunk relative to 1.41 is uuid. Andy, does it seem like merge to release branch is possible by Dec 14? Do you need any assistance? It seems that you have succeeded in integrating the tests into the regression framework. However, one test -- test_generators, appear to fail on all platforms and test_uuid fails on a bunch as well. If the test failures are unclear, you might want to ask platform experts for help, while there is time. The next deadline will be Jan 4, when the release branch will be closed for major code changes. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 7

[interval containers (itl)] Update on Review Version. Element iterators added.
by Joachim Faulhaber 08 Dec '09

08 Dec '09

Dear all, while hanging around in "The Queue" my library was getting pretty bored :-/ So I decided to implement some depreciated featured to arrange for some entertainment =) Well, jokes aside, for a long time I resisted to implement iteration on *elements* for interval containers. Element iterators would be an invitation to inefficient usage of interval containers just by normal habitual use of iterators. For instantiations with continuous domain types like interval_set<double>, interval_set<rational<int>>, interval_set<string>, etc. element iteration would not be possible at all. Yet the questions about such iteration and the related question of interval containers being a model of SortedAssociativeContainer reoccurred in many feed backs on presentations of my library. There even was a proposal for a DenseSet library by Vicente Botet in the wiki's Library Wish List: https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction that follows the idea of interval containers but provides element iteration in order to fully implement SortedAssociativeContainer. So finally I decided to provide element iteration and put the responsibility to avoid inefficient deployment on the user. Moreover, while element iteration on interval containers can be substituted easily by simple loops, the element iteration over an interval_bitset that Zachary Turner asked for http://archives.free.net.ph/message/20091103.064651.263bf6bb.en.html is not so trivial, so it can not be substituted easily by a few lines of user code. That gave me some new motivation. So I have uploaded an update of my library's review version http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… to the vault that is extended by these features: * element iterators on all interval containers http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/fu… * itl::insert_iterator and itl::inserter that allows interval containers to be copied or transformed from std::containers using insert semantics http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… * itl::add_iterator and itl::adder that allows interval containers to be copied or transformed from std::containers using addition semantics so that aggregate on overlap can be done. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… In the extended library itl_xt that is part of http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… * there is an implementation of a large interval_bitset, that combines interval compression and bit compression. Element iteration is now available for interval_bitset. https://svn.boost.org/svn/boost/sandbox/itl/boost/itl_xt/interval_bitset.hpp Element iteration now enables interval_containers to be used with std::algorithms like the corresponding containers of elements. The major requirement for usability of element iteration is that the interval container's domain_type is a discrete type that has a smallest steppable unit and exposes an increment and decrement operator for it's in- and decrementation. I have successfully tested copy (and variants), equal, lexicogrphic_compare, find, lower_bound, upper_bound, includes and set_<algorithms>. All tested algorithms that were applicable to a SortedAssociativeContainer of elements were also working with interval_containers using element_iterators. The test have been done using a law "AtomicEquivalence" https://svn.boost.org/svn/boost/sandbox/itl/boost/validate/laws/atomic_equi… on the law based test automaton (LaBatea) https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… So I think this is a valuable addition to interval containers in the end and I hope it'll make std::algorithm aficionados among you happy ;-) Cheers Joachim ----------------------------------------------------------- Some repeated information on the library: Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part was submitted for review (2009-09-18): itl : Core library, interval containers, SUBMITTED FOR REVIEW Additional parts are: itl_xt : Extensions like interval_bitset, histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. *itl* is a complete library containing all required ingredients particularly a separate test suite (NOT using LaBatea) and the quickbook documentation. The code is successfully compiled and tested with gcc-3.4.4, 4.1.0, 4.3.2 and msvc-8.0, 9.0, 10.0. I have uploaded the first update of the review version as itl_3_2_0.zip to the vault in section containers. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… Another file itl_plus_3_2_0.zip contains all three parts (itl, itl_xt and validate). http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… Reviewers interested in the law based testing part may have to refer to this file to examine those tests. The law base testing examples compile and run with gcc-4.3.2, msvc-8.0, 9.0 and 10.0. LaBatea does not compile with gcc-4.1.0 or older. The quickbook generated documentation is included in the zip files and is also available online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/

1 0

[type_traits] Need help with an - unfixable? - issue
by John Maddock 08 Dec '09

08 Dec '09

This issue just came in: https://svn.boost.org/trac/boost/ticket/3730 Reduced to the test case below, and I can't see a way to fix this at present, anyone any bright ideas? Thanks, John. #include <map> #include <iostream> #include <boost/type_traits.hpp> class base { public: base() : i(0) {} base(int i) : i(i) { m[i] = "text"; } virtual void method1() = 0; virtual ~base() {}; private: int i; std::map<int, std::string> m; }; class derived1 : virtual public base { public: }; class derived2 : virtual public base { public: }; class intermediate : public derived1, public derived2 { public: intermediate() {} intermediate(int i) : base(i) {} void method1(); }; void intermediate::method1() { } class final : public intermediate { public: final() {} final(int i) : base(i) {} }; // // This class demonstrates what we need to make work inside is_virtual_base_of. // MSVC compiles this just fine (likewise is_virtual_base_of), and only complains // when attempting to use method1. Other compilers (GCC, Intel on Linux) complain // as soon as X is declared, likewise when instantiating is_virtual_base_of. // struct X : final, virtual intermediate { X(); X(const X&); X& operator=(const X&); ~X()throw(); }; int main( int /* argc */, char* /* argv */[] ) { X x; x.method1(); boost::is_virtual_base_of<intermediate, final>::type t; return t.value != true; }

2 1

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Michael, hi Robert, hi Felipe, >CurrentState() + cool_event() >[VeeeeeryLoooooooooongGuard()] >/(LooooooooooooooooongAction()) = DestState() I just wanted to bring an example from SimpleTimer (see doc): Ringing() + tick() == Ringing() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) would become: Ringing() + tick() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) == Ringing() Here, it is becoming hard to write action and target state on the same line. And the action can be as big as one wishes. >Here's another suggestion, though it breaks from the logical UML ordering Michael posted previously: >DestState() = CurrentState() + cool_event()[guard()]/(action()) I like this one quite much! Not UML at all but pretty much C++-style. And it'd become easy to write guard and action on the next lines if needed. >CurrentState() + cool_event()[guard()]/(action()) -> DestState() It's very similar with Michael's syntax but I think the operator precedence can be hard to master and we'll need extra parentheses. I think there is no operator -> in proto but ->* . We are making progress :) Christophe

2 1

Re: [boost] [msm] Review
by Christophe Henry 08 Dec '09

08 Dec '09

>FYI, this is an issue of -- apparently -- English not being Christophe's first language. >Darryl's construct, "This is unlike StateChart, where the idea of object instantiation as state is genuinely useful sometimes,..." >means "MSM's approach is unlike that of StateChart, because StateChart instantiates state objects, which is sometimes genuinely useful." > >I think there was more to the original sentence, which I haven't taken the trouble to recover from earlier posts, >which better developed what Darryl liked about MSM's own approach. >There was, however, no implication that MSM fails to meet expectations because it wasn't like StateChart in this behavior. > >For those for whom English is a second language, I apologize. >Few native English speakers learn the language well. We thus make our inherently complex language harder >still to understand by our mistakes of grammar, syntax, structure, and even word usage. >Add to that the many idiomatic constructs and expressions, not to mention colloquialisms, >we use that it's amazing that you manage to converse with us so well. Oh I see. Sorry Darryl for misunderstanding your post. Robert, thanks for your help! Christophe

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Michael, >Thank you for setting me straight on this. It should have dawned >on me that they were completion transitions as described in 15.3.14. >I have a love/hate feeling about them... I don't personally like >the concept of leaving a state via implicit trigger. It just makes >me feel uncomfortable. However, I also see the power they can >afford and use them for exactly your example... stepping along >algorithms. You taught me about simple states' internal transitions so let's count it a fair trade ;-) >Right now I'm pushing on the edges of what I'm learning from the docs >and a little bit of playing so I can determine how to convert basic >constructs I use a lot from the model to the implementation. Thanks >for putting up with me. You're welcome. I enjoy the discussion and await the harder questions which are surely coming. Christophe

1 0

Re: [boost] [msm] Review
by Christophe Henry 08 Dec '09

08 Dec '09

Hi Darryl, >I agree with this. However, I have yet to come completely to terms with >how best to use msm. I am beginning to think, in trying to use it, that >it would be better to separate the state transition table definition as >much as possible from what, in an msm world, are more like semantic >actions. This is very different from the more oo modeling approach of >statechart. I'm not sure the statechart isn't better at expressing fsms >that "emerge" out of overall application/system design in an all >encompassing oo design uml world, and msm better at expressing more self >contained "islands" of fsm in an app As far as I can tell, state machines and OO modeling are completely orthogonal concepts. An OO implementation doesn't mean that FSMs are an OO concept. Can you precise your point with a concrete example? >I'm far from an expert with >spirit, but I think there are many concepts that could be borrowed from >it to make msm better able to be used to define a fsm that can be bound >to separate objects to implement behavior and exend its use beyond these >islands. Again, can you help us with more concrete examples? >Basically, it needs to be easier to take a 1 TU transition table >integrate it into to a bigger multi TU system What would it concretely bring? Compile-time improvements not really, so? >actions - the functor approach is good - though it needs a bit more >development to make it easier to bind to actions that are not explicitly >designed for use as msm state machine actions. What would it bring? You can simply ignore the functor arguments if you don't need them. A closer look at eUML will however show you that having your source/target states at hand in a transition handling can be pretty useful. >states - I don't really understand what an instance of a state is in msm >- it doesn't model anything meaningful to me. Where do you suggest putting the entry/exit actions and the flags? All in one big fat react function with lesser code reuse possibilites? And all the state data inside a fsm? Why giving up reuse of states? >This is unlike statechart, >where the idea of object instantiation as state is genuinely useful - >sometimes, and where it is the state that "reacts" to an event In UML, it is a state machine which reacts to an event, not a state. Statechart != UML (the same applies to MSM). Furthermore, "unlike Statechart" isn't a valid argument, is it? Making MSM look like Statechart is not the goal (besides, David would make us another round ;-) Just kidding, David) Could you please develop your point a little? >Should msm drop state objects altogether and simply have some sort of context / >current state object? Arguably it already has one in the form of the fsm >object - though that is a bigger concept than context. I disagree. I see no gain doing this. Just more confusing, tightly coupled, unreusable state machines. >Michael Caisse has already pointed out that there is something slightly odd about the >current state being represented as a scalar in a model that has objects >as states Did we read the same post? I didn't read all this in any of his posts. >I haven't spent much time thinking about this I also have this feeling, to be frank. If I understand, what you want is a MSM looking like Statechart. What for? I think a few concrete points would help us all. Of course, MSM could easily support a Statechart-like frontend, but nobody required this so far. I had the opposite feeling, that most people welcomed the lesser coupling offered by MSM. Or am I getting it wrong? Christophe

3 2

[serialization] #3677: Please, pay attention to a serious regression
by Alexander Churanov 08 Dec '09

08 Dec '09

Folks, I've just re-opened the issue #3677, since I did not receive any specific feedback on how to resolve it. In the ticket it's claimed that the issue is fixed. However, for the question about how to obtain the patch it was answered that there is a belief the patch is checked in somewhere into the trunk. I completely understand that Boost is free and does not provide any warranty for quality and reliability of the libraries. However, I hope that there is a strong interest in Boost community for that. To my knowledge, the issue is cross-platform and may broke more applications than stated in the ticket. It is a pure regression: boost 1.39 is known to work. The issue is a showstopper, at least for FreeBSD: I may not update the boost to 1.41, because this action breaks working applications. The desired is any definite decision on the issue. Preferably, a fix or a workaround. Alexander Churanov, maintainer of devel/boost-*

1 0

Re: [boost] [serialization] polymorphic archives runtime failure(was:polymorphic archives ... generates linker errors)
by Bogdan 08 Dec '09

08 Dec '09

I just want to confirm I have the same issue with boost 1.41.0 built with MSVC 9.0 (Visual Studio 2008). I have created two tests similar to the one Christoph describes ( both with and without DLLs) and I hit exactly the same assert in basic_serializer_map::find(). It looks like while deserializing B via A*, basic_iarchive_impl::load_pointer() is trying to recover a serializer from: boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::naked_xml_iar chive> > (or boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::naked_text_ia rchive> >, depending on the input archive actually used) but that map is empty. I checked boost::serialization::singleton< boost::archive::detail::archive_serializer_map<boost::archive::polymorphic_i archive> > in the first line of my program and it contains correctly two serializers (one for A and one for B, respectively), proving that the macro BOOST_CLASS_EXPORT_IMPLEMENT(.) has registered those classes. I am not sure why the serializers for A and B do not register with the specific polymorphic archives but only with the base archive. I was under the impression that the polymorphic archives are meant to make that process transparent to the user (especially future archives that are created later). I appreciate any feedback about this issue and please let me know if you need more details. Thank you, Bogdan PS I am using extended type_info_no_rtti. Deserializing via isomorphic pointers (B*->ser->dser->B*) is working.

4 4

[regex][patch] regex build not honoring ICU_LINK build property
by Martin Schafföner 08 Dec '09

08 Dec '09

I have been trying to build boost.regex with Unicode support against a custom ICU4C build. The ICU4C build used the "--with-library-suffix=rm" configuration option to distinguish the library as being custom built. I tried building boost.regex with the bjam option like '-sICU_LINK="\"/LIBPATH:c:\icu4c\dist\libs\windows-i686 icuinrm.lib icuucrm.lib\""' but it failed to apply the linker flags. I then tried to understand what's going on and it seemed that the ICU_LINK property never makes it into the actual linker calls. With the attached patch against 1.41.0 the ICU_LINK build property works as expected. Regards, Dr. Martin Schafföner Core Technologies Recommind, Inc. Office: +49 2226 15 966 13 Email: martin.schaffoener(a)recommind.com This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

2 1