[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it.
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it. |
Date: |
Wed, 7 Mar 2007 00:03:19 -0500 |
User-agent: |
KMail/1.9.5 |
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.
Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it., Dan McMahill, 2007/03/04