Preprocessing Ada

Preprocessing Ada

[David Starner]

I'm writing a library in Ada and I've hit a couple things where I would
use #ifdef's in C. I would like to offer alternate algorithims for the
same function that can be chosen at compile time. I would also like to
add an expensive verification call to the front of each function that
can be turned on and off at compile time (expensive enough that I want
it to be seperate from Pragma Assert.)

1. Is there a more 'Ada'-like way to do this?

2. Will cpp (the C pre-processor) work cleanly with Ada?

3. Is there a DFSG-free preprocessor for Ada? (I hate to go this way,
because that means that everyone who compiles the program needs a
special preprocessor.)

Re: Preprocessing Ada

[David Botton]

Use of pragma Inline and/or gnatprep.

David Botton


David Starner wrote:
> 
> I'm writing a library in Ada and I've hit a couple things where I would
> use #ifdef's in C. I would like to offer alternate algorithims for the
> same function that can be chosen at compile time. I would also like to
> add an expensive verification call to the front of each function that
> can be turned on and off at compile time (expensive enough that I want
> it to be seperate from Pragma Assert.)
> 
> 1. Is there a more 'Ada'-like way to do this?
> 
> 2. Will cpp (the C pre-processor) work cleanly with Ada?
> 
> 3. Is there a DFSG-free preprocessor for Ada? (I hate to go this way,
> because that means that everyone who compiles the program needs a
> special preprocessor.)

Re: Preprocessing Ada

[Dale Stanbrough]

David Starner  wrote:

" I'm writing a library in Ada and I've hit a couple things where I would
  use #ifdef's in C. I would like to offer alternate algorithims for the
  same function that can be chosen at compile time."


Use different packages and use package renames...

package Fast_Algorithms is...

package Small_Alogrithms is...


package Chosen_Package renames Fast_Algorithms;


Alternatively get your sccs to select the appropriate package, and have
two different versions of the same named package.


I would also like to
> add an expensive verification call to the front of each function that
> can be turned on and off at compile time (expensive enough that I want
> it to be seperate from Pragma Assert.)
 

package Verification_Control is

   Do_Verification : constant Boolean := true; -- or false!

   procedure Verify (Item : boolean; Message : String);

   pragma Inline (Verify);

end;

package body...

    procedure Verify (...) is
    begin
       if Do_Verification then...

    end;
end;


Even a 1/2 sensible compiler should be able to eliminate calls to the
routine, I would guess that they can completely eliminate this routine.


> 2. Will cpp (the C pre-processor) work cleanly with Ada?

no, it gets caught on attributes (the single ') i believe.


" 3. Is there a DFSG-free preprocessor for Ada? (I hate to go this way,
  because that means that everyone who compiles the program needs a
  special preprocessor.)"

ACT supply a preprocessor that works with Ada. See the documentation
for details.


Dale

Re: Preprocessing Ada

[fraser]

paene lacrimavi postquam David Starner <dstarner98@aasaa.ofe.org> scripsit:

>I'm writing a library in Ada and I've hit a couple things where I would
>use #ifdef's in C. I would like to offer alternate algorithims for the
>same function that can be chosen at compile time. I would also like to
>add an expensive verification call to the front of each function that
>can be turned on and off at compile time (expensive enough that I want
>it to be seperate from Pragma Assert.)

>1. Is there a more 'Ada'-like way to do this?

Personally, I use packages or the 'separate' mechanism to stick the
various versions into different source files, put these source files
(OK, we're in GNAT territory now) into different directories, then
use -I to select the version I want to compile with.

Using a constant Boolean to turn on the verification check will more
than likely completely eliminate the call at compile time.

>2. Will cpp (the C pre-processor) work cleanly with Ada?

Attributes will probably cause the most obvious problems.

>3. Is there a DFSG-free preprocessor for Ada? (I hate to go this way,
>because that means that everyone who compiles the program needs a
>special preprocessor.)

If you're using GNAT, there's gnatprep, though I haven't used it myself.

cheers,
Fraser.
(change 'i's to 'y's for my real email -- sorry)

Re: Preprocessing Ada

[Marin David Condic]

David Starner wrote:
> 
> I'm writing a library in Ada and I've hit a couple things where I would
> use #ifdef's in C. I would like to offer alternate algorithims for the
> same function that can be chosen at compile time. I would also like to
> add an expensive verification call to the front of each function that
> can be turned on and off at compile time (expensive enough that I want
> it to be seperate from Pragma Assert.)
> 
> 1. Is there a more 'Ada'-like way to do this?
> 
This is an area where angels fear to tread! :-) One thing I have found
works with some compilers is to create a Boolean constant somewhere and
put "if" statements into the code testing this constant. If the compiler
is good, it will know which path cannot be reached and will not generate
code for that path. Changing the constant and recompiling will let you
select the alternate path. Of course, this doesn't give you the ability
to do any conditional compilation in the declarative region.

But this is not "The Ada Way" anyway. What your problem sounds like is
one where you have divergent paths in your configuration. If you don't
have a Configuration Management tool to help you with divergent paths,
you might consider one. You can construct something rudimentary with
subdirectories and search paths. Doing this would enable you to have a
common interface specification for a package and then having two or more
implementations conforming to the specification which are maintained on
divergent paths. Putting things in the code for conditional compilation
seems to me to be a poor substitute for good CM.

Another thing you might want to consider WRT your expensive verification
call would be importing a subprogram as a generic parameter. That, or
obtaining an access object to a subprogram. In either case, it sounds
complex and you might want to rethink the necessity of doing any of it.
An alternative here is also the divergent path notion of CM where down
one path you get a body with full-up implementation of the verification
and down the other path, you get a subprogram stub which, hopefully,
gets optimized away.

Hope this helps.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic