Re: Porting (was ADA and Pascal etc)

[seebs@plethora.net (Peter Seebach)]

In article <345BB0F9.1B7F@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@dynamite.com.au> 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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!