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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public From: Alan E & Carmel J Brain Subject: Re: Porting (was ADA and Pascal etc) Date: 1997/11/01 Message-ID: <345BB0F9.1B7F@dynamite.com.au> X-Deja-AN: 286323815 References: <34557f2b.1934172@news.mindspring.com> <63bhta$g2e@bgtnsc03.worldnet.att.net> <345AB871.413A@dynamite.com.au> <63d3sm$ap7$3@darla.visi.com> Organization: @home Reply-To: aebrain@dynamite.com.au Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-01T00:00:00+00:00 List-Id: Peter Seebach wrote: > If you don't mind us making fun of you. You posted an incorrect > C++ example without including comp.lang.c++. Mind? Nah! For one thing, your post was educational and helpful. > >Code Warrior accepts > > >void Main() > > Does it? Traditionally, C has used a lower case M on main, and > I seem to recall that the Mac implementations were case sensitive. > C++ likewise. > Further, if it accepts it at all, it does so out of bemused > tolerance for your misguided efforts, in both C and C++, main > is a function returning int, not void. Correct! Why do you assume that int main() had anything whatsoever to do with void Main() Sorry, I wanted to make a point here, and laid a dastardly trap. > Well, this is certainly C++; C doesn't let you declare things in the > first expression of a for, and uses /*...*/ for comments. ...but only if the switch for strict ASCII is on, otherwise YMMV. Eg HP C. > 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. IMHO there _is_ a significant difference. There has been vastly more heat than light generated in "the great language debate", and the general conclusion is that it's a matter of religion, with no real reason to prefer one language to another. Yet all the studies that have been done indicate otherwise. This has led to the phenomenon of (sometimes quite valid) attacks on the limitations of the studies. While ignoring the results. > As C, it's trash in more ways than I can conveniently enumerate. As > C++, it's trash because: > You misspelled and misdeclared main > You depended on a not-standardized feature > This is stupid. When you are working with a pre-standardized language, > with implementations which may be tracking the standard to different > degrees, you *NEVER* push the envelope. 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. 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"? > Ahh. So, what you're saying is that C++ is not yet standardized, and > you can't be sure where in the process a compiler is. True, exactly my point. > Pray tell, what would you have said to someone having similar problems > with "Ada 95" compilers in 1992 or 1993? There weren't any (compilers, that is). That's the whole point. Ada 9X compilers existed, but not for production use, as they weren't completely stable. Much like C++ will be in a few years. A better example for you to choose would be Ada-83 compilers in 1984-85. For then there were different interpretations (not quite as bad as the example for C++) of the standard that were unclarified. One that comes to mind is the Ada-83 "delay" statement. This was in the Language Reference Manual as, basically "Delay 5.0 means delay at least 5 seconds, but with no guarentee that it will be exactly 5.0 seconds as other more high priority concurrent processes may pre-empt you". Later on, a codicil was added "but it should be about 5.0 seconds, a delay for an infinite time is not sensible" as one compiler of my acquaintance treated "delay 5.0" as "delay forever, even if you're the only process". Which was within the letter, but not the spirit, of the LRM. Such rubbish (there wasn't much of it) gave Ada a bad name, that it still hasn't lived down. 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). 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 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. 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) > 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. > I do know of systems that won't run the code correctly; none of them make > even a convincing claim of being C89 compilers. > > >Try having a go at the lovelace Ada tutorial at http://www.adahome.com . > >You may hate it, of course. But it also may give you insights into how > >to code C and C++ better. IMHO it's worth a look for any C programmer > >anyway, just as all Ada programmers should be exposed to C { if only to > >beef up their resistance :) } > > I probably will. Learning multiple natural languages makes you more > literate, fluent, and expressive in your native tongue, and I believe > the same goes for programming languages. Familiarity with other idioms > can help you see a way around a sticky problem. Agree completely. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale