comp.lang.ada
 help / color / mirror / Atom feed
From: Marin David Condic <nobody@noplace.com>
Subject: Re: Preprocessor functionality equivalent ideas needed
Date: Thu, 11 Dec 2003 13:34:42 GMT
Date: 2003-12-11T13:34:42+00:00	[thread overview]
Message-ID: <3FD8726E.1000205@noplace.com> (raw)
In-Reply-To: crPBb.9463$rP6.3773@newsread2.news.pas.earthlink.net

While I agree with the general concept of separate bodies for separate 
implementation-specific modules, I have occasionally run into situations 
where it would have been nice if I had a compiler directive of some sort 
to go one way or another depending on some condition. This is especially 
true where I might need to keep code portable between two different 
compilers. Also its a big problem when what needs to be different is in 
the *specification* of something. (Yes, I know, "One more layer of 
indirection...." can go fix it - but why should it be so hard?)

Maintaining two sets of files has a problem - its two sets of files! :-) 
You change something in one file & you have to remember to make the 
update to the other one. You want to give the code off to someone else, 
you thus have to supply both sets of files and sufficient information to 
enable them to build it either way. Someone unaware of the parallel 
paths can really mess things up. Some sort of conditional compilation 
can simplify matters. (The existence of pragma Assert and pragma Debug 
in the Gnat compiler attest to at least *some* usefulness to conditional 
compilation.)

I have sometimes been able to simulate conditional compilation by 
putting code into an if statement with a constant flag. Some compilers 
will optimize away the unreachable code. But that doesn't help much in 
declarative parts or in situations where a set of statements is 
acceptable to one compiler, but not another. I'd hate to see Ada develop 
into the unholy mess that C is with all of its macros and other 
confusing garbage, but maybe a couple of pragmas that let alternate 
versions of the code exist within a single file might not be a bad thing?

MDC

Jeffrey Carter wrote:
> 
> 
> Generally, you define a package specification for the functionality you 
> require, then implement different bodies for it for the different 
> situations.
> 


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

     "Trying is the first step towards failure."
         --  Homer Simpson

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




  reply	other threads:[~2003-12-11 13:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-10 20:04 Preprocessor functionality equivalent ideas needed Greg Milford
2003-12-10 21:41 ` Ludovic Brenta
2003-12-11 17:12   ` sed and perl - yuck [Was Re: Preprocessor functionality equivalent ideas needed] Martin Krischik
2003-12-16  0:40     ` Waldek Hebisch
2003-12-16 20:52       ` Martin Krischik
2003-12-10 22:29 ` Preprocessor functionality equivalent ideas needed Georg Bauhaus
2003-12-12  5:52   ` Simon Wright
2003-12-11  1:07 ` Jeffrey Carter
2003-12-11 13:34   ` Marin David Condic [this message]
2003-12-11 17:49     ` Jeffrey Carter
2003-12-11  5:39 ` Steve
2003-12-11 16:59 ` Martin Krischik
  -- strict thread matches above, loose matches on Subject: below --
2003-12-11 12:52 Lionel.DRAGHI
2003-12-11 15:51 Lionel.DRAGHI
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox