June 2010 - Boost - lists.preview.boost.org

Re: [boost] [Boost.Assign] list_of::range without an initial (single) element?
by Thorsten Ottosen 15 Jun '10

15 Jun '10

er skrev: > Michael McNeil Forbes wrote: >> What is the recommended way of initializing an array from a >> concatenation of other arrays? >> >> list_of::range looks right and I would like to use something like: >> >> array<int, 2> a = { 1, 2 }; >> array<int, 2> b = { 3, 4 }; >> array<int, 4> c = list_of<int>().range(a).range(b); >> >> However, list_of<int>() inserts a default value (so that >> list_of<int>().range(a).range(b) == {0,1,2,3,4}). Maybe we should add empty_list_of<int>() ? It's quite trivial to add. -Thorsten

1 0

[msm] Message queue and copy constructed events
by Christophe Henry 15 Jun '10

15 Jun '10

Hi Michael, >in case we use message queueing in our state machines (which we actually >have to because otherwise the pseudo exit state behaviour will not work >correctly) our events have to implement a copy constructor because there >is a possibility that some of them are queued. Actually for the pseudo exit states it's also so that the event from the outgoing transition can be convertible from the event coming from the inner transition. >We do not want that events >get copied because they are very big and it certainly decreases our >performance. >Could you not just store pointers to events so that the events do not get >copy constructed again? >Our understanding of the queuing implementation is that the event instance >is valid as long as the outer most process_event() is not returned to the >caller. In that case it is not a problem to just store those pointers. I suppose you are still talking about the pseudo exit states. It's not that simple because queuing can happen surprisingly fast. One could decide to defer inside the action method of the transition exiting the pseudo exit. It's a corner case, but I can imagine someone will one day find a use of it, like for about every single feature I put inside msm. >We also could use shared pointers as events and so only the shared >pointers get copy constructed. But this would mean that we have to put all >our events into shared pointers which also decreases performance and it >would look like strange passing shared pointer as reference to the >process_event() method. > >Do you have another idea in order to overcome this? Why not simply pimpl the big data from the event inside a shared_ptr as event's attribute? Or more efficiently, as I understand your data is useful only until the end of a process_event, keep a pointer to it, for example something like: { Data data; fsm.process_event(my_event(&data)); } // data is gone here >At the moment, we can not think of a proper solution for deferred events. >In that case there would be no other solution than copy deferred events. I'd prefer to avoid confusing users by using different behaviors, especially as the above solution seems pretty simple to implement. >Anyway, we would like to have a mechanism in order to influence the queue >implentation and change it to a user definied implementation. >Would it be possible to pass the queue type as an optional template >argument to the state machine? >This would the make state machine even more flexible and one does not have >to use std::queue. I'm thinking about this because someone requested the possibility of using no heap at all and providing a fixed-size array instead. It seems a reasonable request. Regards, Christophe

2 1

[Proto] Computing type in expression
by joel falcou 15 Jun '10

15 Jun '10

I have an expression wrapper class tied to a domain and a grammar. Everythign works ok except for the fact it seems I can't compute type inside the expression class that depends on the expression type itself. I end up with tons of incomplete type error in proto/fusion.hpp. The example is a bit big, i'm still working on a small repro but basically, what I do is using the expression framework from ym last mail is to have a value_type on expression which represent the value_type of the expression element. Regards

2 4

[proto] small breaking change
by Eric Niebler 15 Jun '10

15 Jun '10

I just made a change to proto in the effort to reduce compile times. There's a new expression type, proto::basic_expr, that is lighter weight than proto::expr in that it doesn't define the operator=, operator[] and operator() member functions. It's ideal as a base when extending expressions with proto::extends or BOOST_PROTO_EXTENDS. You'll get basic_expr instead of expr automatically if you use either of proto::generator or proto::pod_generator. That could surprise you if you were expecting to get an expr, so beware. Most normal uses of Proto will just work with this change, though, and if you measure you should see a modest improvement in your compile times. Please let me know if this breaks your code. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 22

[trac] more spam
by Steven Watanabe 15 Jun '10

15 Jun '10

AMDG Here: https://svn.boost.org/trac/boost/ticket/1633 In Christ, Steven Watanabe

2 1

tcmalloc and boost::diagnostic_information
by Daniel Larimer 14 Jun '10

14 Jun '10

I have some code that works fine on Mac OS X. I then switched it to use tcmalloc and it crashes when I attempt to use boost::diagnostic_information to print out information about an exception. #0 0x00007fff81298886 in __kill () #1 0x00007fff81338eae in abort () #2 0x000000010076ece3 in TCMalloc_CRASH_internal () at spinlock.h:104 #3 0x000000010076ee4b in TCMalloc_CrashReporter::PrintfAndDie () at spinlock.h:104 #4 0x000000010076c586 in (anonymous namespace)::InvalidFree (ptr=<value temporarily unavailable, due to optimizations>) at src/tcmalloc.cc:372 #5 0x000000010004171a in boost::units::detail::demangle (name=0x100258ac0 "N5boost16exception_detail10clone_implIN2fl5error14future_timeoutEEE") at utility.hpp:48 #6 0x0000000100046456 in boost::exception_detail::diagnostic_information_impl (be=0x101b00080, se=0x101b00070, with_what=true) at diagnostic_information.hpp:140 #7 0x00000001000466b9 in boost::diagnostic_information<boost::exception> (e=@0x101b00080) at diagnostic_information.hpp:156 Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.

4 6

Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
by Dave Handley 14 Jun '10

14 Jun '10

Vicente Botet wrote: > Tom's swap_in_place force to interpret all the fields of the structure with the same endianness. Do you have a use case for the situation where fields of a structure have different endianness? It seems a lot of complexity to add if there isn't a strong use case. Dave

2 1

[contract] non-public subcontracting (N1962)
by Lorenzo Caminiti 14 Jun '10

14 Jun '10

Hello all (and N1962 authors especially), How should subcontracting work for non-public base classes? I have listed a few examples below. Assume contracts were written for all these example classes (invariants) and their functions (pre/post conditions). My questions are: A) `c::p()` should subcontract; but what about any of the other member functions of `c`, should any of them subcontract also? B) Am I missing any other combination of member/inheritance access level significant for deciding when to subcontract? class bp { public: virtual void p(void) { std::cout << "bp called" << std::endl; } }; class bf { protected: virtual void f(void) { std::cout << "bg called" << std::endl; } }; class bg { public: virtual void g(void) { std::cout << "bg called" << std::endl; } }; class bh { public: virtual void h(void) { std::cout << "bh called" << std::endl; } }; class c: public bp, public bf, protected bg, private bh { public: // This should subcontract. virtual void p(void) { bp::p(); } // Should any of the following subcontract also? virtual void f(void) { bf::f(); } virtual void g(void) { bg::g(); } virtual void h(void) { bh::h(); } // Am I missing any other relevant combination? }; (I do not think multiple inheritance is relevant for my questions. I am using multiple inheritance in this example just so to have only one derived class `c` which exercises all the use cases.) My notes and questions: 1) All member functions of `c` are public so they will check their pre/post conditions as in `c` and `c` class invariants. 2) But shall any `c` member functions also check their base class invariants and/or base function pre/post conditions? 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because it is a public function publicly inheriting from a base public function. ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not `bf` invariant... (because `bf::f` is protected thus it does not have to check `bf` invariant). ** ** 5) Should `c::g()` and `c::h()` subcontract given that their inheritance is not public? ** Thank you very much. -- Lorenzo

2 5

[boost::endian] Summary of discussion #1
by Tomas Puverle 14 Jun '10

14 Jun '10

Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit. Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions. Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>(). The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol. Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used. Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values. Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future. This seems like a reasonable plan for implementation. Thanks again for all the input. Tom

10 68

[xint] Fourth release, requesting preliminary review again
by Chad Nelson 14 Jun '10

14 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next, and hopefully final, iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The highlights of this release are: * It's now a header-only library. It can still be compiled if you wish (I use the compiled version for most of my testing), but that's no longer required. * The user-visible classes (integer, nothrow_integer, and fixed_integer) are all now templates, with parameters for an allocator, thread-safe operation, and "secure mode" (zeroing all memory before releasing it). * Thread-safe operation is now the default. It's slightly slower that way, but not much, because the library still uses a copy-on-write system for internal functions (where it's safe because variables allocated there can never be seen across thread boundaries). Every object is given its own storage before it's returned to the non-library caller. I've included my testing projects as well, for CodeLite under Linux and Visual Studio under Windows, for convenience. It includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. I plan to add a few more examples, but what's there should be sufficient to get people started. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwFDsoACgkQp9x9jeZ9/wR4GwCfQ3LMFyQZIuNZC71qEgDQR1fG uLwAoKR3cMA3Be859DxYgz56GsGlCqE9 =o62S -----END PGP SIGNATURE-----

16 71