Conditional compilation

Conditional compilation

[Steinar Haug]

Hi,

I'm developing programs for both DEC VAX (VAX/VMS Ada compiler) and
SUN-3 (Alsys Ada compiler). I need to use some form of conditional
compilation. The Alsys compiler has the BEGIN_COMPILE/END_COMPILE
pragmas to control the compilation but I have not found any similar
mechanism for the VAX/VMS compiler. Can anybody out in Adaland tell
me how to do conditional compilation with the VAX/VMS compiler?

The LRM contains a reference [10.6] to conditional compilation but
it seems rather cryptic and it is not obvious to me how I could use
it in practice.

Steinar Haug             ! ARPA:        haug%vax.runit.unit.uninett@tor.nta.no 
Database Research Group  !   or:        steinar@tor.nta.no                     
Computing Research Center! EAN(X.400):  haug@vax.runit.unit.uninett            
 University of Trondheim ! BITNET/EARN: haug@norunit                           
7034 Trondheim, NORWAY   ! VMS Mail:    psi%02422530001003::12423              
                         !       or:    psi%0242211000114::z_haug_s            

Re: Conditional compilation

[rds]

On the issue of conditional compilations in Ada...

Our Ada requirements would be well suited by a conditional compilation
but our application must be portable. My interpretation of LRM 10.6(2)
is since the compiler omits code not referenced the programmer can
omit code by conditionally (not) referencing it and setting static
conditions for evaluation at compile time. 

If this is, in fact, what the LRM intends to say it is an insufficient
method for conditional compilation. Consider the following scenario:

Package A is generic with a generic type parameter. Package B is generic
with the same generic parameter. A particular system requires only
package A and another system requires both A & B. 

B's compilation requires the existance of an instantiated version of A.

It is important that the customer with system A who does not need package B
not get package B and not neccesarily know of the existance of package B.

An appropriate solution (in a C environment) is to conditionally
include the code for package B with package A at compilation time.

The LRM does not require the implementation of an include like feature.

Is there an accepted practice for "including" files in the Ada world?

Richard DeSimine
AT&T Bell Laboratories
(201) 386-2059

Re: Conditional compilation

[rjs]

In article <909*haug@vax.runit.unit.uninett>
haug%vax.runit.unit.uninett@TOR.NTA.NO (Steinar Haug) asks:
>I'm developing programs for both DEC VAX (VAX/VMS Ada compiler) and
>SUN-3 (Alsys Ada compiler). I need to use some form of conditional
>compilation.
>
>The LRM contains a reference [10.6] to conditional compilation but
>it seems rather cryptic and it is not obvious to me how I could use
>it in practice.
>
This seems to be the type of mechansim that 10.6 is referring to:

-- At the beginning of your source, or in a separate package that you
-- include in any module that needs to conditionally compile based on
-- the target, make the following declarations.

type MACHINE_NAME is (VAX, SUN3);
TARGET : constant MACHINE_NAME := VAX;  -- Change this line to compile
                                          -- for a different target


-- Then wherever you need to conditionally compile code based on the 
-- target machine, use the following:

case TARGET is
  when VAX =>
	-- VAX specific code goes here.
  when SUN3 =>
	-- SUN-3 specific code goes here.
end case;


Of course this solution assumes that you can put all your conditional
stuff in a case statement.  The compiler is allowed to not generate any
of the code for the obviously FALSE case.
Good Luck.

	Robert Snyder
	{ihnp4|clyde}!moss!rjs
	(201) 386-4467
The above statements are my own thoughts and observations and are not
intended to represent my employer's position on the subject(s).

Re: Conditional compilation

[Jeff Bartlett]

In article <28254@clyde.ATT.COM>, rds@moss.ATT.COM writes:
> 
> If this is, in fact, what the LRM intends to say it is an insufficient
> method for conditional compilation. Consider the following scenario:
> 
> Package A is generic with a generic type parameter. Package B is generic
> with the same generic parameter. A particular system requires only
> package A and another system requires both A & B. 
> 
> B's compilation requires the existance of an instantiated version of A.

1. if the customer is to do this instantiation of A then they must receive
   the source for B.

> It is important that the customer with system A who does not need package B
> not get package B and not neccesarily know of the existance of package B.

2. This implies that there are no packages in the minimal system that depend
	on B
     ==> no shipped executables need package B.
     ==> package B is supplied to customer in source or in a shipped
         compilation library

> An appropriate solution (in a C environment) is to conditionally
> include the code for package B with package A at compilation time.
 
The C source would have:
	#ifdef EXTRA_FEATURES
	#include "package_b.c"
	#endif

- the existance of package B should not be revealed in limited systems.
- the C source would reveal the existance of package B
- C is appropiate solution.
==> the customers do not get the source.

for the limited system:
    - if it is in a shipped compilation library compile everything
      and delete the interface and body for package B from the library

    - not supplied B in source form (for the case of user instantiated A and
      '#include "package_b.c"' is acceptable ).

    - these are separately compilable units.  Just don't compile the
      file containing package B.

Any bad assumptions or flaws in logic?

Are the any tests in the Ada compiler validation suite that checks that
compilation unit Y does not depend on the interface of B in the compilation
library?

    with B;
    procedure Y is
       K : B.TYPE1;  -- unref'd, may be removed
    begin
	if FALSE then
	    B.ROUTINE1;
	    K := 5;
	end if;
    end Y;

DecAda V1.5 has the library dependancy but no code or stack space was generated.

LRM 10.1.1.6 states that the 'with' will cause a library dependancy.  Should
the optimizer be allowed to revoke it or does a 'with' imply an explict
elaboration of package B regardless of the fact that there are no references
to B in procedure Y.

Of course this isn't allowed

   procedure Y is
   begin
      if FALSE then
	 declare
	    with B;
	    K : B.TYPE1;  -- unref'd, may be removed
	 begin
	    B.ROUTINE1;
	    K := 5;
	 end;
      end if;
   end Y;

if it were then the compiler could safely assume that the elaboration of B
was not needed.
     
> Richard DeSimine
> AT&T Bell Laboratories
> (201) 386-2059

Jeff Bartlett
Center for Digital Systems Research
Research Triangle Institute
jb@rti.rti.org		...mcnc!rti!jb

Re: Conditional compilation

[Arny B. Engelson]

In article <28254@clyde.ATT.COM>, rds@moss.ATT.COM writes:
> 
> On the issue of conditional compilations in Ada...
> 
> Our Ada requirements would be well suited by a conditional compilation
> but our application must be portable. My interpretation of LRM 10.6(2)
> is since the compiler omits code not referenced the programmer can
> omit code by conditionally (not) referencing it and setting static
> conditions for evaluation at compile time. 
 
LRM 10.6 is insufficient for conditional compilation because it is not
REQUIRED that an implementation check for code that will never be executed
and eliminate the corresponding object code.  It (the LRM) only says that
it is permissible to do this as part of optimization.  Some compilers may
do it, some may not, and some may do it only if (the equivalent of)
/optimize is used.

This is an (optional) optimization step, not a standardized way of
providing conditional compilation.  Personally, I think the "pragma"
solution for conditional compilation works well, and would like to see
it standardized and provided with all implementations.  Comments?

  - Arny Engelson

Re: Conditional compilation

[Dave Seward]

In article <1369@wayback.UUCP> arny@wayback.UUCP (Arny B. Engelson) writes:
>In article <28254@clyde.ATT.COM>, rds@moss.ATT.COM writes:
>> On the issue of conditional compilations in Ada...
>[...]
>This is an (optional) optimization step, not a standardized way of
>providing conditional compilation.  Personally, I think the "pragma"
>solution for conditional compilation works well, and would like to see
>it standardized and provided with all implementations.  Comments?

I don't like the pragma approach as it is very hard to specify it within
the bounds of pragma legality. RM 2.8(8) says "An implementation is not
allowed to define pragmas whose presence or absence infuences the legality
of the text outside such pragmas." This means that conditional compilation
pragmas could not be used to select one of multiple possible declarations,
as, without the pragmas, the program would be seen to have multiple,
conflicting declarations of the same identifier.

Additionally, a significant conditional compilation facility requires a
meta-language of its own for definition and evaluation of conditions upon
which to include text into a compilation or not. This would probably be
force fit into existing Ada rules for declarations and expressions, or
would stick out like a sore thumb.

I am in favor of a distinct facility in the programming environment, like
a preprocessor, for doing file inclusion, conditional compilation, and
the like. Go ahead and standardize it, but don't force it into the Ada
compiler. A compiler should compile the text you feed into it. Defining
that text is a job for other tools.

Dave Seward
uunet!actnyc!djs

Re: Conditional compilation

[brucej]

djs@actnyc.UUCP states several objections to embedding conditional
compliation within an Ada compiler:

> I don't like the pragma approach as it is very hard to specify it within
> the bounds of pragma legality.  [RM references & explanation deleted]

> Additionally, a significant conditional compilation facility requires a
> meta-language of its own for definition and evaluation of conditions upon
> which to include text into a compilation or not. [more deletions]

> I am in favor of a distinct facility in the programming environment, like
> a preprocessor, for doing file inclusion, conditional compilation, and
> the like. Go ahead and standardize it, but don't force it into the Ada
> compiler. 

Here at Harris, we discovered a need for conditional compilation when
we first attempted to rehost and retarget the toolset we ship with our
Ada compiler.  Our approach was to create a preprocessor to perform 
that conditional compilation, and to implement code in the compiler
to automatically invoke the preprocessor as needed.  Ada source files
have a `.a' suffix,  while files in need of preprocessing have a `.pp'
suffix.  If the compiler's input file ends in `.pp' it first invokes
the preprocessor ("a.pp <foo.pp >foo.a"), and then compiles the `.a' file.

Preprocessing as a separate pass is cheap and efficient.  Invoking an
expensive global optimizer to perform this function is overkill.  Besides,
the optimizer has more than enough to do anyways.

While it would be presumptuous of me to propose that Harris' preprocessor
syntax be standardized,  I can at least point out the preprocessor's great 
value in allowing us to use a common set of source code for our Ada toolset 
for all of our different host/target combinations.  We found a.pp so useful
that we released it as part of our toolset.

----------
Bruce Jones 
brucej@hcx1.harris.com
Harris Computers, Fort Lauderdale, FL

re: conditional compilation

[Emery]

Bill Wolfe writes:
>   Now are you REALLY contending that any competent maintainer is 
>   going to fail to understand the following?

>     type foo_bar (MACHINE : SYSTEM{NAME := SYSTEM.SYSTEM_NAME) is record
>        X : Integer;
>        case MACHINE is
>           when VAX => Y : Float_64; 
>           when IBM_PC_WITH_8087 => Y : IEEE_Float;
>        end case;
>     end record;

I contend that any competent compiler will REJECT this code for (at
least) two reasons:
	1.  There is no guarantee that an arbitrary compiler will have
either of the two enumeration values "VAX" or "IBM_PC_WITH_8087" in
the type SYSTEM.NAME.  Furthermore, the declaration is ILLEGAL if the
(enumeration type) SYSTEM.NAME has additional values besides the two
mentioned (although the addition of "when others => null;" would at
least fix this problem.) 
	2.  Even if these two exist, the program is still semantically
ILLEGAL, as you would have two components both named Y, which is not
permitted. 

Furthermore, there are many reasons besides host machine name for
doing separate compilation.  One that comes immediately to mind occurs
when a specific feature is present or absent from the version of the
operating system generated for a given machine.  I've seen this rather
frequently in Unix.

L.T.F.L.
				dave emery
				emery@aries.mitre.org

conditional compilation

[Matthew Woodcraft]

I noticed the following statement in the Steelman requirements:

"6C. Conditional Control. There shall be conditional control structures
that permit selection among alternative control paths.
...
Only the selected branch shall be compiled when the discriminating
condition is a translation time expression."

Am I right in thinking that the second sentence above isn't true of
Ada-as-we-know-it (for example, if a non-selected branch has a
compile-time error)?

-M-

Re: conditional compilation

[Ira D. Baxter]

Conditional compilation is a really practical tool for managing part
of the configuration space problem, which is why it is so popular in C/C++.

It is true that if you implement it as a preprocessor, that you end up
with all kind of abominable constructs (this found in real code):
             if (.....) {
               ......
             #if ...
                     .....
                     } else  {
                    ...
             #endif
                    ...
             endif
[I see this an an indictment of the programmer, not the language,
but it would be nice if the language prevented it].
A real problem in understanding such constructs is not only
just other maintainer's ability to understand what it says,
but an inability to get a tool that can read such a construct
and reason about it (extract call graphs, etc.)
This is a significant problem for the reverse engineering and
analysis tools we build.

It is much better if the language enables conditional compilation
directly.    We have an internal programming language, not Ada,
in which conditional compilation is allowed (defined in the grammar)
around the major
language constructs:    function defintions, declarations, modules,
etc., and it works very nicely without allow silly stuff like the above.
Much easier to handle for automated tools, as well as people.

--
Ira Baxter, Ph.D., CTO  idbaxter@semdesigns.com 512-250-1018x140
Semantic Designs, Inc., www.semdesigns.com FAX 512-250-1191
12636 Research Blvd #C214, Austin, Texas 78759

Marin D. Condic <mcondic-nospam@acm.com> wrote in message
news:39857E5F.33C40014@acm.com...
> Matthew Woodcraft wrote:
> >
> > I noticed the following statement in the Steelman requirements:
> >
> > "6C. Conditional Control. There shall be conditional control structures
> > that permit selection among alternative control paths.
> > ...
> > Only the selected branch shall be compiled when the discriminating
> > condition is a translation time expression."
> >
>
> Now I'm not sure that a true conditional compilation feature based on
> lexical exclusion is really such a good idea.

Re: conditional compilation

[Marin D. Condic]

Matthew Woodcraft wrote:
> 
> I noticed the following statement in the Steelman requirements:
> 
> "6C. Conditional Control. There shall be conditional control structures
> that permit selection among alternative control paths.
> ...
> Only the selected branch shall be compiled when the discriminating
> condition is a translation time expression."
> 
> Am I right in thinking that the second sentence above isn't true of
> Ada-as-we-know-it (for example, if a non-selected branch has a
> compile-time error)?
> 
I know from experience with a few different embedded compilers that it
was a common optimization to remove dead code. A construct such as:

declare
    Debug : constant Boolean := False ;
begin
    if (Debug) then
        Do_Some_Stuff ;
    else
        Do_Some_Other_Stuff ;
    end if ;
end ;

would result in the call to Do_Some_Stuff being removed from the object
code. It was a reasonably effective method of getting conditional
compilation. However, I don't recall that the unreachable code could
ever be syntactically incorrect - or why you would want it to be.

Of course the weakness of this is that you can't pull this trick in a
declarative part. It would be nice to have a mechanism for controlling
that sort of thing as well. (Yes, GNAT has pragma Debug - it's just not
part of the standard - yet.)

Now I'm not sure that a true conditional compilation feature based on
lexical exclusion is really such a good idea. I've been doing a lot of
C++ work lately using Visual C++/MFC and it never ceases to amaze me
that people actually *like* this kind of thing. I'm constantly tracking
down problems related to #ifdef and #include causing multiple instances
of things getting brought in - or not. And of course, the compiler
doesn't care because its C. Would Ada really want to get caught up in
that web?

BTW: Visual C++ has a *really* nice debugger. But then again, it needs
it. :-) It would be nice to see an environment this powerful for Ada.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================

Re: conditional compilation

[Marin D. Condic]

Simon Brady wrote:
> 
> Maybe I'm being pedantic here, but I don't consider this an acceptable
> substitute for "real" conditional compilation. Sure, with a good
> compiler it achieves the results (debug support with zero runtime cost
> in the production build), but from a maintenance perspective it strikes
> me as a Bad Thing.
> 
Said I had a use for it. Didn't say I actually liked it. :-)

Pragma Debug is almost certainly a better way to go for debug code -
unless you want to leave the debug code in place. (Good reasons to do
that sometimes.) I've not often run into situations where I thought
conditional compilation was essential to getting the job done. It may be
useful, but may not be the best way to get there.

I've used the "if" method when I've had to maintain a configuration that
ran on a brassboard demo and another version that ran on the real
hardware. Sometimes you've got hardware on one machine that doesn't
exist on the other and its easier to maintain one flag that builds the
software either way. In that case its a reasonably natural way of
getting what you want because you'd probably be doing this kind of flow
control with a runtime variable anyway. Of course it doesn't let you get
rid of declarations that you don't need for a given build, so it is a
weak substitute in that sense.

I guess I don't really know what to think on this issue. Conditional
compilation may be useful. So might "include" directives or macros or
other features found in other languages. Still, it may not be in the
spirit of The Ada Way and they may cause more problems than they fix. I
guess I don't find any really compelling reasons to expand the language
to include them. But I'm listening if you want to make a case....

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================

Re: conditional compilation

[William J. Thomas]

How much dead code would you like in your flight control laws when your
inherently unstable fighter aircraft is pulling 6 G's.  Safety Critical
Systems and Mission Critical Systems in general should not be the home of
endless lines of code that act as scaffolding and flying buttresses through
a relatively limited phase of the software lifecycle.

The original developers of the language knew what they were doing when they
prohibited its use.  The problem is best solved with adjunct tools, and good
configuration control, not language features.

Besides that, just try to certify a piece of code with the FAA that has all
sorts of conditional compilation in it. As a matter of fact in level A
certification even that little piece of Ada code used in the previous
example would raise a flag.

Keep it out of the language, its lived for close to twenty years without it
so don't spoil a good thing. As stated before there are other languages that
make extensive use of it, if conditional compilation is what you must have
then by all means use them.

WJT

Re: conditional compilation

[Simon Brady]

"Marin D. Condic" wrote:
> 
> I know from experience with a few different embedded compilers that it
> was a common optimization to remove dead code. A construct such as:
> 
> declare
>     Debug : constant Boolean := False ;
> begin
>     if (Debug) then
>         Do_Some_Stuff ;
>     else
>         Do_Some_Other_Stuff ;
>     end if ;
> end ;
> 
> would result in the call to Do_Some_Stuff being removed from the object
> code. It was a reasonably effective method of getting conditional
> compilation.

Maybe I'm being pedantic here, but I don't consider this an acceptable
substitute for "real" conditional compilation. Sure, with a good
compiler it achieves the results (debug support with zero runtime cost
in the production build), but from a maintenance perspective it strikes
me as a Bad Thing.

Why? Because it overloads the meaning of the if-then control structure.
Compile-time configuration control and runtime flow control are quite
separate issues, and IMO they need to be clearly distinguished for both
human and automated readers of the code. For example, some Unix tools
take a "print debug info" command-line switch, so the above code might
be just as sensible if Debug was a variable and not a constant. In a
large, unfamiliar source tree, how would you know?

From my own (small-scale) experience I like what conditional compilation
can achieve, especially the way it allows debug builds loaded up with
paranoic self-test code.\x18I would certainly like to see a standardised,
portable method of achieving such ends in Ada - however, the question of
(a) whether conditional compilation is the way to do it and (b) whether
support belongs in or out of the language seems to be very much open.
I'd be curious to hear what people with larger-scale experience think of
this.

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: conditional compilation

[Ted Dennison]

In article <3985FB16.82D140BB@below.for.email.address>,
  Simon Brady <see@below.for.email.address> wrote:
> From my own (small-scale) experience I like what conditional
> compilation can achieve, especially the way it allows debug builds
> loaded up with paranoic self-test code.\x18I would certainly like to see
> a standardised, portable method of achieving such ends in Ada -
> however, the question of (a) whether conditional compilation is the
> way to do it and (b) whether support belongs in or out of the language
> seems to be very much open. I'd be curious to hear what people with of
> larger-scale experience think this.

I've often had to figure out someone else's large C program that was
chock full of target-dependent #ifdef's. Its a *nightmare*. Often times
you have to dig deep into the bowels of an even more complicated
makefile to even figure out which conditional branches your compilation
is using. I suspect the people who specified the orignial Ada
requirements had similar experiences, as support for C-like conditional
compilation was explicitly forbidden.

The Ada approach is supposed to be that you have different source files
for different targets, and use your build tools to choose between them.
From a maintanence standpoint I like that idea a whole lot better. But
it requires that the program be organized ahead of time for this
purpose. Developers aren't used to having to think about these issues
before they start coding. So most of the time the need for the new
target appears after the code is already complete. Then it annoys people
that they have to redesign all their code, rather than just graft on the
new target like they could with C.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: conditional compilation

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> I've often had to figure out someone else's large C program that was
> chock full of target-dependent #ifdef's. Its a *nightmare*.

Yes, that can be a nightmare.

> The Ada approach is supposed to be that you have different source files
> for different targets, and use your build tools to choose between
> them.

That can be a nightmare, too.  I've seen cases where there were six
different versions of the same file, for six different target
environments, each just slightly different.  The bulk of the code in
those files is the same for all targets.  This kind of code duplication
leads to trouble: a bug gets fixed in one version, a different bug gets
fixed in a different version, and pretty soon the six files have
diverged, and you have no idea which differences are truly target
dependent, and which are accidental.

So if you're going to use that approach, it's important to make the
target dependent files as small as possible -- make them contain *only*
the stuff that really needs to be target dependent.  Unfortunately, you
might not know which code is target dependent ahead of time.

Tagged types can help here.  You can have a default version of each
procedure, which works on most targets, and override it only on the one
weird target that needs something special.

- Bob

Re: conditional compilation

[Laurent Guerby]

Robert A Duff <bobduff@world.std.com> writes:
> [...] So if you're going to use that approach, it's important to make the
> target dependent files as small as possible -- make them contain *only*
> the stuff that really needs to be target dependent.  

I do think this is pertinent to any method to manage target dependant
code, ie make it nonexistant or as small as possible, and in addition
write piles of documentation on the why side, mention it in the top
level internal documentation.

> Unfortunately, you might not know which code is target dependent
> ahead of time. [...]

I would say that it is true only when writing your first multi target
software. After that, you get the idea ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: conditional compilation

[Simon Brady]

Ted Dennison wrote:
> 
> I've often had to figure out someone else's large C program that was
> chock full of target-dependent #ifdef's. Its a *nightmare*. Often times
> you have to dig deep into the bowels of an even more complicated
> makefile to even figure out which conditional branches your compilation
> is using.

Been there, done that... I think the literate programming crowd offer a
useful insight here: programs aren't the same thing as representations
of programs, and what the compiler sees isn't necessarily what the
programmer should see. C source loaded up with #ifdefs isn't really C
source - it's a template for generating C source. Sometimes the
programmer wants to view the template (for a configuration-management
perspective), other times she's interested in a particular instance of
it.

Imagine an editor integrated with the C preprocessor that supported such
multiple views (I guess it would also have to grok makefiles and other
source-molesting tools like lex and yacc). Ideally you'd never need to
see a preprocessor directive except when you were in "configuration
managment mode" - you could switch between targets, debug/release views
or whatever, and always be dealing with a direct representation of that
particular instance of your program. This seems quite doable, and could
alleviate many of the problems you've described. Sure, no tool can
outwit human perversity, but something that reduced my grappling with
the preprocessor by even 50% would be a good thing.

(Btw, Ch. 18 of Stroustrup's "Design and Evolution of C++" presents a
succinct discussion of why the C preprocessor is evil, yet has been so
successful and will be so hard to banish:

   Cpp does [its] tasks pretty badly, mostly by indirect means, but
   cheaply and often adequately. Most important, Cpp is available
   everywhere C is, and it is well known. This has often made it
   more useful than far better, but less widely available or less
   widely known, macroprocessors.     (p425)

I like Stroustrup's sensitivity to "sociological" issues - he repeatedly
makes the point that it's not enough to offer better alternatives to C's
shaky features, you also have to offer features that real-life C
programmers will want to switch to.)

> The Ada approach is supposed to be that you have different source files
> for different targets, and use your build tools to choose between them.
> From a maintanence standpoint I like that idea a whole lot better. But
> it requires that the program be organized ahead of time for this

A fair comment, but allow me to play devil's advocate here (to
paraphrase Martin Condic, just because I've found conditional
compilation useful I don't necessarily like it). The above approach may
be clean and effective for multi-targeting. However, where I most use
conditional compilation in my C/C++ work is for inline debugging code (I
admit to being heavily influenced by Steve Macguire's "Writing Solid
Code" here). This is stuff I want tightly bound to the code it supports,
both in terms of sharing the same lexical scope and (more importantly)
of reading sequentially so maintainers see it as an integral part of the
routine. Again, it's that template vs. source distinction - the approach
I'm describing involves delivering two products (program and integrated
self-test), which sometimes I want to view together and sometimes I
don't.

As Martin has noted, pragma Debug achieves most of this, with the
exception of debug-only declarations (which can be useful, although
perhaps not useful enough to justify messing with the language). And the
mythical environment I've described above could work with Ada pragmas as
easily as C #ifdefs (was such a capability part of the APSE dream of the
80s?). But, just for discussion's sake, is there a better "Ada way" to
achieve what I'm describing? Or is it so rooted in the existence of Cpp
as to be inherently opposed to the Ada spirit?

OK, enough speculation for one day - time to go do some work (yawn).

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: conditional compilation

[Simon Brady]

I wrote:
> 
> (to paraphrase Martin Condic
                   ^^^

Eep! Sorry, Marin!

Simon Brady                                            sjbrady
Research Assistant, Computer Science Dept.               at
University of Otago, Dunedin, New Zealand            acm dot org

Re: conditional compilation

[Georg Bauhaus]

Simon Brady (see@below.for.email.address) wrote:
: Ted Dennison wrote:
: > 
: > I've often had to figure out someone else's large C program that was
: > chock full of target-dependent #ifdef's. Its a *nightmare*.

: C source loaded up with #ifdefs isn't really C
: source - it's a template for generating C source.

There is a thread on this topic (plus on related included #includes)
in comp.os.plan9, entitled "Installing the updates", in which
Rob Pike and Howard Trickey offer their view.

Re: conditional compilation

[Robert A Duff]

Simon Brady <see@below.for.email.address> writes:

> Been there, done that... I think the literate programming crowd offer a
> useful insight here: programs aren't the same thing as representations
> of programs, and what the compiler sees isn't necessarily what the
> programmer should see.

I don't like so-called literate programming for the same reason I don't
like C macros.  In order to understand the code, you have to imagine the
actual output of the macro preprocessor.  (I admit that C macros are the
worse of the two, of course.)

In any case, from a language design point of view, if you think the
compiler should see things in a different order or different
organization than human beings, then clearly the programming language is
poorly designed.  Macros can be used to get around poor language
designs.

> Imagine an editor integrated with the C preprocessor that supported such
> multiple views (I guess it would also have to grok makefiles and other
> source-molesting tools like lex and yacc). 

I imagine you would get into a mode where you hack upon one particular
target, and break all the others.

- Bob

Re: conditional compilation

[Georg Bauhaus]

Robert A Duff (bobduff@world.std.com) wrote:

: I don't like so-called literate programming for the same reason I don't
: like C macros.  In order to understand the code, you have to imagine the
: actual output of the macro preprocessor.

Agreed if literate programming  was about code, but it is
not.  It is about English, about explaining algorithms in
English (or your preferred human language), about not having
to worry about the outcome of the processor because the
processor takes care of that. Ideally, though.

If the language has facilities to express your design the
way you think about design, good.  Literate programming
helpers can help with this.  I'm exaggerating, but ideally
you would not have to worry about the outcome of
preprocessors, compilers, optimizers, anything.

Of course you should and Knuth, supposedly having coined
the words "literate programming", has written one of the
books about inputs and outcomes, and that you shoul know
how to worry about them.

Re: conditional compilation

[Brian Rogoff]

On Wed, 2 Aug 2000, Robert A Duff wrote:
> In any case, from a language design point of view, if you think the
> compiler should see things in a different order or different
> organization than human beings, then clearly the programming language is
> poorly designed.  

That isn't so clear to me. I don't think Common Lisp, Scheme and Dylan are 
poorly designed because they include powerful macro systems. I believe 
their designers feel that syntactic abstraction is important enough to 
include facilities in the language for extensible syntax. That may
conflict with some of the design goals of Ada, but I don't thnk it
clearly indicates poor design. 

> Macros can be used to get around poor language
> designs.

They can also be used to change the syntax of the language so that it is
more suitable for a particular problem. There are lots of things I don't
like about Lisp, but the inclusion of a powerful macro system is not among
them.

-- Brian

Re: conditional compilation

[Florian Weimer]

Robert A Duff <bobduff@world.std.com> writes:

> Simon Brady <see@below.for.email.address> writes:
> 
> > Been there, done that... I think the literate programming crowd offer a
> > useful insight here: programs aren't the same thing as representations
> > of programs, and what the compiler sees isn't necessarily what the
> > programmer should see.
> 
> I don't like so-called literate programming for the same reason I don't
> like C macros.  In order to understand the code, you have to imagine the
> actual output of the macro preprocessor.  (I admit that C macros are the
> worse of the two, of course.)

I think this argument is valid only to a limited extent.  After all,
there are plenty of language constructs which can be used to hide
details, and if a programmer has hidden the wrong details, this will
always make maintenance unnecessarily complicated.

Of course, the C preprocessor is bad, and its usage results in quite
a lot of bugs.  (IIRC the study carried out by Bell Labs on some of
their telephone switching software showed this quite drastically.)

Many of them are extremely non-obvious because there are many common
idioms associated with C macros which you tend to ignore when
reading the source, but which are quite intrusive and can cause
bugs by itself.  For example, after a while, you start to overlook
the "do { ... } while (0);" construct to make a macro expansion a
statement---until a "continue;" statement is part of the macro, which
is supposed to effect an outer loop. :-/ (I guess C macros are used
quite regularly to obfuscate flow of control because you can't use
subroutines for that.)

I don't have any experience in maintaining literate programs, but
the last time I tried to read such code, the algorithms were in fact
nicely documented, but even at the lower levels, the data flow was
very hard to trace even locally (in contrast to the control flow,
which was properly outlined, but which you could hide as well).  In
my experience, understanding the data flow is quite important if you
want to do some non-trivial changes to existing code.  I doubt that
the literate programming approach as exemplified by TeX is really that
maintainer-friendly.  If you are interested in such stuff, TeX is
very nice to read, but it's generally considered a dead end regarding
future development.  In fact, TeX has already been reimplemented in
Java, AFAIK not in strict literate programming style.  (Well, this
reimplementation is also an involuntary case study in the portability
of Java code with rather disappointing results.)

> In any case, from a language design point of view, if you think the
> compiler should see things in a different order or different
> organization than human beings, then clearly the programming language is
> poorly designed.  

This is a very good point.  On the other hand, with most programming
languages, you need some separate documentation for the overall
structure of the code, general design decision and so on.  AFAIK
literate programming tries to merge this kind of documentation with
the actual code.

Re: conditional compilation

[Robert A Duff]

sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus) writes:

> Robert A Duff (bobduff@world.std.com) wrote:
> 
> : I don't like so-called literate programming for the same reason I don't
> : like C macros.  In order to understand the code, you have to imagine the
> : actual output of the macro preprocessor.
> 
> Agreed if literate programming  was about code, but it is
> not.  It is about English, about explaining algorithms in
> English (or your preferred human language), about not having
> to worry about the outcome of the processor because the
> processor takes care of that. Ideally, though.

Ideally, indeed!

I'm afraid we haven't quite gotten to the point where we can ignore the
code, and just pay attention to the English explanation of the code.
I doubt we ever will, in fact.

The other day I was reading Knuth's book about MMIX, his new RISC
version of the MIX machine code.  The book contains literate programs of
various sorts: an assembler, an interpreter, and so forth.

I found the English prose to be quite nice.  So literate programming
succeeded in that regard.

But I found the code itself to be difficult to understand, partly
because it's written in a (strange dialect of) C, and partly because
it's so heavily macro-fied, as literate programs always are.

One example: there was a piece of code containing a "break" to exit a
loop.  This piece of code was not contained in a loop.  Which loop is it
exiting, I wondered?  The only way to tell was to hand-expand the
macros.

In my opinion, loop exits should be physically contained within the loop
their exiting.  Even C has this level of error checking.  But literate
programming succeeded in defeating even this simple (and good) rule,
making the code less readable than raw C code.

> If the language has facilities to express your design the
> way you think about design, good.  Literate programming
> helpers can help with this.  I'm exaggerating, but ideally
                                   ^^^^^^^^^^^^
> you would not have to worry about the outcome of
> preprocessors, compilers, optimizers, anything.

exaggerating!  :-)

> Of course you should and Knuth, supposedly having coined
> the words "literate programming", has written one of the
> books about inputs and outcomes, and that you shoul know
> how to worry about them.

- Bob

Re: conditional compilation

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On Wed, 2 Aug 2000, Robert A Duff wrote:
> > In any case, from a language design point of view, if you think the
> > compiler should see things in a different order or different
> > organization than human beings, then clearly the programming language is
> > poorly designed.  
> 
> That isn't so clear to me. I don't think Common Lisp, Scheme and Dylan are 
> poorly designed because they include powerful macro systems.

I completely agree with you, so if you think we disagree, I think you
misunderstand what I mean.  I have nothing against Lisp macros -- they
are quite powerful and useful.  Note that one feeds them directly to the
compiler, and also reads them as is.

What I object to, is using Literate Programming to stir the code around
in an obfuscatory manner.  In cases where Literate Programming improves
the structure of the code, that indicates a flaw in the underlying
programming language.  In cases where it damages the structure of the
code (see my previous post about loop exits), well, that's not a good
thing.

Note that Lisp macros operate at a completely different level than
text-based macros.  Lisp macros don't stir the code around in ways that
totally violates the language rules.  Text-based macros are evil.

>... I believe 
> their designers feel that syntactic abstraction is important enough to 
> include facilities in the language for extensible syntax. That may
> conflict with some of the design goals of Ada, but I don't thnk it
> clearly indicates poor design. 
> 
> > Macros can be used to get around poor language
> > designs.
> 
> They can also be used to change the syntax of the language so that it is
> more suitable for a particular problem. There are lots of things I don't
> like about Lisp, but the inclusion of a powerful macro system is not among
> them.
> 
> -- Brian

- Bob

Conditional Compilation

[Kenneth Kueny]

Does ADA have an analog to the C language #define, #ifdef constructs
commonly used to include or exclude certain blocks of code in different code
versions?

Thanks,

Ken Kueny

Re: Conditional Compilation

[Ted Dennison]

In article
<7FEFA9E5E3B3C4A5.90418F4BE7D5AE58.48E094CF81EC6BD3@lp.airnews.net>,
  "Kenneth Kueny" <kkuenyx@vctinc.com> wrote:
> Does ADA have an analog to the C language #define, #ifdef constructs

No, Ada does not have conditional compilation. When the language was
being designed, conditional compilation was expressly prohibited (for
very good reason).

There's a good discussion of this in one of our old FAQs at
http://www.adahome.com/FAQ/programming.html#macros . I'd repost it here,
but unfortunately the text is copyrighted. :-(

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Jeffrey Carter]

Kenneth Kueny wrote:
> 
> Does ADA have an analog to the C language #define, #ifdef constructs
> commonly used to include or exclude certain blocks of code in different code
> versions?

Yes. We write package specifications and have different implementations
(bodies) for different versions.

-- 
Jeff Carter
"Son of a silly person."
Monty Python & the Holy Grail

Re: Conditional Compilation

[David Starner]

On Tue, 19 Sep 2000 13:15:35 -0400, Kenneth Kueny <kkuenyx@vctinc.com> wrote:
>Does ADA have an analog to the C language #define, #ifdef constructs
>commonly used to include or exclude certain blocks of code in different code
>versions?

No. IIRC, the usual method is to make seperate bodies for the different
versions, and only compile the one you want to use. Alternately, you
can use the preprocessor of your choice on the code - gnatprep comes
with GNAT, or you can use M4 or some other generic preprocessor. (I've
heard cpp has problems with the ' attribute syntax, though.)

-- 
David Starner - dstarner98@aasaa.ofe.org
http/ftp: dvdeug.dhis.org
And crawling, on the planet's face, some insects called the human race.
Lost in space, lost in time, and meaning.
	-- RHPS

Re: Conditional Compilation

[E. Robert Tisdale]

Kenneth Kueny wrote:

> Does ADA have an analog to the C language #define, #ifdef constructs
> commonly used to include or exclude certain blocks of code
> in different code versions?

This is a bit confusing.
The C macro preprocessor wasn't originally part
of the C computer programming language.
It was, and still is, a separate program
which accepted a C program "source file"
and emitted a C program "translation unit".
The typical C compiler accepts a translation unit
and compiles it into assembly language code
then calls the assembler to generate machine code.
The ANSI/ISO C/C++ standards now specify
syntax and semantics for the C macro preprocessor
but you can still use the C macro preprocessor
on Ada source files as long as the translation unit
is an acceptable Ada program.
Try it.  It works.

Now, professional programmers almost never write
programs in Ada, C, C++ or any other standard
computer programming language directly.
They usually use perl, the m4 macro preprocessor,
the sed stream editor or some combination of tools
to write programs for them from "prototype files"
which they maintain instead of source files.
Of course, if you are distributing "open source" programs,
you will need to distribute the prototype files
and any special tools along with the source files
so that other programmers can help to maintain
an contribute to the prototype files as well.

Re: Conditional Compilation

[Larry Kilgallen]

In article <39C7C748.4A533989@netwood.net>, "E. Robert Tisdale" <edwin@netwood.net> writes:

> The typical C compiler accepts a translation unit
> and compiles it into assembly language code
> then calls the assembler to generate machine code.

> Now, professional programmers almost never write
> programs in Ada, C, C++ or any other standard
> computer programming language directly.
> They usually use perl, the m4 macro preprocessor,
> the sed stream editor or some combination of tools
> to write programs for them from "prototype files"
> which they maintain instead of source files.

You live in a strange different world !!!

Re: Conditional Compilation

[David Starner]

On Tue, 19 Sep 2000 20:06:32 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>The C macro preprocessor wasn't originally part
>of the C computer programming language.

You sure? It was definetly a part of K&R C, and it would be almost
impossible to build a C program without it.

>but you can still use the C macro preprocessor
>on Ada source files as long as the translation unit
>is an acceptable Ada program.
>Try it.  It works.

Maybe. cpp will emit errors about unterminted character constants,
it will chop up C comments, and do other unfriendly things. It
can work, but I'm not sure it's a great idea.

>Now, professional programmers almost never write
>programs in Ada, C, C++ or any other standard
>computer programming language directly.
>They usually use perl, the m4 macro preprocessor,
>the sed stream editor or some combination of tools
>to write programs for them from "prototype files"

Not that I've seen. For example, GCC and GNAT use prototype files
for machine descriptions, but for pretty much everything else
it's just straight code. moc (QT's preprocessor) is about the only 
largescale example of that I've seen.

-- 
David Starner - dstarner98@aasaa.ofe.org
http/ftp: dvdeug.dhis.org
And crawling, on the planet's face, some insects called the human race.
Lost in space, lost in time, and meaning.
	-- RHPS

Re: Conditional Compilation

[Jeff Allen]

Larry Kilgallen wrote:
> 
> In article <39C7C748.4A533989@netwood.net>, "E. Robert Tisdale" <edwin@netwood.net> writes:
> 
> > The typical C compiler accepts a translation unit
> > and compiles it into assembly language code
> > then calls the assembler to generate machine code.
> 
> > Now, professional programmers almost never write
> > programs in Ada, C, C++ or any other standard
> > computer programming language directly.
> > They usually use perl, the m4 macro preprocessor,
> > the sed stream editor or some combination of tools
> > to write programs for them from "prototype files"
> > which they maintain instead of source files.
> 
> You live in a strange different world !!!

It was humor!!!

Re: Conditional Compilation

[Samuel T. Harris]

Jeffrey Carter wrote:
> 
> Kenneth Kueny wrote:
> >
> > Does ADA have an analog to the C language #define, #ifdef constructs
> > commonly used to include or exclude certain blocks of code in different code
> > versions?
> 
> Yes. We write package specifications and have different implementations
> (bodies) for different versions.
> 

Could we please get a more informative answer.
The above does NOT address the question and does
NOT cover the problem space inferred by the questioner!

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Conditional Compilation

[Richard Riehle]

Kenneth Kueny wrote:

> Does ADA have an analog to the C language #define, #ifdef constructs
> commonly used to include or exclude certain blocks of code in different code
> versions?

That is not as stupid a question as some habitues of this forum might assume.  I
recall
a project in the late 1980's where the Ada 83 code was targeted to an embedded
processor.  The compiler for the intended deployment was priced very high "per
seat."    This was a non-DoD project with a requirement for a lot of programmers

and there was a need to stay within a reasonable budget.

The development manager bought a lot of copies of the Meridian compiler for the
programmers and let each have a copy for his/her home computer, and installed it

on MS-DOS based computers all over the lab.  Then, one of the programmers wrote
a little preprocessor program to detect the difference between code for the
Meridian
compiler and the expensive embedded  system  compiler. This was done with a
commenting scheme in which the double hyphen, followed by some identifiers could

tell the difference between the two compilation environments.

The preprocessor would simply remove comments as appropriate for whichever
compiler was
being used.   There was code in the Meridian version to emulate the features
required by the
embedded compiler.   Programmers were encouraged to write vanilla-flavored Ada
as much
as possible to avoid the issues related to the embedded compiler.   As is
typical of such
development, much of the platform-dependent code was pushed to a low level of
abstraction.

One result was that the programmers, encouraged to use Ada for more than just
their daily work,
were willing to experiment with it on their own time.  More important, the
developer did not have
to buy as many copies of the expensive compiler, thereby reducing their overall
costs.    The downside
was that the publisher of the embedded compiler  experienced financial
difficulties and is
no longer able to supply Ada compilers for newer products manufactured by this
organization.

As far as I know, the manufacturer continues to quietly use Ada for its embedded
non-Dod
software products, but now provides GNAT instead of Meridian.  Rational dropped
the idea
of updating Meridian to Ada 95 and missed an opportunity to provide a low-cost
commercial
Ada 95 compiler that could compete with GNAT.

Preprocessors, such as the one just described, may  not be in the best economic
interest
of the embedded compiler publishers since those publishers end up selling fewer
licences.
For a commercial  manufacturer using Ada, this kind preprocessor may have the
benefit of
making the development effort a little more profitable.

Richard Riehle
richard@adaworks.com

Re: Conditional Compilation

[Bobby D. Bryant]

Robert Dewar wrote:

> For example, I heard high up people in the DoD in charge of
> information processing systems seriously claim that no one
> would do any more programming any more, we would simply
> put our "business models" into the 4GL tool and that would
> be it :-)

Yeah, heard a lot of that in the trade media 10 years ago.

Meanwhile, I worked for a PHB who complained that our reports showed
that the "pounds ordered" and "pounds shipped" last month didn't match,
so their must be a bug in our programs.  Proving once and for all that
even if 4GLs, 5GLs, 9GLs, or whatever, are eventually operable by PHBs,
they'll *still* need programmers as an interface between the Management
Zone and reality.

Bobby Bryant
Austin, Texas

Re: Conditional Compilation

[Robert Dewar]

In article <39C7FEB8.FC72A217@Raytheon.com>,
  samuel_t_harris@raytheon.com wrote:
> Could we please get a more informative answer.
> The above does NOT address the question and does
> NOT cover the problem space inferred by the questioner!

Well it does relate to the *problem* space, which is to
provide for different versions of the program for different
circumstances. It does not relate the the specific *solution*
space suggested by the questioner, which was to solve this
problem with conditional compilation. In fact many people feel
that conditional compilation is the wrong way to go about
this kind of specialization. This is of course an old and
weary discussion. It is hard to believe that anything new
can come from spinning this thread once more :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Robert Dewar]

In article <39C7C748.4A533989@netwood.net>,
  "E. Robert Tisdale" <edwin@netwood.net> wrote:
> The ANSI/ISO C/C++ standards now specify
> syntax and semantics for the C macro preprocessor
> but you can still use the C macro preprocessor
> on Ada source files as long as the translation unit
> is an acceptable Ada program.
> Try it.  It works.

Well almost, the requirement of valid C tokens causes
trouble with constructions like Integer'Val (x)!

> Now, professional programmers almost never write
> programs in Ada, C, C++ or any other standard
> computer programming language directly.
> They usually use perl, the m4 macro preprocessor,
> the sed stream editor or some combination of tools
> to write programs for them from "prototype files"
> which they maintain instead of source files.

In fact the percentage of programming done this way,
particularly in large Ada programs, is quite small, and
the applicability of such techniques is quite limited.
The "almost never" in the above paragraph is a huge
exaggeration.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Robert Dewar]

In article <39C7E700.4A47DF47@SPAMM.example.com>,
  Jeff Allen <jallen@SPAMM.example.com> wrote:
> It was humor!!!

Ah, but we really have a hard time identifying it as humour,
because you can easily find this type of viewpoint expressed
seriously.

For example, I heard high up people in the DoD in charge of
information processing systems seriously claim that no one
would do any more programming any more, we would simply
put our "business models" into the 4GL tool and that would
be it :-)

Anyway, do us a favor, this is a strange field, and we cannot
conclude that just because somone is saying something ludicrous
that they intend it as a joke. So please add a smiley, otherwise
you are likely to be confused with people who really believe
some lunatic ideas :-)




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Robert Dewar]

In article <8q8mqv$aik1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> On Tue, 19 Sep 2000 20:06:32 +0000, E. Robert Tisdale
<edwin@netwood.net> wrote:
> >The C macro preprocessor wasn't originally part
> >of the C computer programming language.
>
> You sure? It was definetly a part of K&R C, and it would be
> almost impossible to build a C program without it.

The C preprocessor is most certainly part of C, and the fact
that it may be implemented as a separate program is not
relevant (except that, as noted, it may mean that in practice
it can be used for other languages).

Note that there are other possibilities, including

generalized macro processors (some of the GNAT tasking
development was originally done using the M4 processor).

specialized Ada preprocessing tools. GNAT supplies a tool
called gnatprep, and you will find that other vendors have
similar tools. In fact gnatprep is really pretty much
independent of GNAT and could be used with any Ada compiler.
(or for that matter, any C compiler :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[tmoran]

>Does ADA have an analog to the C language #define, #ifdef constructs
>commonly used to include or exclude certain blocks of code in different
>code versions?
Since most good Ada compilers will do dead code elimination, an idiom
for small include/exclude sections is:
  Debug_Version : constant boolean := True;
  ...
  if Debug_Version then ... -- stuff_for_debug_version
  else ...                  -- stuff_for_alternate_version
  end if;
Since the truth/falsity of the constant Debug_Version is known
at compile time and can't change, the compiler can include the
desired code and eliminate the undesired.
  You could make a configuration package with no body and a spec
consisting just of Debug_Version-like constant declarations if that
was appropriate.

Re: Conditional Compilation

[Robert Dewar]

In article <39C80309.F4C80A22@mail.utexas.edu>,
  "Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote:
> Robert Dewar wrote:
>
> > For example, I heard high up people in the DoD in charge of
> > information processing systems seriously claim that no one
> > would do any more programming any more, we would simply
> > put our "business models" into the 4GL tool and that would
> > be it :-)
>
> Yeah, heard a lot of that in the trade media 10 years ago.

That's precisely what surprised me, the rest of the IS world
went through this illusion a decade ago, and has long since
recognized the reality of the situation :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Robert Dewar]

In article <8qauu3$7ei$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Of course the drawback to this approach is that both
> alternatives have to be compilable. That makes it suitable for
> debug messages (as implied above), but unsuitable for making a
> source file that handles multiple
> host configurations.

Well in a way it is a big advantage that it all has to be
compilable. it is only too common to encouter a large C
file, full of conditional stuff based on say ten different
condition settings, and you just know that no one has
systematically done all 1024 compilations, and sure enough
you try a new combination, and the thing does not even compile,
let alone work.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[Robert Dewar]

In article <39CA31F2.E160F0D8@res.raytheon.com>,
  John J Cupak Jr <John_J_Cupak@res.raytheon.com> wrote:
> This is a multi-part message in MIME format.
> --------------914A2A588B0105349F9BA591
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Why not use Rational Apex for Ada, place the different code
blocks
> (or separate bodies) in different segments / views, use
import/export,
> and "builds" to create and manage various versions?


Well in fact some variation of this is the normal Ada way
of doing things, and all Ada technologies support this kind
of approach.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Conditional Compilation

[peter]

In article <39CEE3C5.42E8D8E5@telepath.com>, Ted says...
 
>A few hours of that is enough to convince anyone that
>the man who forbade macros from Ada was a genius.
>

I saw once some C code where a comment before start of a function said:

"Too large for a macro"

Later I learned that the programmer did everything in macros, and
only if they could not, resorted to functions.
 
The most fun was when seeing a macro using other macros. (some C
compiler would chock on this).

Saw one C file which had 7 different compilation modes, and overlays between
them. So complex, impossible to understand one mode from the other becuase
every other line there is an #ifdef this_mode || that_mode, so the only
way to understand the logic of each mode by itself, is to compile 
using -E flag (with one -Dmode_name) and then look at the outout of 
the pre-processor.  one mode did not compile at all, it was missing 
header files. Later I learned this mode was no longer supported (so dead code
sitting in there).

One of the things I like about java (as with Ada) is lack of macros
and pre-proccessor and everything that comes with that (i.e. the #define mess),
and lack of header files.

peter

Re: Conditional Compilation

[Ted Dennison]

Robert Dewar wrote:

> In article <8qauu3$7ei$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > Of course the drawback to this approach is that both
> > alternatives have to be compilable. That makes it suitable for
> > debug messages (as implied above), but unsuitable for making a
> > source file that handles multiple
> > host configurations.
>
> Well in a way it is a big advantage that it all has to be
> compilable. it is only too common to encouter a large C
> file, full of conditional stuff based on say ten different
> condition settings, and you just know that no one has
> systematically done all 1024 compilations, and sure enough
> you try a new combination, and the thing does not even compile,
> let alone work.

Ohhh yeah. I wasted a weekend once trying to get Wolfpack's Empire to
compile on my NT box using gcc. It has a whole mess of conditional
compilation code which assumes Windows means VC++ is being used. That
combined with the macros that detect gcc and pull in other stuff just
wreaked holy hell. A few hours of that is enough to convince anyone that
the man who forbade macros from Ada was a genius.

Of course it was no picnic getting it to work with the newer version of
VC++ I had either. But that's another C gripe for another time.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Conditional Compilation

[John McCabe]

"E. Robert Tisdale" <edwin@netwood.net> wrote:


>Now, professional programmers almost never write
>programs in Ada, C, C++ or any other standard
>computer programming language directly.
>They usually use perl, the m4 macro preprocessor,
>the sed stream editor or some combination of tools
>to write programs for them from "prototype files"
>which they maintain instead of source files.

That's news to me. If only I'd known that as a professional programmer
these last 13 years I could have saved myself some time!


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Conditional Compilation

[Andrew Hately]

Kenneth Kueny wrote:
> 
> Does ADA have an analog to the C language #define, #ifdef constructs
> commonly used to include or exclude certain blocks of code in different code
> versions?

No it does not and for good reasons.

But if you really need one - and we found we did - look at
http://users.swing.be/imw

Use with care, however. 

For a complete explanation of what we were doing, come along to
Ada-Europe'2001 in May. About 14:30 on Thursday, all should be made
clear.

Andrew Hately
Eurocontrol

Re: Conditional Compilation

[Robert Dewar]

In article <3A51D729.CB9362C5@cfmu.eurocontrol.be>,
  andrew.hately@eurocontrol.be wrote:
> Kenneth Kueny wrote:
> >
> > Does ADA have an analog to the C language #define, #ifdef
constructs
> > commonly used to include or exclude certain blocks of code
in different code
> > versions?
>
> No it does not and for good reasons.

Most Ada systems will include a preprocessor, for example,
see gnatprep supplied with GNAT (whose design is copied
from widely used Ada 83 tools).


Sent via Deja.com
http://www.deja.com/