Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it.

[David Fang]

> This is a modified version, that uses a pointer work-around,
> hopefully taking care of the initialization order issue.
>
> It works for the cases I tried ..  I was able to move globals.o to either
> end of the link list and it works both places.

Hi Al,
        Nicely done.  I looked over the new version, and it's one form of
what I expected.  I was able to move globals.cc to various locations from
front to back of the SRCS lists, and gnucap started up fine in all cases.
Platform: Mac OS X, 10.4.8, powerpc7400, apple-g++-4.0.1.

> There are still some theoretical issues.  I am not sure whether this
> is actually an improvement in all cases, because the impact is less
> predictable.

        Can you elaborate on the concern?

> For this to work, it essential that class DISPATCHER does not have
> a constructor or destructor.  Then it makes the assumption of
> C-style initialization.  For every C++ compiler I have seen, this is
> true, but it is not guraranteed by the standard,

> If DISPATCHER has a constructor, it could be called after the
> manual initialization already happened, wiping it out.

        However, you can guarantee that the object is not-touched by a
constructor/destructor by writing empty ones without doing anything to the
_map member.  (Yeah, I know this goes against 'good practice'.)  Since
_map is a plain-old-date (POD) pointer, it'll just sit uninitialized
(0-initialized pre global init).
        Am I correct in assuming you don't care about the _map being
memory-leaked?  (never deleted)  If you guarantee that everything that
gets installed is eventually uninstalled, you could have the last one out
the door delete the _map, basically using install-uninstall as your
reference count mechanism.  You might have to _map.erase() instead of
clobbering an entry with NULL if you're going to use the map's size() as
the counter.

> If the link order is correct, as defined as resulting in the correct
> construction order, this version should work the same as before.
> If the link order is incorrect, as defined as resulting in an incorrect
> construction order, this version seems to hide the problem, so it
> only shows when compiled with all debugging turned on.

>From brief testing, "works for me"!


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)