- Boost - lists.boost.org

MSVC 7.1 bug with recursive template typedefs
by Samuel Krempp 24 Feb '05

24 Feb '05

As I said in the thread in [boost-users] about "using boost::format with STLPort" ( <421CC3D6.4010600(a)crans.ens-cachan.fr> ), I've come across a bug with recent MSVC's (tested on MSVC 7.1, and apparently MSVC 8 fails the same way). Does anyone know if this is a known MSVC bug ? Or should someone report that ? The following sample causes error C2244 ("unable to match function definition to an existing declaration") template<class T> struct A { typedef T* some_type; }; template<class T> struct B { typedef typename A<T>::some_type le_type; le_type some_f(); }; template<class T> typename B<T>::le_type B<T>::some_f() { le_type x; return x; } Replacing B<T>::le_type with A<T>::some_type when defining B<T>::some_f() seems to work around the bug. Regards, -- Samuel

2 1

RE: [boost] Re: Boost library inclusion: generic tree containers?
by Brian Braatz 24 Feb '05

24 Feb '05

Extremely interesting. I am working on a similar thing. Except I am doing this- the iterators take policies which tell how to get the parent and children of a node I am sorry I have not dug DEEP into either bodies of work yet. But in a nutshell, I am holding a tree of objects, and then using a template library (similar to BIL- except it is "classical Interface based programming") to QueryInterface (QI) the objects. (this is the opposite of how BIL works) I have gotten working the ability to QI the objects and apply operations to anything in the tree from X node down based on interface supported. This very curious technique is one I am working to evolve into something for controlling dynamic UI objects. In any case, I am writing this to share what I have been working on. Maybe it will give you some ideas. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard Peters Sent: Wednesday, February 23, 2005 12:44 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost library inclusion: generic tree containers? ----- Original Message ----- From: "Rene Rivera" <grafik.list(a)redshift-software.com> > Additionally, I'm also of the opinion that the "iterator" concept should > be kept as it's currently used in STL. An object that does more than an > iterator, because it happens to be an iterator in a tree should be > called something else, "cursor" comes to mind. If it's really > masquerading as a sub-tree, or a tree, then call it a tree. If it's a > pointer to a node in the tree, then perhaps a "node_pointer". Mixing the > terms will just cause more confusion than it's worth. Reading some of > your later posts I can see the confusion already creeping in. My > suggestion would be for you to formalize the different parts of a tree: > > * node; Holder for the value, structure pointers, and tree coloring > information > > * cursor; pointer to a node with tree specific operations to move the > cursor within the tree and to interrogate the tree > > * iterator; linear traversal of the nodes in the tree > > * tree; the container of nodes and producer of cursors and iterators, > and the needed allocators I think these formalizations of different parts of the tree is a very good start, but I'd like to see the iterator eliminated for a while, or at least totally decoupled from the tree: The reason for this is Separation of Concerns. A tree class is a container quite similar like the standard containers in that it stores values, but the big difference is that the structure of the tree matters, instead of the sequence. Therefore, I think the tree class should provide functions to navigate through the tree, and functions to alter the structure of a tree, like insertion, deletion, and rotation. These functions should probably work on things like the above-defined cursor. Once this tree class is built, then it is time to start thinking how the structure of the tree should be translated to flat sequences. There are of course a lot of options: depth first, breadth first, only a single level, or from top to a single node. Navigating in this way is done via 'normal' iterators. These iterators work on cursors, and should not be a part of the tree class itself (the iterator type should not be a member of the tree class). These iterators are like 'cursor-to-iterator adaptors'. So I guess my point is this: The tree doesn't need a normal or default or any iterator type, because it doesn't have a proper meaning: a tree is about structure, not about sequence. Translating that structure into a sequence can be done outside the tree. best regards, Richard Peters _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[typeof] template template parameters, etc.
by Arkadiy Vertleyb 24 Feb '05

24 Feb '05

Hi all, The typeof submission has been updated to include the latest features, most notably support for *template template parameters*. Please take it in the in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/ (typeof.zip). (Most credit for the template template parameters support goes to Peder). Among other additions are support for enum template parameters, and reused template parameters, such as in: template<class T, T n> class x; Also the REGISTER_TEMPLATE_X macro has been eliminated. Instead, the REGISTER_TEMPLATE macro has been "overloaded" to cover all the cases of template registration. Please see the documentation for more details. Regards, Arkadiy

3 2

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

24 Feb '05

Hi Andreas [snip guard discussion] > > The equivalent with a custom reaction would look as follows: > > struct StState : fsm::simple_state< StState, StOuter, > fsm::custom_reaction< EvEvent > > > { > fsm::result react( const EvEvent & evt ) > { > if ( cond ) > return transit< StRes0 >( &StRes0ActCtxt::Action0, evt ); > else > return transit< StRes1 >( &StRes1ActCtxt::Action1, evt ); > } > }; > > For a human, IMHO this is easier to read. Easier, but less consistent. In complicated fsms (many transitions, lots of state local data and functions), I find it extremely useful to separate the 'state' (as it would appear on a state chart) from the 'other stuff' (local variables, local functions - anything looking like 'normal' c++). Given that guards tend to be fairly common in real world fsms, we should be able to spot them in the same way we spot normal transitions. > > > I haven't thought about the implementation too much admittedly. > > Having > > this would be a big help in automatically generating UML state charts. > > Agreed. It is much easier to implement a tool that only needs to look at > the state declarations than one that additionally also needs to analyze > code inside functions. For this reason I think I will eventually add a > construct similar to the one you suggested. But, since such a tool does > not yet exist (to my knowledge), this is of fairly low priority at the > moment. > OK. My argument is largely philosophical. > > The library produces large binaries. > > The produced binaries certainly will never be small. Out of curiosity, > do you have any numbers (number of states -> size of executable)? > I just ran a few tests. The original camera example compiles to 103k using -O3 and -DNDEBUG (and the other options specified in the Makefile in the distribution). When stripped, the size came down to 56k. I added a new nonsense state in Shooting.hpp: struct Shooting2 : fsm::simple_state<Shooting2,Camera, fsm::transition<EvShutterRelease,NotShooting> > {}; I also changed Shooting's EvShutterRelease to transition to the new Shooting2 state. The compile size increased to 111k, and the stripped size increased to 61k. In my application (as described below), I added a state with 9 transitions that was empty otherwise. When compiled with -g and stripped (our current 'release mode'), the size of the executable increases by around 30k. I didn't spend too much time on these tests, and I ran them with a version of boost::fsm that is a few months old (my apologies). > > 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. > > I guess that is for the hundreds of machine objects you mention below? Yes. The in memory size is not important for this application (we have far more RAM than persistent storage). Regards 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. ##########################################################################

2 1

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