Re: How to Emulate C++ Macro with Static Local Variable?

[Jeffrey Carter <spam@spam.com>]

taashlo@sandia.gov wrote:

> I went up one order of magnitude, you went up four.  You appear to play
> the game much better than I. :-)

There's no profit in thinking small :)

> If the ID is simply an index into an array of caches, it doesn't require
> you to "modify the code that interprets the ID".  So it's down to "add
> new IDs" and "insert the new call".
> 
>>With an instantiation you add the new instantiation and
>>the new call.
> 
> Same as above.  Please give more detail on the "significant
> differences".

And if the ID is NOT simply an index into an array? Generics handle that
case exactly the same way. IDs do not; in the general case, you have 
some processing to deal with the IDs.

> But don't forget to delete the associated generic instantiation, too.

You probably want to delete the instantiation, but you don't have to. A 
good compiler will eliminate the resulting code; in the worst case, you 
have unused code.

> I don't know of a manual process that can prevent me from being human
> and therefore making mistakes.  And the penalty for making a mistake of
> accidentally re-using an instantiation name is that the location that
> gets called first will determine the contents of the cache for both
> locations.  In a dynamic system where the one that gets called first
> changes from execution to execution, this could result in a *very*
> difficult bug to find.

Yes, but this is the argument against using C/++ and for using Ada. It's 
very easy to make simple mistakes that compile and run and are very 
difficult to find. If that's acceptable to you in C/++ it should be 
acceptable in Ada.

> I'm attempting to port a C++ library that supports implementing
> hierarchical state machines (think UML statecharts) directly in a
> programming language (as opposed to using a tool to generate the code).
> The function in question performs a state transition.  You pass in the
> target state and it discovers the path from the current state to the
> target state.  It then caches this information so that subsequent calls
> from the same location don't need to perform the same "discovery"
> process.
> 
> Yes, the transition path could (possibly) be cached by the state
> transition function based on the starting state and the target state.
> (In Ada, is it possible to somehow use the *value* of subprogram access
> parameters?  In this system, a state is defined as a subprogram access
> type.)  You can use dynamic allocation.  Or you can reserve enough space
> so that you can cache all state transitions.  Or you can can have some
> combination of both so that when the reserved space is filled, more will
> be allocated.  Or you can come up with more options that I haven't
> thought of yet.  And if I was just developing an application, a large
> number of choices is great.  But for porting a library whose utility
> ranges from GUI applications running on workstations to small embedded
> systems, having to make a choice will certainly narrow this range.  And
> it won't win me any converts from C++ because the C++ implementation
> didn't require you to know ahead of time how many state transitions
> there are, or suffer the overhead of dynamic allocation, or have to come
> up with a unique name for each cache.

This is much clearer. Yes, access-to-subprogram values are no different 
than any other access values. You can store them and compare them. So a 
solution based on the 2 states sounds like a good approach to use.

> One solution would be to come up with a way to automatically pre-cache
> the state transitions during initialization.  This way, you could
> statically reserve cache space and if you didn't have enough cache space
> reserved, you would find out during start-up.  I'll look into this.

Could you do a "2-pass" process? The 1st pass would tell you how big 
your cache needs to be; then you could statically allocate enough space 
(Ada allows you to statically allocate space based on values not known 
until run time) and fill it during the 2nd pass.

As a compromise, starting with a default amount of space that's usually 
big enough, and doubling it if you run out of space, is usually 
acceptable, even for some embedded systems.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29