On Thu, Feb 19, 2004 at 09:42:26PM -0500, Mike M wrote: > On Thu, Feb 19, 2004 at 05:16:53PM -0600, Alan Shutko wrote: > > Mike M <[EMAIL PROTECTED]> writes: > > > > > C++ seems to be steaming away in this direction. I've got my doubts > > > that the .h is going away in C however. > > > > As far as I know, nobody has proposed that the C header files change > > in this way. > > I was unaware too until someone in this thread posted that stdlib.h is out > and cstdlib is in. > > > > > It seems that this is going to cause more portability problems than > > > it solves. Code written for advanced compilers will be incompatible > > > with older compilers. > > > > This has been a problem of C++ for at least a decade. But at least > > it looks like it's finally getting better now that the standard is > > standardized and compilers catch up. > > A decade of C++ becomes deprecated? How can this be? I > argue that it cannot from a practical point of view. The body of > existing work is too large to allow drastic change.
I think you missed the point. The header names changed explicitly to
*support* backward compatibility. The Standard says that the standard
library belongs in the std:: namespace. This decision was made for a lot
of good reasons. However, most vendors were already shipping iostream.h,
that did not put iostream into the std namespace.
So, the standard writers had two choices: force vendors to change their
iostream.h so that it puts everything into the std namespace -- and
break millions of lines of legacy code, or ask vendors to provide a
different header for std::iostream. The standards committee chose to use
a different header, expressly to *preserve* backward compatibility with
existing code.
> On the one hand we have a standards committee and eager-to-please
> compiler maintainers creating features and requiring us to change
> existing code to adapt to the new features.
Languages change, and compilers change along with them. How many ifdefs
do you see today in C code in order to support K&R vs. ANSI? Not too
many, because programmers and programs catch up to standards. All you
need to do is trace the history of much of the GNU code to see how their
function definitions evolved from pure K&R to a macro hack that did K&R
or ANSI depending on the compiler to today, where most GNU code uses
ANSI only.
That doesn't mean that legacy K&R code won't compile with a modern C
compiler. It means that programmers no longer feel that they need to
refrain from using ANSI constructs because they're worried that some
compilers won't support it.
Or do you still live in fear of encountering a K&R compiler, so you continue
to declare your functions like:
int foo(a,b)
int a;
char b;
{
}
> I am not opposed to new features in C++ as long as they are not mandatory.
> If the new features are mandatory, then rename the language to C+++ so
> there'll be no confusion.
Languages change. C went from K&R to ANSI to C89 to C99. C++ is evolving
in the same way.
> Back to the case in point - header files. Why the change? To support
> the namespace feature? A project as well-known as Mozilla says to not
> use namespace because it's not portable.
The mozilla project started 6 years ago, possibly even before the
standard was even ratified and certainly at a time when many mainstream
C++ compilers did not support namespaces well. Things have
changed. Today, there's no way that the mozilla folks would be against
namespaces; all mainstream C++ compilers support them very well. Today,
they would be telling you to avoid things like partial template
specialization, because it's not well-supported yet. And 5 years from
now, they will probably be telling you to avoid the export keyword
because it's not well supported (yet!).
> I've worked in telecom for many years and from that I know that when a
> system becomes very large, you can no longer change the standards on
> which it is based. The costs are too great. The new must adapt to the
> old.
Nobody is saying you have to change. What they're saying is that if you
#include <iostream.h>, you're NOT getting std::iostream, and you can't
complain if whatever iostream you do happen to get doesn't conform to
the C++ standard. If you want std::iostream, then you need to #include
<iostream>.
Under GCC, you're probably going to get behavior nearly identical to
std::iostream even if you #include <iostream.h>. But you might be in
for a nasty shock if you try to compile your code with Visual C++ or
Comeau C++ or some other C++, because their iostream.h (if it even
exists) may or may not behave like your iostream.h.
Conversely, their <iostream> *will* behave like yours, or else one of
the vendors has a bug with their implementation. Bugs like this are
still a common and sad fact, but the situation would be much worse if
none of your vendors followed a standard at all.
--
Dave Carrigan
Seattle, WA, USA
[EMAIL PROTECTED] | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL
signature.asc
Description: Digital signature
