Re: Modified version of l_dispatcher.h -- please try it.

On Sunday 04 March 2007 21:31, David Fang wrote:
> > 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?

Read on.....

> > 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).

As I said ...  C-style initialization.  It is legal for the 
0-initialization to happen in blocks, like the formal 
constructors, at least as I interpret what I see.

That guarantee you mention is not guaranteed to work.  If you 
don't specify you get the default constructor.

>         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.

I really wanted it to be static storage but that leads to order 
dependencies.

Generally, I believe in the Muntz approach.

I never intended to use the map's size().  It doesn't work 
anyway, because a failed lookup adds a new entry with NULL.