Re: Standard Ada Preprocessor

["Robert I. Eachus" <rieachus@comcast.net>]

Warren W. Gay VE3WWG wrote:

> As said before, I prefer a portable platform neutral code
> as much as the next guy. But when you start writing bindings
> and such that must bind to _many_ different situations,
> this simply becomes impractical.

I feel here like I am being castigated for something I have never said. 
  (No, I am not saying Warren is attacking me, just that I have the 
feeling that I am not getting my point across.)

The problem is that there is an underlying philosophical difference, and 
until and unless you accept the "Ada" philosophy you will be 
uncomfortable programming in Ada.  Once you "get it" Ada becomes as 
comfortable as well broken-in shoe.  There are still some minor lumps 
and bumps--but you don't notice them.

For a second assume that there are things that do require a preprocessor 
to do in Ada.  Now look at the long debate here, from the point of view 
that one group uses preprocessor directives in with clauses and the 
public part of packages, while I argue that this is poor programming 
practice and that all preprocessor directives belong in unit bodies 
where possible, and as few such bodies as possible.

And actually that IS the way I feel.  With one minor exception.  When 
you do the necessary work to collect all of the pre-processor decorated 
code in one spot, surprise!  There isn't any left.

But there is really a trick to this, and it is important to understand. 
  In the military the problem is known as micro-management.  Problems 
and issues should be addressed at the right level, without solutions 
imposed from above which may not be appropriate in a particular situation.

In Ada where this often comes up is in representation clauses.  You 
either tell the compiler to "do it right" with alignment directives, or 
lay things out bit-by-bit with rep clauses.  If there is an 
implementation INdependent format you have to follow, sometimes because 
you are interfacing directly to some special-purpose hardware.  Fine, 
use static layouts.  But these are, by their nature not compiler 
dependent in any way.  The hardware you interface with, or the other 
computer system you interface with, or whatever, specifies the layout. 
If some compiler can't support those rep clauses, it is not time for 
preprocessor directives, it is time to either fix the compiler or get a 
new one.  The bits MUST look exactly like that, it is not an option.

The second case is where you want the bits laid out a certain way for 
efficiency.  Fine, no problem...and no rep clause required or needed. 
That is the compiler's job.  You may use alignment clauses and specify 
that some components are aliased, but the compiler will take all that 
into account when it lays out the record.  If two compilers do it 
differently on different hardware because, say, Integer is a different 
size?  Not a problem.  If you needed the records to be identical on 
different hardware, you would have specified things that way.

So as far as I am concerned, the case of rep specs that compile on one 
compiler and not on another is almost uninteresting.  If you care, it is 
a big problem.  But it has to be fixed by fixing (or replacing) one 
compiler.  A pre-processor CAN'T help.  If you are trying to use 
pre-processor directives to force efficient layouts on each different 
platform, you are micro-managing.  Let each compiler choose the layout 
it thinks is best.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush