- Boost - lists.boost.org

value_initialized docs problem
by David Abrahams 24 Feb '05

24 Feb '05

The docs use "impll-defined" where they should say "unspecified." -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[any] checked convertion to reference?
by Vladimir Prus 24 Feb '05

24 Feb '05

Currently, boost::any supports two kinds of conversion: 1. Unchecked conversion to pointer (NULL is returned if conversion is impossible) 2. Checked conversion to value type (exception is thrown if conversion is impossible) I'd like to have another variant -- checked conversion to reference. The following code does not compile: boost::any a = 1; int& i = boost::any_cast<int&>(a); There are two issues: 1. Documentation says: If passed a value or reference, it returns a copy of the value content if successful. But even if I change the above to boost::any a = 1; int i = boost::any_cast<int&>(a); it does not compile. Docs are at least inaccurate. 2. Can we make the above work? I attach a patch which implements casting to reference, and passes all the existing test. I'd like this behaviour because currently program_options contains code such as: template<class T> T& variable_value::as() { T* r = boost::any_cast<T>(&v); if (!r) throw boost::bad_any_cast(); return *r; } which is plain ugly. With the patch, the above can be written as template<class T> T& variable_value::as() { return boost::any_cast<T&>(v); } - Volodya

5 13

Re: [boost] Proposal: Library to manage processes
by Julio M. Merino Vidal 24 Feb '05

24 Feb '05

I'm not replying to any particular reply to my original message because I want to address them all at once. First of all, I have started to write a little document listing all the requirements for the library. I'm focusing on my initial ideas and on all the interesting comments you've made. Then I need to learn more about Boost.Thread (mainly to see if its design could be appropriate to the process management library) and Boost.Iostreams (which should be used to ease handling input and output). Also it'll be worth to look at all the existing libraries you've mentioned. In fact, what I had in mind is quite simpler than what some people would like to see in the lib. But after reading your comments, I realize that it'd be worth to add the features you request. WRT my existing code... well, better forget about it (somebody asked for it, or at least some documentation regarding its interface). It is not worth using (I was going to refactor it anyway). Better to start the design from scratch, get it powerful and correct, and then implement it (which should be the easiest part). I'll let you know when I have a somewhat decent document that lists all the required features in detail as well as some design ideas to get some feedback. (Dunno when that'll be though; my time is probably going to be limited from now on...) Anyway, thanks for all your great comments! -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

6 9

Incorrect usage of test macros in octionion, quaternion, special_functions, regex, fusion.
by Martin Wille 24 Feb '05

24 Feb '05

Hello, several test macros are used with the wrong number of arguments by several tests: octonion_test: BOOST_REQUIRE_PREDICATE, BOOST_CHECK_PREDICATE quaternion_test: BOOST_REQUIRE_PREDICATE, BOOST_CHECK_PREDICATE sinc_test: BOOST_CHECK_PREDICATE unicode_iterator_test: BOOST_CHECK_EQUAL_COLLECTIONS Fusion still uses BOOST_TEST (which doesn't exist anymore). Regards, m

5 9

Re: Boost library inclusion: generic tree containers?
by Jeff Mirwaisi 24 Feb '05

24 Feb '05

Since the interest level in a generic tree library seems to be high, below is a link to an incomplete tree library/type constructor framework I have been tinkering with. It, perhaps foolishly, tries to present the building blocks for the construction of a large set of different tree types with different balancing and book-keeping requirements. Keep in mind it is not complete, some of the balancing schemes need to be checked, it has no workarounds for broken compilers and for the most part only basic/range insert have been implemented (erase is just a placeholder) http://24.221.194.82:8080/src/trees/index.html There are a number of meta programming techniques used in the library, including execute_if which i brought up in a separate thread, the techniques link via the above link describes a few of them (template parameter mapping, execute_if etc). http://24.221.194.82:8080/src/tc/index.html The above is a start at defining some of the terms and concepts used in type constructors/builders/computers, once meaningful terms are agreed upon the tree documentation will change to use the new terms. Stroustrup on a generic binary tree library: Matt Austern, Bjarne Stroustrup, Mikkel Thorup, and John Wilkinson: Untangling the Balancing and Searching of Balanced Binary Search Trees. Software - Practice & Experience. Vol 33, Issue13. October 2003 (google only has a link to the example code in this paper) Stroustrup on binary tree iterators: http://portal.acm.org/citation.cfm?id=268114 Feedback is appreciated, -Jeff Mirwaisi

3 2

[lambda] throw_action is sometimes declared as a struct and sometimes as a class
by Yariv Tal 24 Feb '05

24 Feb '05

This is not serious, but does cause warnings on my VC7.1 (I could suppress them but I like staying tidy so I want to be warned when I am not consistent with the struct/class usage)

2 2

RE: [boost] ANN: review of FSM library starts
by Simon Gittins 24 Feb '05

24 Feb '05

I think the library should be accepted in boost. Comments below. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] > On Behalf Of Pavel Vozenilek > Sent: Monday, February 21, 2005 11:31 AM > To: boost(a)lists.boost.org > Subject: [boost] ANN: review of FSM library starts [snip] > > * What is your evaluation of the documentation? > How easy (or hard) it is to understand library > features? What can be improved? > The tutorial is good. The few times I've needed the reference, it has been sufficient. > > * What is your evaluation of the design? > What features are supported better by > alternative FSMs? What could be added > (or removed) from the library? > Three appealing features of boost::fsm for me are: - No code generation - Hierarchical. - State local data ('state is an object'). In my application (5 state machines, each with 8 - 40 states), I was able to use the fsm to manage the lifetime of objects local to the state (and any inner states). To me, it seems natural that states have the option of 'owning' information. Managing the lifetime and access rights of some 50+ variables used by a state machine would be unpleasant. I think that custom_reactions that act like guards should be discouraged, as they effectively hide part of the state chart in the implementation. When I read a particular fsm, I want to be able to clearly see all possible transitions and actions without having to search through any decision logic code to fill in the gaps. We should be able to specify guards as part of the state definition. Something like this: struct StState: fsm::simple_state<StState,StOuter, mpl::list < fsm::guard2<EvEvent, fsm::switch<StRes0,StRes0ActCtxt,&StRes0ActCtxt::Action0>, fsm::switch<StRes1,StRes1ActCtxt,&StRes1ActCtxt::Action1> > > >; I guess this might make the cpp code look like this: fsm::guard2::result StState::guard2(const EvEvent& ev) { if(cond) return fsm::guard2::result<0>(); else return fsm::guard2::result<1>(); } I haven't thought about the implementation too much admittedly. Having this would be a big help in automatically generating UML state charts. > > * The library documentation contains > few not yet solved issues (name, > separating the library into two parts, > exception handling). What is you opinion here? > I have no opinion on the possibility of splitting the library in two. I've avoided using the exception handling feature of boost::fsm, but the description in the documentation looks fairly sensible. > > * What is your evaluation of the implementation? > Are there parts of code too obscure or > duplicating exiting Boost functionality? > Can something be factored out to standalone > library or among general utilities? > Implementation appears concise. No real concerns here. I was able to add a new type of reaction (in_state_transition - trivial though it is) with no problems. > > * Are there performance bottlenecks? > Does the library design fit requirements > of real-time systems? How is it useable > for embedded systems? > Is the documentation clear on performance > tradeoffs? > The library produces large binaries. It does however, appear to scale reasonably well (anecdotally, it seems about linear with the number of states). The in memory footprint is of the same order of magnitude as the binary size. My application is fairly soft real time, and runs on an embedded 486-like system, with a few hundred individual state machines and a few hundred events delivered per second. In this case, the performance of boost::fsm is acceptable, and does not threaten any timing constraints of the system. > > * What is your evaluation of the potential > usefulness of the library? Can you compare > this FSM to other implementations? > The library has already been useful, and I see myself using the library again. I believe that boost::fsm is a good solution for many non trivial compile time fsms. > > * Did you try to use the library? With what > compiler? Did you have any problems? > Do you have tips for better support of older > compilers? What are possible portability problems? > I've been using an older version of the library with gcc-3.2.3 > > * How much effort did you put into your > evaluation? > A glance? A quick reading? In-depth study? > I've spent quite a few hours developing using boost::fsm, and about half an hour catching up the on the latest documentation. > * Are you knowledgeable about the problem domain? > Not overly. I've built state machines with switch(), and have had to build a flat dynamic fsm framework (and use it) in the past. > > And finally, every reviewer should answer this question: > > > * Do you think the library should be accepted as a > Boost library? Be sure to say this explicitly so that > your other comments don't obscure your overall opinion. > Yes Simon Gittins ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 3

type_info/typeid
by Jody Hagins 23 Feb '05

23 Feb '05

As noted eariler, I have been working on moving the type_info/typeid stuff into a more common place. I have been using the implementation in boost/python/type_id.hpp as a reference, because that code seems to have addressed many issues related to different compilers. However, some of the workaround code prohibits standard confirming calls, so I wanted to get some input here. I am conflicted as to giving a summary or providing full details. I will probably end up doing a bit of both... The biggest problem is that on some older compilers, calls to the typeid() operator incorrectly leave outer reference and cv-qualifiers when returning type_info. Some interesting code exists to workaround this problem, resulting in a type_id() function. I have expanded this functionality to get most of 5.2.8 working. However, there are several pieces of 5.2.8 that are not possible (at least to me), using a fix like this. I have tried using macros, and some other tricks, but can not get full conformance to 5.2.8. So, maybe I can get a little help. The "bad" compilers are currently recognized by this incantation. #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) \ || (defined(BOOST_INTEL_CXX_VERSION) \ && BOOST_INTEL_CXX_VERSION <= 700) What versions of MSVC/Intel does this include? Is support for them still necessary? If so, is it reasonable to leave in a type_id function that does not conform to 5.2.8, letting the buyer beware? Also, it is remotely possible that implemeting 5.2.8 fully is possible with a workaround, but I have been unsuccessful using gcc. I basically "force" the workaround to be used by adding defined(__GNUC__) so I can test the workaround code. The closest I can come is defining a macro... #if (defined(BOOST_MSVC) && BOOST_MSVC <= 1300) \ || (defined(BOOST_INTEL_CXX_VERSION) \ && BOOST_INTEL_CXX_VERSION <= 700) # define BOOST_TYPEID(x) \ // Some funky stuff #else # define BOOST_TYPEID(x) typeid(x) #endif but still under the "bad" compilers, some code does not compile, and other code causes tests to fail. This leaves users with some leeway. If you do not care about compiler bug workarounds, use typeid(). If you do care, use the BOOST_TYPEID() macro. However, if you are using a "bad" compiler, some things will either not compile, or will give the wrong behavior. FWIW, the current workaround only supports static types, and does not support lvalue at all. I have added this, but it has some problems. FWIW, the most difficult parts of 5.2.8 to get right with the workaround are: 5.2.8.2: I am having problems stripping the qualifiers and still leaving the most derived information 5.2.8.2: once the expression is evaluated, unless call directly to typeid(), a segv happens instead of std::bad_typeid exception being thrown. 5.2.8.3: The expression is not supposed to be evaluated (the expression is only allowed to be evaluated if the expression results in a polymorphic type or a pointer to a polymorphic type is dereferenced -- see 5.2.8.2). I would gladly appreciate any questions/comments.

1 0

Yet another typo fix
by Julio M. Merino Vidal 23 Feb '05

23 Feb '05

Hi again, you can find attached another typo fix; this time it's a change from neccessary to necessary. I first noticed this in a documentation file (from Boost.Build v2), but then decided to cleanup the whole source tree. It's gzipped to keep it small. Can anybody please apply this one (and possibly the other patches attached to my last two emails)? Thanks a lot, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 3

Re: Compile-time conditional function invocation
by Jeff Mirwaisi 23 Feb '05

23 Feb '05

documentation, but just for completeness. Given a type trait TT which you want to select upon. Given a template function TF which you would like to call only for types that TT selects from within template function G. We need a type which will delegate to TF, that doesn't bind the template parameter types and is a first class type (a holder) template <typename T> void TF(T) {} struct TF_holder { typedef void result_type; template <typename T> result_type invoke(T t) {return TF(t);} }; template <typename U> void G(U u) { execute_if< TT< U >::invoke< TF_holder >(u); } G is the generic template function for all types, TF is the conditionally targeted template function for types for which TT is true. Hope that helps. Jeff Mirwaisi

1 0