Re: Implementing C/C++ style #include...

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Well, you bring up a lot of points here. Let me see if I can at least hit on
the overall cases.

Yes, I've seen cases where you may need to maintain code for two different
compilers. You can't sneak the one version of code past the other compiler,
so you might be tempted to use preprocessing directives to eliminate it.
(Something that is itself possibly peculiar to one compiler and won't sneak
past another compiler, eh?) Why can't you burry this in a package body that
is maintained down a separate CM path? (Your example could be hidden in a
package body, no?)

While I admit the possibility of maintaining code for two different
compilers, I think it is kind of rare. More likely, you've got code for two
different platforms wherein some resources may be variant between the
platforms. (OS calls, devices, etc.) In either case, I'd prefer to either
isolate it in a package body and maintain two bodies down two different CM
paths or I'd control it with (static or dynamic) "if" checking that I would
change from a configuration package spec. I'd personally prefer these
choices to using a preprocessor.

As for being "open" - I think it was G. K. Chesterton who said "Having an
open mind is nothing. The object of opening the mind, as of opening the
mouth, is to shut it again on something solid." :-) Seriously, I've used
preprocessors (and still do by way of C/C++) and just remain unconvinced
that you can't get there by other means with fewer pitfalls.

Given the experience I have had, I just don't see it as being in the same
category as "Unchecked_Conversion" and I don't feel the need for that sort
of "expressive power". Some people may like a preprocessor and that's fine
by me. I personally would advise against it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u7l1cgzpa.fsf@gsfc.nasa.gov...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > I guess I've just seen it done enough different ways that work as well
or
> > better that I don't really see any necessity for a preprocessor to do
this
> > job. Managing different configurations can be handled with package body
> > substitution, static elimination of code via normal "if" statements,
pragma
> > Debug, available configuration management tools, etc.
>
> Not this one:
>
>    function Ada_Size_Of_Input is new
>       Interfaces_C_More.Storage_Unit_Size_Of (Input_Type);
> #if GNAT_Compiler
>    pragma Export (C, Ada_Size_Of_Input,
>                   "ball_ct633_ada_size_of_input",
>                   "ball_ct633_ada_size_of_input");
> #elsif ObjectAda_Compiler
>    pragma Export (DLL_STDCALL, Ada_Size_Of_Input,
>                   "ball_ct633_ada_size_of_input",
>                   "ball_ct633_ada_size_of_input");
> #end if;
>
> The difference is in the name of the Convention. Preprocessing is, in
> this case, the best way to handle it. I believe the only alternative
> is to reproduce the entire package spec, and change this one value.
> Surely you do not claim that is better from a maintenance point of
> view?
>
> I can only assume you have not personally encountered a situation like
> this. Until you have, you need to be a little more open :).
>
> There are similar examples of needing to support a mix of Ada 83/95,
> compiler vendors, and targets, where limited, structured,
> well-designed use of pre-processing is the best way to go.
>
> > As a result, I think that trying to include special pre-processor
> > directives in the source and going through an extra pre-compilation
> > step (fraught with peril!) is unnecessary and potentially dangerous.
>
> "potentially dangerous" yes, just like Unchecked_Conversion and
> Unchecked_Deallocation. "unecessary" no, just like
> Unchecked_Conversion and Unchecked_Deallocation!
>
> >
> > (Try looking at some older C code that may have very convoluted
> > "#include" chains, etc. if you need an example of how dangerous this
> > can get.) I've never once seen a case where you could accomplish
> > some goal with a preprocessor that you couldn't accomplish with a
> > less error prone technique.
>
> Have you seen the above case?
>
> > So why ask for the trouble?
>
> I'm not asking for "trouble", I'm asking for "expressive power".
> "Trouble" I can handle with coding guidelines and project discipline.
>
> Note that the gnat preprocessor does _not_ define "include", only
> "if". And it does _not_ define macros.
>
> --
> -- Stephe