delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/11/14/23:32:00

Message-ID: <20021115043144.31342.qmail@web13005.mail.yahoo.com>
Date: Thu, 14 Nov 2002 20:31:44 -0800 (PST)
From: Thomas Tutone <thomas8675309 AT yahoo DOT com>
Subject: Re: Re: whats wrong with my compiler
To: djgpp AT delorie DOT com
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

"JMK" <jeffrey DOT m DOT klopotic AT lmco DOT nospam DOT com> wrote in
message news:<3DD44568 DOT 141AB4FA AT lmco DOT nospam DOT com>...
> 
> Thomas,
> 
> The doctrine of backward compatiblity dictates that
> any compiler 
> written for a language be able to compile any 
> previous code without 
> modification, proprietary extensions excepted.  

Jeff, I feel your pain.  Unfortunately, the C++
standards committee adopted the standard in 1997, and
you and I both have to live with it.  

> Thus, a simple "Hello 
> World" type source must be recompilable on any 
> version of compiler 
> design.  

Well, you're starting from a flawed premise.  The
original "Hello, world" program in C that appeared in
the 1978 edition of Kernighan & Ritchie's "The C
Programming Language" will not compile on most modern
C compilers, unless you set various compile options
that indicate you are using "archaic" C.  When
Kernighan & Ritchie issued their second edition in
1988, they updated it to reflect the ANSI standard for
C, and they updated the "Hello, World" program as part
of that update.

Bjarne Stroustrup did exactly the same thing.  When he
wrote the Third Edition of "The C++ Programming
Language" in 1997, he updated it to conform to the
ANSI standard (which he played an enormous role in
drafting).  He, like Kernighan and Ritchie before him,
updated his "Hello, World" program.  I have in front
of me my copy of Stroustrup's "The C++ Programming
Language", 3rd Edition, Second Printing, August 1997. 
In Section 3.2, on page 46, Stroustrup provides the
"Hello, World" program.  Here it is in full:
	
#include <iostream>
int main()
{
	std::cout << "Hello, world!\n";
}

Note the use of "<iostream>" and "std::cout".  The
very next section, 3.3, entitled "The Standard Library
Namespace," explains why the "std::" part is required.

> The presumption here is that we're talking 
> C++ and that gcc 
> intends to be C++.  

We are talking about C++, and gcc does indeed intend
to be C++.  And, in fact, gcc 3.2 is one of the best
C++ compilers currently available.  It is closer to
conforming to the standard than either Microsoft's or
Borland's current versions.  And it generates
optimized code that is generally as fast or faster
than those two commercial versions.  And DJGPP is an
outstanding port of gcc to DOS.  And it's all free. 
Amazing, really.  Thanks, DJ and all the other
developers.

> Further, it should be 
> recompilable whether written 
> in C or C++.
> If you what you assert is true, that one must now 
> rewrite something as 
> simple as "Hello World" to meet new standards, my 
> prediction is that 
> this oversight will be corrected once the economy 
> gets going again.  

Well, as I said, the rewrite of "Hello, World" in C
occurred in 1988, and the rewrite of "Hello, World" in
C++ occurred in 1997.  I don't think the economy has a
whole lot to do with it.

> All those companies out there with legacy code that 
> won't recompile 
> are going to be quite besides themselves once they 
> find out just what 
> happened.  

You and I can certainly agree that being able to
compile legacy code is important.  That's why gcc and
most other C++ compilers have switches that permit
legacy code to compile.  But gcc, and most other
compilers, generate warnings when you do that to tell
you that the code does not comform to modern C++
language requirements.  And just because gcc CAN
compile legacy code, it does not mean that you or I
should be encouraging beginners to program that way -
i.e., in an archaic form of C++ that does not conform
to the standard.

> Either that, or C++ will be renamed D or 
> whatever the next 
> generation will be called -- which is probably more 
> appropriate.
> 
> In the meantime, you might want to advise to see if 
> changing iostream 
> to iostream.h works.  If it does, a lot more people 
> would be greatful 
> if you pointed out the historical change that 
> occurred.  It will save 
> a lot of learning programmers a great deal of grief 
> when realizing 
> that it is a system fault and not theirs.
> 

I agree with the point you make - that this trap has
caused misery for newbies everywhere, and that this is
unfortunate.  But I think the advice you would give is
wrong.  Using <iostream.h> is a really bad idea.  Let
me explain why.  On many platforms, you can't mix
standard headers (like <iostream>) with legacy headers
(like <iostream.h>, even if those legacy headers still
exist.  Think about what that means.  On such
platforms, if you use <iostream.h>, you can't use
<vector>, or <algorithm>, or <memory>, or other
components of the modern C++ Standard Library without
getting compile errors.  You're stuck using the
pre-standard versions, if they exist.  In other words,
it leads to many, many additional compile errors, and
a lot more confusion.  That means that programmers who
get in the habit of using <iostream.h>, as you
advocate, will have endless problems once they advance
beyond "Hello World" programs.  Better that they
should learn the correct usage in the first place. 
That was why I encouraged the original poster to get a
copy of Koenig (also heavily involved in drafting the
standard) and Moo's "Accelerated C++."  It teaches the
proper habits from the start.  So does Stroustrup's
book, but it's pretty hard for beginners to follow.

My apologies to the mailing list for my off-topic
rant. But it bums me out when I see people making this
mistake, and even more so when I see other members of
the list encouraging them to do so.

Best regards,
	
Tom

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019