Re: [Texmacs-dev] Efficiency of C++ switch-statements

[Joris van der Hoeven]

> To use virtual methods, things would have to be redesigned a bit
>
>   class tree_rep: abstract_struct {
>   public:
>     virtual ~tree_rep() {}
>     virtual tree_label label() = 0;
>     virtual tree exec(edit_env_rep* e) = 0;
>     friend class tree; };
>
>   class atomic_rep: public tree_rep {
>   public:
>     string label;
>     virtual ~atomic_rep() {}
>     virtual tree_label label(); // return STRING
>     inline atomic_rep (string l);
>     virtual tree exec(edit_env_rep* e); // return this
>   };
>
>   class compound_rep: public tree_rep {
>   public:
>     array<tree> a;
>     inline compound_rep (tree_label l, array<tree> a2): tree_rep (l), a (a2) 
> {}
>     virtual ~compound_rep() {}
>     virtual tree exec(edit_env_rep* e); // default case
>
>   // An example class for a compound tree
>   class decorate_atoms_rep: public compound_rep {
>     inline decorate_atoms_rep (tree_label l, array<tree> a2): compound_rep 
> (l, a2) {}
>     virtual tree_label label(); // return DECORATE_ATOMS
>     virtual tree exec(edit_env_rep* e); // handle this case
>   };
>
> A good thing with this approach is that an appropriate class hierarchy
> can explicit a lot of the common structure of the big switches.
>
> Locality of code can be preserved by defining virtual methods with the
> same name in the compilation unit where they are used. So this would
> lead to compact code (good cache behaviour) and a maintainability
> comparably to switch statements (all definitions are toghether).

Of course, I have also considered this possibility.
The point is that locality is not really preserved,
because each of the "virtual tree exec(edit_env_rep* e);"
have to be defined explicitly for the class tree.

This stuff always boils down to whether you take the data or
the routines on the data as the primary information for dispatching.
At the moment, I chose it to be the data (for trees), because I want
to see trees as data. Unfortunately, with C++ you necessarily have
to make a choice. With higher level languages, dispatching may be
done following more complex patters, and that is exactly what
I am working to for the scheme interface.

In fact, as to Scheme, I intend to provide three major forms
of dispatching:
  1) On DRD (like modes).
  2) On inside-out context (most inside wins).
  3) Overloading on type.
Mainly 1 and 2 will be important and 1 is already supplied,
although not systematically. If I have time, I will finish this
during the next (and last) reorganization phase in januari.

Coming back to the C++, the number of big switches is actually
quire reduced (mainly execution and typesetting), so the current
situation is not that bad and we can continue to live with it.
The next reorganization of the tree data-type should rather permit
to associate dynamic call-backs to trees. This would for instance
allow us to define reliable cursor positions in an efficient way and
to provide a DOM-like interface. Another interesting extension of
our tree class would allow for non-string leafs. This might be
interesting for a more efficient macro language. But more on
all that later: things have to be done in order...