Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)

[Marin David Condic <nobody@noplace.com>]

While I find preprocessors distasteful and can see how they can become 
an unholy mess (look at some of that "Portable C" code to which you 
refer! :-) I'm afraid I'd have to agree to some extent.

Ada ought to have some sort of answer for how to deal with maintaining a 
single body of code that has to compile for more than one environment. 
Even if you have the same target hardware and two different compilers 
(even from the same manufacturer sometimes!) you can have statements 
that will compile on one but not on the other. Isolation with separate 
bodies is sometimes difficult to do and always complicates the build 
process. Some form of conditional compilation would make the job easier.

Naturally that has risks and can lead to all sorts of abuse. I'm not 
sure there is a good answer, but Ada ought to try to address it somehow. 
Eventually, developers need some scheme for how to deal with 
implementation differences and platform differences. To the extent that 
it can be handled via isolation in "standard" & "portable" interfaces, 
this is a good thing. But we've seen reluctance to do so for a variety 
of reasons, not the least of which is the time & expense to get those 
interfaces specified & implemented by the vendors. Even then, you'll 
have differences that can't be cleanly dealt with that still give full 
access to the underlying features of an OS or implementation.

I'm not smart enough to figure out if there is a better answer than 
conditional compilation, so I'd have to agree that some sort of standard 
method of getting conditional compilation or preprocessing would be a 
good thing.

MDC


Warren W. Gay VE3WWG wrote:
> 
> (I'll probably take some heat for this but..)
> 
> In my opinion, the preprocessing of C code has made C the clear
> winner (and now C++) for portability. Examples of code that
> compiles and runs on the ancient Atari, BeOS, UNIX and Windows
> etc are not hard to find. Unless the Ada code is pretty
> much disconnected from the operating system, you won't find
> the same level of portability.
> 
> Granted preprocessing results in ugly code. But it is
> pretty clear that developers prefer to maintain one
> source module, rather than trying to keep 10+ parallel modules
> synchronized (for each supported platform).
> It is certainly my preference to centralize maintenance.
> Any time you can centralize the control of something,
> maintenance becomes cleaner, and is forced
> to be consistent (much like database normalization).
> 
> gnatprep obviously helps to address this issue for the "gnat
> world". But IMHO Ada could be well served if there was a standard
> for an Ada preprocessors.  Its use of course would be optional
> (for the purests and those situations where it is not needed),
> but a standard would make Ada code more easily portable.
> 
> Failing that, everyone must bake their own solution to this
> problem. Many maintain that by centralizing problem code into
> separate libraries works well enough. But this does not help
> in the cases where a product can be compiled with different
> options turned on or not (say from a Makefile). In other cases,
> it may mean enhancements involve maintenance of several parallel
> modules, instead of one centralized location.
> 
> I havn't checked to see if any current discussions are
> taking place about the possibility of standardizing a
> preprocessor. But if were to guess, it has been discussed
> and summarily dismissed on religious grounds ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================