Re: Porting (was ADA and Pascal etc)

[Alan E & Carmel J Brain <aebrain@dynamite.com.au>]

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