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

[taashlo@sandia.gov (Tad Ashlock)]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F722C53.9020808@attbi.com>...
> taashlo@sandia.gov wrote:
> > Hello,
> > 
> > I'm trying to port a small C++ library to Ada95.  Most of it is going
> > quite well in that the Ada implementation is smaller, simpler, and
> > easier to follow than the C++ implementation.  But I've ran into a
> > hurdle with the following C++ construction:
> > 
> > class Test {
> > ...
> > protected:
> >    struct s {
> >       int data[8];
> >    };
> > ...
> >    void bar(s *t, int foo);
> >    #define BAR(foo_) if (1) { \
> >       static s t_; \
> >       bar(&t_, foo_);\
> >    } else ((void)0)
>  ...
> > };
> > 
> > What happens is that when you do this:
> > 
> > BAR(10);
> > 
> > it expands to this:
> > 
> > if (1) {
> >   static s t_;
> >   bar(&t_, 10);
> > } else ((void)0);
> > 
> > This, in effect, creates a (hidden) static local variable for each call
> > to bar().  This static variable (actually a structure, t_) is used to
> > cache information for each unique call to bar() such that subsequent
> > calls from that location can be processed *much* faster.
> > 
> > For instance, the following code would create three of the hidden local
> > variables:
> > 
> > for (int i = 0; i < 55; ++i) {
> >    switch (wozit()) {
> >       case 1: BAR(10); break;
> >       case 2: BAR(20); break;
> >       case 3: BAR(30); break;
> >    }
> > }
> > 
> > The first time each BAR() is encountered, it does the full processing,
> > but subsequent calls to the *same* BAR() used it's unique cached
> > information and go much faster.
> > 
> > Any ideas on how I can achieve this with Ada95?
> 
> Wild, I'm going to give you "ideas," and let you implement one of them.
> 
> First, the normal way to implement this in Ada would be to break the 
> action into a generic instantiation followed by a call of the 
> instantiated generic.  But if you want to follow that pattern here it 
> gets tricky to wrap it in a generic.  You would need a subprogram access 
> type declared at an outer level, the generic instantiation would create 
> a procedure and pass back the access value for subsequent calls.

I've been trying ideas along these lines for a few days, but I haven't
been able to make them work.  I understand how the procedure would get
created, but I don't understand where the data is uniquely cached for
each procedure call. (The C++ implementation above does it in t_->data.)

> The fast way to implement this of course is to use self-modifying code. 
>   Ugh!  You can manage this with subprogram parameters.  The first call 
> goes to the 'generic' version which returns among other things the new 
> address to call.  Sort of:
> 
> procedure Subp is
> 
>    type Subprogram_Record;
> 
>    type Subprogram_Pointer is
>         access procedure(X: in Integer; P: in out Subprogram_Record);
> 
>    type Subprogram_Record is record
>      SP: Subprogram_Pointer;
>    end record;
> 
>    procedure Test (X: in Integer; P: in out Subprogram_Record)
>    is begin null; end;
> 
>    Bar_Pointer: constant Subprogram_Record := (SP => Test'Access);
> 
>    Local_Pointer: Subprogram_Record := Bar_Pointer;
> begin
>    Local_Pointer.SP.all(3, Local_Pointer);
> end Subp;

I'm not following this one at all.  Where is the cached data?

> This code is a bit ugly, but it does compile.  And since Bar_Pointer is 
> a constant, you can't accidently pass it to Test.  There might be a 
> cleaner cleverer way to do it, but this works.
> 
> The cleanest option may be to run your code through a preprocessor and 
> use a similar macro.

Yeah, I've thought of that one too.  And due to performance requirements,
it might end up being my only option.  But even that isn't as straight
forward as in C++ due to the fact that the data cache needs to be
declared in the *package's* declarative region with a unique name.
(Where the C++ implementation could declare the data cache statically in
a block immediately before the function call.)

Thank you so much, Robert, for taking the time to reply to my question.

Tad