
Following on from my last post regarding composites, I've dug out my work on acyclic visitors, and dealing with them alongside composites. I've put these up on a web server for people to have a look at as well. Again I would be interested in comments. http://dah.me.uk/pattern_tl/acyclic_visitor.hpp http://dah.me.uk/pattern_tl/composite_visitor.hpp I've also added some demonstration files to show the sorts of class you might create with the composite and the composite visitors http://dah.me.uk/pattern_tl/NodeBase.h http://dah.me.uk/pattern_tl/VisitorBase.h In use the acyclic visitor is very similar to Alexandrescu's - with only one notable change. I have moved the default visit function into the visitor rather than having it in the visitable. This means that any visitable hierarchy can interact with lots of different visitors, with different default actions and potentially different return types. I find this much more intuitive than the DefaultCatchAll template in Alexandrescu's version. The composite visitors allow you to traverse a given composite in a given order calling the visitor on every node in the tree. I wrote this because of the number of times that you tend to do this particular operation when using composites. You simply need to inject in the composite visitor to turn a visitor into a composite visitor. This results in a slightly odd double-visitation stage where the visitor accepts the visitable, iterates over it and accepts the visitor back again. I generally tend to use this by first setting up a visitor eg: class MyVisitor : public pattern_tl::base_visitor<>, public pattern_tl::visitor<MyNode>; Then creating versions that implement the different ordering strategies as necessary eg: class MyVisitorTopToBottom : public MyVisitor, public pattern_tl::composite_visitor<MyVisitorTopToBottom,MyNode> { }; Then the visiting sequence is initiating by letting the visitor accept the head of the composite: MyVisitorTopToBottom visitor; visitor.accept( head ); Again, any feedback and/or interest would be appreciated. Dave Handley

On Wed, 12 Jan 2005 22:01:07 -0000, Dave Handley wrote
Again, any feedback and/or interest would be appreciated.
Well, my feedback is going to be fairly shallow since I don't have lots of time to look it over, but what I see looks pretty good. Both of the composite and visitor stuff would be nice additions. One interesting question on composite is whether a boost::tree would really be all that's needed and might be a more general component that could be used to implement composite. Of course, you are really depending on pointer semantics and the clone, so it wouldn't be a minor change of course to go down that path... I think instead of trying to create a 'patterns' library I would make 2 standalone libraries: vistor and composite. The fact that these are 'patterns' (ie: well known designs) isn't really strong enough to bind them together. Jeff

Good day to All. Working with boost::mpl recieve subj. How to solve this problem? Will it be solved in next VC++? My solution for boost. In mpl everywhere you wrote: typedef smth type; may be it better to write: struct type : public smpth {}; (or, as was discussed before: struct type1 : public smpth {}; typedef tepe1 type; ) if smth is very-very long name, then for compiler: in first case type is very-very long name. in second type is simply "type" and it is only 4 letters. Would the compiler work correctly? Faster? Slower? Other points/goals? --Sincerely Yours,-- --\ SergeY /-- --<>\\\ PisarchiK ///<>-- --<>()<>--Never surrendeR--<>()<>-- mailto:Sergey_pisarchiK@tut.by

Sergey Pisarchik writes:
Good day to All.
Working with boost::mpl recieve subj.
How to solve this problem?
It's hard to say without seeing the code; see http://tinyurl.com/6uug7 for one possible solution.
Will it be solved in next VC++?
This is a question for the Microsoft folks. You can ask it, for example, on news:microsoft.public.dotnet.languages.vc.
My solution for boost. In mpl everywhere you wrote:
typedef smth type;
may be it better to write:
struct type : public smpth {};
(or, as was discussed before:
struct type1 : public smpth {}; typedef tepe1 type; )
if smth is very-very long name, then for compiler: in first case type is very-very long name. in second type is simply "type" and it is only 4 letters.
Would the compiler work correctly? Faster? Slower? Other points/goals?
Most of the MPL algorithms are required to operate on all types, including the ones you cannot derive from. -- Aleksey Gurtovoy MetaCommunications Engineering

Directed at Dave Handley, I look forward to examining your libraries as soon as I read up on those patterns. Alexandrescu's _Modern_C++_Design_ just arrived, as well as the GoF book on patterns, so I'm gonna do some busy reading over the next few days. I'm reading the section on typelists right now and finding it quite exciting :D -Jason
participants (5)
-
Aleksey Gurtovoy
-
Dave Handley
-
Jason Hise
-
Jeff Garland
-
Sergey Pisarchik