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,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public From: seebs@plethora.net (Peter Seebach) Subject: Re: Porting (was ADA and Pascal etc) Date: 1997/11/01 Message-ID: <63e9p0$99h$5@darla.visi.com> X-Deja-AN: 286326528 References: <34557f2b.1934172@news.mindspring.com> <345AB871.413A@dynamite.com.au> <63d3sm$ap7$3@darla.visi.com> <345BB0F9.1B7F@dynamite.com.au> X-Complaints-To: news@visi.com X-Trace: darla.visi.com 878357088 9521 205.166.146.1 (1 Nov 1997 04:04:48 GMT) Organization: Plethora Internet Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-01T00:00:00+00:00 List-Id: In article <345BB0F9.1B7F@dynamite.com.au>, Alan E & Carmel J Brain wrote: >Mind? Nah! For one thing, your post was educational and helpful. >> >void Main() >Correct! Why do you assume that > int main() >had anything whatsoever to do with > void Main() Because, in C89, the implementation is *allowed* to be case-insensitive, on externally visible symbols, so you *may have been* declaring the one true main(), and doing so incorrectly! >Sorry, I wanted to make a point here, and laid a dastardly trap. Lucky for me that C89 supported a brain-dead linker. :) >> Your problem here is that C++ is random. >WORDS WORTHY OF ENGRAVEMENT IN LETTERS OF GOLD ON JADE! >I program in Ada-83. I program in Ada-95.I program in C. I program in >C++. Not just privately, or academically, but on systems that really do >things. Cool! At some point, I should look you up and ask you questions about Ada. >If having 2 loops in the same procedure, using the recommended way of >doing things (localisation of indices) is "pushing the envelope", then >maybe the envelope is a little too constraining. This is why I use C, not C++. >How does one tell when >one is venturing into "Here Be Dragons" territory? As far as I can tell, >not even setting the switch for strict ANSI C compliance will save you >in every case, just the vast majority of them. Can you tell me a good "rule >of thumb" to use for finding out which C++ statements are "safe" and >which are "dangerous"? This is *soooo* tempting... :) Basically, no, I can't. I can tell you that the example was (modulo main issues) supposedly conforming draft-standard ANSI C++, and that (once again, modulo main issues) it will be C9X. But I can't tell you how to guess when a compiler will get in the same decade with you. >> Pray tell, what would you have said to someone having similar problems >> with "Ada 95" compilers in 1992 or 1993? >The fact that all of these inconsistencies were >cleared up by 1987 is not well known. The Ada-83 LRM >straight-out-of-the-box was far more useful as a guide to expected >behaviour than even the ISO C standard, which abounds with unclear >statements that require "sensible interpretation" (like the original >Ada-83 delay statement). Yeah, but it's getting a lot better. :) >Summary: If the ISO C standard is more unclear after 20 years than the >Ada-83 standard was after 20 days, what can we expect from the C++ >standard? I would take issue with an assertion that ISO C was unclear after 20 years. ISO C didn't start until around 1984, as I recall, so they had five years, and further, they had a lot of existing practice to account for... They couldn't just sit down and describe what *ought* to be. I am fairly confident that C9X will be a significant improvement over C89 - serious effort is going on to make sure that potential confusions are eliminated. >I respectfully submit, "more of the same" with no end in >sight. Will C++ have a standard by the turn of the century? My guess is >Yes, but I'd reckon the odds are about even. I'd say "most likely". Last I heard, they're on a schedule that may well complete before C9X, so they'd *better* be done this century... >Will the standard prevent >all the problems? Not a hope. The best we can hope for is a reduction of >inconsistencies to the level of ANSI C, in about 20 years.( A level >which Ada-95 has already achieved, after 2 years, but that's irrelevant) Ada has an advantage similar to that enjoyed by perl - the language was developed under controllable circumstances. C was mildly crippled by the vast amounts of existing code which couldn't be broken. C++ is *much* more badly hurt by this. I don't think ISO C really has many inconsistencies left, even afer only 7 years. (C89 is really C90...) There are some confusions, but you can write a lot of code with a lot of confidence now. >> Drop by my web page; all of my non-POSIX-dependant C is expected to compile >> and run correctly on all C compilers. All of them. No exceptions. I >> consider any failure to do this a bug, and will happily fix it. >> Yes, I really mean it. >I like your attitude, Sir, a man after my own heart! Yes, I will drop by >your web page. My thanks for bringing it to my attention, I'm sure I'll >learn a lot from it. Cool! I always like getting feedback on my code, it's helped a lot. Sadly, I had some 8-bit char dependancies in my string library a while back, but I believe they're all fixed. :) (Actually, it also has a logic bug in the allocation rules, that seems to be "mostly harmless", but which really implies that it's time to move my -current code out as a release.) -s -- seebs@plethora.net -- Speaking for myself. No spam please. Copyright 1997. All rights reserved. This was not written by my cat. C/Unix wizard - send mail for help! -- - More Net, Less Spam!