Topic: iostreams changes
Author: Steve Clamage <stephen.clamage_nospam@eng.sun.com>
Date: 1997/09/15 Raw View
Joe Buck wrote:
> ...
>
> It's too late now, but arrays could have been fixed at the cost of
> breaking a few C programs, and fixing the programs would have been
> no worse than fixing the old C++ programs.
>
> "Fixed" means that arrays would become first-class types that can be
> assigned, that arrays pass by reference, that instead of saying an array
> name is the same as a pointer to its first element you say that there is a
> conversion that does this, etc.
Very early in the C++ standardization process, Doug Lea presentd
a very nice proposal to "fix" arrays in C++, making them
first-class data types. The only thing wrong is that fixing
arrays breaks nearly every C++ program in a non-trivial way.
I doubt you can find real-world C++ programs that do not depend
on the near-equivalence of pointers and arrays. Siginificant
amounts of code would need to be re-written.
But C++ provides a mechanism to get arrays as first-class
types: classes. The standard library even provides several
different kinds of templatized array types that provide
different sorts of useful semantics. IMHO, there is much
LESS need now to break code by fixing C-style arrays in C++
than when Doug presented his proposal. If you want an array
with nice properties, use vector or valarray, or roll your own.
Legacy code will continue to work unchanged.
> I am not proposing that it be done now, but I think that had the committee
> realized in the early days that what they would wind up with would force
> users to change every C++ program, they would have been more ready to
> break some aspects of C compatibility (in a way that "well-behaved" C
> code would continue to work).
I think you are overstating the case regarding how badly the
draft standard breaks programs. The most major change is
introducing namespaces. If you add one line of code to your
project header file ("using namespace std;") you can solve
that issue. IMHO that at least two orders of magnitude less
serious than promoting arrays to first-class data types.
For a given program, changing to a standard-conforming compiler
will result in other breakage. I think nearly everything
that breaks will be in code which could not be ported unchanged
to many other compilers anyway. If code isn't portable, I don't
think it makes a lot of sense to talk about the standard
causing it to become broken.
As I noted in an earlier article, there are changes to iostreams
which will break some programs. Given the inadequacy of classic
iostreams regarding I18N, that couldn't be helped.
--
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: jbuck@synopsys.com (Joe Buck)
Date: 1997/09/12 Raw View
I made a silly error that I wouldn't want anyone to attribute to Al
Stevens (since I discussed his article): the suggested compatibility
solution is not to write "using namespace std; #include <iostream>" in
iostream.h, but rather, as Steve Clamage suggests, to import only the
<iostream> names into the global namespace. I apologize for any confusion
caused.
My point was not so much to attack the committee for breaking old C++
programs, but rather for working so hard to keep ANSI C programs working.
That is the principal inconsistency.
It's too late now, but arrays could have been fixed at the cost of
breaking a few C programs, and fixing the programs would have been
no worse than fixing the old C++ programs.
"Fixed" means that arrays would become first-class types that can be
assigned, that arrays pass by reference, that instead of saying an array
name is the same as a pointer to its first element you say that there is a
conversion that does this, etc.
I am not proposing that it be done now, but I think that had the committee
realized in the early days that what they would wind up with would force
users to change every C++ program, they would have been more ready to
break some aspects of C compatibility (in a way that "well-behaved" C
code would continue to work).
--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html
If you thought flashing ads on Web sites were annoying, wait till the Web
and your operating system are "seamlessly integrated" and watch the
pulsating promotional crud spill out over your desktop. -- Scott Rosenburg
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]