Re: Why do we have to define a namespace with string header?
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:bvm8g.85172$dW3.71134@newssvr21.news.prodigy.com...
P.J. Plauger wrote:
The general set of keywords for C++ were invented in the 1980s.
And many more were added during "standardization" in the 1990s.
And *lots* more library names (which are not keywords) were added
as well.
The point was the time delay between establishing enough of the core
language to write programs, and establishing a stable library.
Sorry, but there was considerable overlap between evolving the language
and using the new features in the library. There are even cases where
the library required a language feature *before* it was settled by
the core language subcommittee.
The Standard Library - the most common and most useful things to do
/with/ those keywords - was ratified in 1997.
This was a good thing because the library had time to mature.
Some of it. And parts of it were paper tigers that were standardized
before they were ever implemented.
I'm sure some people could have said the exact right thing in fewer words,
but I couldn't. The question was why is the standard library inside
namespace std...
Because it seemed like a good idea to some, at the time. It is worth
noting that namespaces were voted into the draft C++ Standard in mid
1993, mostly as an aid for structuring the Standard C++ library;
but it quickly became apparent that the people pushing namespaces
had no idea how to use them for that purpose. As a result, the library
subcommittee revised the use of namespaces at *every* meeting for the
next two years. And they settled on the current usage over the
vehement objections of several major compiler vendors. It is no
surprise that, to this day, only one or two vendors fully conform
to the C++ Standard in the use of library namespaces. (The Dinkumware
library can be configured to do so, but practically all of our OEMs
choose not to, for good practical reasons.)
Thuse, namespace std was yet another paper tiger, which is *still*
being debugged.
But the new language specification had to preserve over a decade of
legacy code. The language committees could not tell everyone, "some of
your functions will now disappear, some will change their behavior, and
some will break your programs now". People would simply reject Standard
C++, and keep using the "ARM C++" and its defacto standard.
But that's exactly what the C++ committee did do.
...and you are gainsaying minor details. Of course The Standard broke some
existing code, just as The C Standard broke some existing code.
Well, there's "some" and there's "some". The C Standard bent over
backwards not to break existing code. Even where it did in theory,
in practice the existing code could compile properly with standard
conforming compilers. By contrast, the C++ Standard omitted *every
single* header that had been in use by the community for over a
decade. In their place it introduced a whole new set of headers
with tantalizing similarities to the old stuff, but with pernicious
differences. Some breaks didn't even involve headers or namespace
std -- like new expressions that once returned a null pointer and
now throw an exception. Some "some"s are way bigger than other
"some"s.
So the committee fixed this in one move by putting everything in The
Standard Library into one big namespace. Legacy code that did not
declare this namespace could continue to use their legacy libraries. You
might find your C++ implementation still contains files such as
"iostream.h".
It's nice to think that the C++ committee wisely took a new departure
and made a point of staying out of the way of old library naming
practices, but this was not their goal in adding namespace std and
the new headers. It was the *vendors* who wisely retained the legacy
headers for many years.
Yet if they had not added namespace std, the Standard language would have
been much harder to adopt for billions of lines of legacy code.
I disagree, and I think the evidence supports my position. The vast
majority of new names are in headers that older code would never
have included. The "revised" headers such as <iostream> and <new>
hew closely to past practice. And if you don't want to add several
billion "std::"s to your old code, you have to use the omnibus
"using namespace std" and risk about as many ambiguities as if
the library stayed in the global namespace. Where's the savings?
So it's the
same difference, and it's an adequate way to explain the namespace std
system to a newbie.
It's *not* the same (see above), and while it's a convenient
bedtime story for the kids, it's about as real as Santa Claus.
(Worse, code can also mix-and-match legacy and standard code. The less
said about that the better.)
Maybe, but quite a lot *had* to be said about it, by those of us who had
to support customers through a decade of transition. You will *still*
see regular postings on these newsgroups along the lines of, "I included
<string>, so why isn't class string defined?"
That's not mix-and-match.
No it isn't. I should have used the example, "I've included <iostream.h>
and <string>, so why is my program failing to compile (or link)
properly?" I've seen three references to <iostream.h> in newsgroup
questions just this past week, along with about as many missing
std:: problems.
So, if you need strings or "STL" containers, import their namespace.
This is a very minor detail of well-structured code.
I agree that importing the entire std namespace is often the best way
to repair the damage, but I'm in a tiny minority.
I tried to say "import them from their namespace".
Okay, but even if you import names one at a time from namespace
std, you still run the risk of colliding with names undreamed
of fifteen years ago. Not a big savings.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com