Boost logo

Boost :

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-11-01 09:47:48

Stefan Seefeld wrote:
> Hi Boris,
> Boris Kolpackov wrote:
>> Also note that you can get this behavior with a normal reader and a
>> visitor but with a modular design as a bonus:
>> typedef visitor<handle1, handle2, ...> v;
>> reader r (filename);
>> while (node* n = v.visit (n);
> That's right, but that is inefficient: The reader already does know
> the type of the token, but in the name of 'modular design' you throw
> it away only to recover it later with an extra round-robin dispatch
> through the visitor. What is the advantage of that ?
The handlers are easily switchable. Imagine XML handling that looks
something like this:

function basic(parser&) : gets the events at the root. If a <foo>
element is encountered, calls foo to handle its contents. If a <bar>
element is encountered, calls bar to handle its contents.

function foo(parser &): handles <foo> and its contents.

function bar(parser &): handles <bar> and its contents.

If a token is returned and dispatched through a local visitor, this
looks kind of like this (C++-like pseudo-code, note the lambdas to make
things easier):

void basic(parser &p)
  visitor basic_visitor(start_tag = (start_tag_info &t){
    if(t.tag_name() == "foo") foo(p);
    else if(t.tag_name() == "bar") bar(p);
  while(node *n = basic_visitor.visit(n);

void foo(parser &p)
  visitor foo_visitor( ..., end_tag = (end_tag_info &t){
    if(t.tag_name() == "foo") return_parent;
  while(node *n = basic_visitor.visit(n);

void bar(parser &p) like foo().

With the visitor stored in the parser, foo would have to store the old
visitor, place its new one, then restore the old one when it's finished.
Which is less nice.

Sebastian Redl

Boost list run by bdawes at, gregod at, cpdaniel at, john at