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

al davis wrote:
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.

Maybe I'm missing something, but in gpsim I have statically allocated objects, C++, dynamically loadable modules, and support Linux, Windows, BSD and (at one point) Solaris. However, I typically don't statically link everything.

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.

Thanks for pointing this out. Yes I do use operator[], but I think I use it in a way in which a default object is not created. For example, instead of using operator[] to index into the map to search for a particular key, I use the find() method. This returns an iterator pair that can be compared against end(). I'm assuming find() does not create a superfluous default object in the map. When adding to the map, I do use operator[].

Scott




reply via email to

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