[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: Scott Dattalo
Subject: Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it.
Date: Wed, 07 Mar 2007 08:47:50 -0800
User-agent: Thunderbird (X11/20061219)

al davis wrote:
I really wanted it to be static storage but that leads to order dependencies.


(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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]