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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-28 04:40:03 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stueberl.de!newsr1.ipcore.viaginterkom.de!btnet-peer1!btnet-feed3!btnet!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: 28 Jan 2004 13:27:51 +0100 Organization: Sun Microsystems Message-ID: References: <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <_JSdna166JuxFo3dRVn-hg@comcast.com> <401115B7.5020205@noplace.com> NNTP-Posting-Host: europa1.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1075292872 20911 129.159.113.161 (28 Jan 2004 12:27:52 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 28 Jan 2004 12:27:52 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:4992 Date: 2004-01-28T12:27:52+00:00 List-Id: "Warren W. Gay VE3WWG" writes: > Ole-Hjalmar Kristensen wrote: > > >>>>>>"JC" == Jeffrey Carter writes: > > JC> Warren W. Gay VE3WWG wrote: > > >> Jeffrey Carter wrote: > > >>> One standard POSIX-Ada binding > > >> Impossible. Some UNIces provide some API structure members, > > >> while others don't, or provide something else again. Yes, > > >> you can dumb it down to a "standard" (or omit non-universal > > >> functionality), but by doing so you throw away functionality. > > >> I find that unacceptable. > > JC> There is a standard POSIX-Ada binding (Florist is an implementation of > > JC> this standard) to the POSIX standard. If you want something not in > > JC> this standard, obviously you're going to have to provide it yourself > > JC> on some platforms. If you're on a platform that doesn't provide some > > JC> of the functionality, then it's not a POSIX system. In neither case > > JC> are you dealing with different versions of POSIX. > > Which does not matter if what you are doing is maintaining a program > > which is running on multiple platforms and is compiled with multiple > > compilers. The program has to run even if the platform does not > > support a standard package like Florist. How many platforms is Florist > > really available on, btw.? > > Listen, C programmers do this thing every day. "If some feature > is available, then do it this way, else do 'it' in a more > inferior way". > For the past 20 years, I think about 90% of the code I have been writing is C or C++, so please cool down... I think you may have misread my answer. The sentence "Which does not matter if what you are doing is maintaining..." is answer to "There is a standard POSIX-Ada binding...". To re-state my position: It does not matter that there is a standard POSIX-Ada binding if I am maintaining a program on a platform where this standard POSIX binding does not exist. I still have to get my system working, somehow. The problem does not go away because of this standard binding. > Just because you write to "any platform", doesn't mean you > have to dumb down the code for all platforms. If one O/S gives > me an efficient way to do something, and I care to take > advantage of this, then I can do just that with conditional > compilation. > > By saying that an Ada program would never do that, has again > condemned it to be inferior in some cases (which, IMO, > is an entirely unnecessary limitation). > > > What matters is how do I do this while keeping the code readable and > > maintainable. > > Of course! I could argue that conditional compilation may > make it clearer where I'd run into portability problems > on some platforms, because the different offending code > is right in front of me (vs sitting somewhere else, > unexplored). > I never said conditional compilation was bad. > > One way to combat the combinatorial explosion of platforms * compiler > > * library is to explicitly test for the features of the environment > > you really need to know, not assume something because of a particular > > platform/compiler. This is the approach typically used by projects > > using the 'configure' tool. > > Yes, and that ./configure tool generates files that drive > a conditional compile process. But no amount of Ada if > statements can help you with conditionally with-ing certain > packages, and conditional code that have to distinguish > between the code that must work around differences and > limitations, and deal with optional members of records etc. > I agree. My point was simply that there is an alternative to test for compiler/platform. > But this horse has been beaten to death already in this > thread, and I see no reason to expand upon it again. > > > I would really like to have some standard configuration tool which > > could take such parameters as input and produce a version of the > > system tailored to the environment in which it is to be compiled and > > run. > > This is just a high level statement of what has already > been discussed. So how are you going to _implement_ this? > > 1. Preprocessing? > 2. Conditional compilation? > 3. Generate source code? > > The problem with #3 (which is what you seem to be suggesting) > is that when there is a compile time problem, or a maintenance > issue, you end up wanting to work with the generated files. BUT, > you know you have to remember to work with the original INPUT > files, that were used to generate it. #3 actually describes > the gnatprep case, and there are options to make it easier > to work this way (eg. an option that relates the line # > back to the one in the original input file). But every once > in a while, I end up modifying the wrong file by accident. > I hate this. Conditional compilation would be a better > solution for the developer because it is less error prone, > and it is more natural. > > -- > Warren W. Gay VE3WWG > http://ve3wwg.tk > It's been a while since I worked actively with CM systems, but basically the idea is that you select the variant you want to work on, make your changes, and then commit your changes to the system to integrate them with the other variants. Yes, you easily get into problems when wanting to work with generated files. (Unless the compiler is integrated with the CM system in such a way that the output of the compiler is related to the original file, and you do not see the intermediate file at all). What you do with a conditional compilation system is to code the exact same information as the CM system needs to keep internally into the source code. As you point out, sometimes it may not be desirable to hide this information, other times it may be for the sake of easily seeing the variant you are working on. Please observe that I am not arguing against conditional compilation. Given the state of the art, it may well be the best solution in a number of circumstances. -- C++: The power, elegance and simplicity of a hand grenade.