gnucap-devel
[Top][All Lists]
Advanced

[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 13:43:58 -0500
User-agent: KMail/1.9.5

On Wednesday 07 March 2007 11:47, Scott Dattalo wrote:
> You can achieve static allocation and control the order which
> objects are allocated.

There is no way that is absolutely consistent and portable.  
That is the issue.  

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

You are thinking C.  This is C++.  What you say for C works for 
C++ but it is too much work.  There are easier ways.

In C++, the global constructors are called when a library is 
loaded, and locating functions is automatic through the derived 
class - "vtable" mechanism.  You don't need to bother with the 
explicit call to init(), or manually setting up those function 
pointers.

The issues that were discussed in this thread, now solved well 
enough for now, apply when a library that can be a dynamic 
library is instead static linked.  If all plugins were attached 
by using dlopen, there would be no problem.

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

Do you ever use operator[] to index your map?  It returns an 
lvalue, which adds a default object for a failed lookup.  It 
doesn't hurt anything.





reply via email to

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