From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd63afa4dc364b7e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-26 11:48:06 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Implementing C/C++ style #include... Date: Mon, 26 Mar 2001 14:35:25 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <99o5m6$6of$1@nh.pace.co.uk> References: <98m938$2iod0$1@ID-25716.news.dfncis.de> <99alrr$itf$1@nh.pace.co.uk> <99d5dj$fi4$1@nh.pace.co.uk> <99nkte$157$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 985635334 6927 136.170.200.133 (26 Mar 2001 19:35:34 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 26 Mar 2001 19:35:34 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:6071 Date: 2001-03-26T19:35:34+00:00 List-Id: 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" wrote in message news:u7l1cgzpa.fsf@gsfc.nasa.gov... > "Marin David Condic" 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