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

Scott Dattalo <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
al davis wrote:
> I really wanted it to be static storage but that leads to order 
> dependencies.
>   

Al,

(I've just joined the list and may have missed relevant points already 
discussed in this thread.)

You can achieve static allocation and control the order which objects 
are allocated.

On all OSes, there is an initialization function called whenever a 
dynamically loaded library is loaded. For example dlopen() calls a 
function 'init()'. This initialization function can statically declare 
objects and then initialize global pointers to point to them. This costs 
one level of indirection, but it is safe. In general, if all of your 
static objects are within the same scope, you can control the order in 
which they're allocated. If they're not in the same scope, then it 
depends on the linker. (This is definitely true for file scoping , but 
may not be true for function or name space scoping).

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

In gpsim (the gnupic simulator for Microchip PIC microcontrollers) I 
just switched over the implementation of the symbol tables from STL list 
containers to STL map containers. I don't use map's size method, however 
I never add null objects to the symbol table either. Why would a failed 
map lookup end adding a null object to the map?

Scott
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.