Re: [Gnucap-devel] Modified version of l_dispatcher.h -- please try it.

[al davis]

On Wednesday 07 March 2007 16:54, Scott Dattalo wrote:
> 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.

The issue is simple:  A container must be constructed before you 
put anything in it.  It doesn't work well to put stuff in a 
container that doesn't exist yet.

If the container is in the static linked portion of the program, 
and all of the contents are in the dynamic linked portion, 
there is no problem.  There is a potential problem when static 
linked objects can also be in that same container with the 
dynamic objects.  The problem is that you must take care to 
assure that the container is constructed first.  That's all.

The construction order of objects within a translation unit is 
defined.  The construction order of objects in different 
translation units is not defined.  That is the problem.

Putting a list of static objects in a single file violates 
encapsulation, and causes maintainance problems.


>
> >> 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[].

find() does prevent the superfluous default object, but there is 
no harm in having them.  The simpler code resulting from 
allowing the superfluous objects to exist is easier to 
understand and easier to prove correct.

Let's see:

Option #1:

THING* get_it(std::string& key)
{
  return map[key];
}

Option #2:

THING* get_it(std::string& key)
{
   iterator p = map.find(key);
   if (p != map.end()) {
      return *p;
   }else{
      return NULL;
   }
}

Not too bad ....  Complexity/cost metric ,,,  Option#1 ..1 line 
of code.  Cost = 1
Option #2 .. 6 lines, 1 decision, 2 distinct paths ...    
Effective cost = 14.  (lines + decisions) * (# of paths)

Ok ... these metrics are a kluge, but they do give a view, and 
be used as a mechanism for taming complexity.  These little 
details add up when applied thousands of times in a large 
project.