Re: Standard Ada Preprocessor

From: Warren W. Gay VE3WWG (warren_at_ve3wwg.tk)
Date: 01/27/04 

Date: Tue, 27 Jan 2004 12:30:19 -0500

Robert I. Eachus wrote:
> 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.)

It could be argued that MDC, lurkers and I are not getting
our 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.

The "Ada phylosophy" works until you start interfacing to many
foreign components (normally C ones) that cannot be relied upon
to be the same. You cannot even rely on the same API to be
available, in some cases. This is where things get real ugly.

The practical side of many bindings, requires me to deal
with portability issues in a "C wrapper". This may not always
be entirely possible to avoid because of C macros, but I
would like to put more code into Ada than into C. But I
can't, because Ada cannot deal with the portability issues.
That is, unless I resort to processes outside of the language
(like gnatprep and code generation).

I would just like people to look at some of the "practical"
issues without resorting to quoting "ivory tower" notions.
Again, all of this would be _optional_ anyway. The military
can outlaw it for all I care, but for general purpose
computing, it needs to be addressed.

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

I am not against any of these techniques. What I am against
is the notion that "no, we don't do it that way because it
might get abused". There is a need for it in the GP case,
perhaps not in the military and embedded case. But if you're
only going to do the later, than why add an Annex to deal
with COBOL interfaces and features?

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

Point to some major open sourced work, where it can be
compiled and installed on Win32, Linux and many flavours
of *NIX, and I might believe this. Why is it that large
portions of Florist is generated code? I know that C macros
demand this, but what about the API issues? This says
preprocessing all over it.

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

The military can make its own rules and enforce them. But again,
*sigh*, in the general purpose world, things need to be a bit
more flexible.

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

If you are binding to an API that returns a structure, and on
one platform you get 3 members back, and on another you get 5,
then just how is any Ada construct going to address this? What
if the order of member placement is different? These are the
kind of portability issues that Ada programmers must wrestle
with when binding to existing code.

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

Again, you look at the simple cases where everything is the
same. When dealing with portability issues, you are looking
at representation issues where the interfaces are DIFFERENT.

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

Your examples _are_ uninteresting. The interesting ones are the
ones that differ according to platform, platform version, and
the choice of library(ies) used. 

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)
  • Re: <ctype.h> toLower()
    ... >> So what is the output from your compiler if it's not a TU, ... and your code includes your implementations tolower function then you don't ... > platform, without even having to know which character set is used on that ... Even talking about portability in concept of porting source code across ...
    (alt.comp.lang.learn.c-cpp)
  • Re: C language portability support
    ... When you have platform specific functionality which you want ... > 1 The typedef name intN_t designates a signed integer type with ... What the hell has this got to do with portability? ... >> Virtually every C compiler exposes important platform specific ...
    (comp.lang.c)
  • Re: How does one read in 32 bits at a time from a binary file?
    ... Portability with reading on a binary level is a hard thing. ... You write the file on one platform. ... same compiler, same compiler version on the same platform. ... The 'read head' will move just by 'read'-ing ...
    (comp.lang.cpp)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)