Why do we have to define a namespace with string header?

Discussion in 'C++' started by bgeneto, May 10, 2006.

  1. bgeneto

    bgeneto Guest

    I know that it's a very basic question, but I can't figure out or find
    an answer to why do we have to specify a namespace, like this

    #include<string>
    using namespace std;

    when using the standard string library? Is this really necessary, why?
    Thanks,

    Bernhard Enders.
     
    bgeneto, May 10, 2006
    #1
    1. Advertising

  2. bgeneto

    Ian Collins Guest

    bgeneto wrote:
    > I know that it's a very basic question, but I can't figure out or find
    > an answer to why do we have to specify a namespace, like this
    >
    > #include<string>
    > using namespace std;
    >
    > when using the standard string library? Is this really necessary, why?
    > Thanks,
    >

    Because the standard library functions are declared in the namespace std.

    You have to fully qualify something declared in a namespace, otherwise
    the compiler won't find the symbol.

    I'd avoid the blanket 'using namespace' directive and either use fully
    qualified names (line std::cout) or use specific using directives for
    the items you want to use from the namespace (using std::cout; for
    example).

    --
    Ian Collins.
     
    Ian Collins, May 10, 2006
    #2
    1. Advertising

  3. bgeneto

    Alan Johnson Guest

    bgeneto wrote:
    > I know that it's a very basic question, but I can't figure out or find
    > an answer to why do we have to specify a namespace, like this
    >
    > #include<string>
    > using namespace std;
    >
    > when using the standard string library? Is this really necessary, why?
    > Thanks,
    >
    > Bernhard Enders.
    >


    When creating a library, it is generally a good idea to put any symbols
    you define in their own namespace. Doing so severely decreases the
    chances that names that you use will conflict with names in the library
    you write conflicting with names in others' libraries. You might say
    the designers of the C++ Standard Library were just following good style
    and setting a good example by putting all their symbols in namespace
    std.

    --
    Alan Johnson
     
    Alan Johnson, May 10, 2006
    #3
  4. bgeneto

    bgeneto Guest

    Thanks for your explanation, if I understand well the string class and
    possibly it's methods are defined in the namespace std within the
    standard header <string>. If so, what is the point in doing this? Is it
    any better compared to the old school? std sounds like a scope to me,
    but what do we have defined without the scope std? No class, no
    methods, nothing?
    About your 'suggestion' to use full qualified names, I figure that I
    must also use std::string in addition to std::cout, std::cin, etc... a
    little cumbersome, no?

    Thanks one more time,

    Bernhard Enders.
     
    bgeneto, May 10, 2006
    #4
  5. bgeneto

    Ian Collins Guest

    bgeneto wrote:
    > Thanks for your explanation, if I understand well the string class and
    > possibly it's methods are defined in the namespace std within the
    > standard header <string>. If so, what is the point in doing this? Is it
    > any better compared to the old school? std sounds like a scope to me,
    > but what do we have defined without the scope std? No class, no
    > methods, nothing?
    > About your 'suggestion' to use full qualified names, I figure that I
    > must also use std::string in addition to std::cout, std::cin, etc... a
    > little cumbersome, no?
    >

    Cumbersome, but it avoids name collisions between symbols form the
    standard library and others. That's why the standard library is in its
    own namespace.

    The 'old school' (and current C) resolved naming issues by using more
    verbose names in an attempt to avoid ambiguities. At least with
    namespaces you can dispense with the namespace prefix with an
    appropriate using directive.

    --
    Ian Collins.
     
    Ian Collins, May 10, 2006
    #5
  6. bgeneto

    Phlip Guest

    bgeneto wrote:

    > Thanks for your explanation, if I understand well the string class and
    > possibly it's methods are defined in the namespace std within the
    > standard header <string>. If so, what is the point in doing this?


    The general set of keywords for C++ were invented in the 1980s.

    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.

    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.

    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".

    (Worse, code can also mix-and-match legacy and standard code. The less said
    about that the better.)

    So, if you need strings or "STL" containers, import their namespace. This is
    a very minor detail of well-structured code.

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
     
    Phlip, May 10, 2006
    #6
  7. bgeneto

    Alan Johnson Guest

    bgeneto wrote:
    > About your 'suggestion' to use full qualified names, I figure that I
    > must also use std::string in addition to std::cout, std::cin, etc... a
    > little cumbersome, no?
    >


    Within a source file it doesn't matter too much. In that context you
    know everything you need to know to tell if it is safe to issue a
    'using' directive. It is still my personal preference to explicitly
    name which symbols I'll be using. Example:
    using std::cout ;
    using std::endl ;

    In a header file it is best to avoid a 'using' directive that brings
    something into the global namespace, as you don't know when and where
    that header will get included, and whether or not your 'using'
    directives are going to cause trouble for the person doing the
    including.

    --
    Alan Johnson
     
    Alan Johnson, May 10, 2006
    #7
  8. bgeneto

    P.J. Plauger Guest

    "Alan Johnson" <> wrote in message
    news:e3rlp1$79b$...

    > bgeneto wrote:
    >> I know that it's a very basic question, but I can't figure out or find
    >> an answer to why do we have to specify a namespace, like this
    >>
    >> #include<string>
    >> using namespace std;
    >>
    >> when using the standard string library? Is this really necessary, why?
    >> Thanks,
    >>
    >> Bernhard Enders.
    >>

    >
    > When creating a library, it is generally a good idea to put any symbols
    > you define in their own namespace. Doing so severely decreases the
    > chances that names that you use will conflict with names in the library
    > you write conflicting with names in others' libraries. You might say
    > the designers of the C++ Standard Library were just following good style
    > and setting a good example by putting all their symbols in namespace
    > std.


    You might say that, if it were true. Unfortunately, the Standard C++
    library incorporates the Standard C library and the old cfront iostreams
    library, both of which were born before namespaces were invented. Thus,
    practically *every* pre-standard C++ program broke. Of course, you can
    patch most programs by changing a few header names and adding the
    notorious "using namespace std", but the latter is actively discouraged
    by those who believe in "good style".

    Even with newly written code, namespace std causes problems, mostly
    because not everything really lives there. Of course, you have some
    simple rules:

    -- If a name is all caps, it must be a macro, so you don't write std::
    in front of it (except for FILE).

    -- If a name is all lowercase, it must be a function or object, so
    you must write std:: in front of it (except for assert, errno, and
    setjmp).

    -- If a name begins with an underscore, it must be reserved to the
    implementation, so you shouldn't use it (except for _IOFBF, _IOLBF,
    and _IONBF).

    -- There are no names with mixed case (except for the macro L_tmpnam,
    and more recently the function _Exit).

    -- Otherwise, all names are in namespace std (except for those in
    std::relops).

    -- It is therefore safe to recycle a name from the Standard C library
    as your own name with external linkage (as long as it's not in either
    namespace std or the global namespace, or has extern "C" linkage).

    Got all that?

    It would have been far better to leave the Standard C++ library in
    the global namespace, where it was born and grew up. You can still
    use namespaces to protect your own code, and that is indeed good
    style. But nobody seems to teach that.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, May 10, 2006
    #8
  9. bgeneto

    P.J. Plauger Guest

    "Phlip" <> wrote in message
    news:lQd8g.3351$...

    > bgeneto wrote:
    >
    >> Thanks for your explanation, if I understand well the string class and
    >> possibly it's methods are defined in the namespace std within the
    >> standard header <string>. If so, what is the point in doing this?

    >
    > 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 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.

    > 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.

    > 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.

    > (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?"

    > 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.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, May 10, 2006
    #9
  10. bgeneto

    Phlip Guest

    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.

    >> 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...

    >> 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.

    >> 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. So it's the
    same difference, and it's an adequate way to explain the namespace std
    system to a newbie.

    >> (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.

    >> 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".

    http://www.janko.at/Humor/Computerwelt/using namespace std.htm

    --
    Phlip
    http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
     
    Phlip, May 10, 2006
    #10
  11. bgeneto

    Earl Purple Guest

    P.J. Plauger wrote:
    >
    > It would have been far better to leave the Standard C++ library in
    > the global namespace, where it was born and grew up. You can still
    > use namespaces to protect your own code, and that is indeed good
    > style. But nobody seems to teach that.


    But then you are assuming that everyone will have to learn the whole of
    the standard library to know what is in it to avoid nameclashes.

    You should be able to learn a subset of the language and use it. Most
    of us do. I don't use <valarray>, rarely if ever use <locale>, don't
    use any of the time-formatting stuff...
     
    Earl Purple, May 10, 2006
    #11
  12. bgeneto

    P.J. Plauger Guest

    "Phlip" <> wrote in message
    news:bvm8g.85172$...

    > 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
     
    P.J. Plauger, May 10, 2006
    #12
  13. bgeneto

    P.J. Plauger Guest

    "Earl Purple" <> wrote in message
    news:...

    > P.J. Plauger wrote:
    >>
    >> It would have been far better to leave the Standard C++ library in
    >> the global namespace, where it was born and grew up. You can still
    >> use namespaces to protect your own code, and that is indeed good
    >> style. But nobody seems to teach that.

    >
    > But then you are assuming that everyone will have to learn the whole of
    > the standard library to know what is in it to avoid nameclashes.


    Nope. Most new names are templates defined in brand new headers.
    There's a theoretical risk that <iostream> will drag in <valarray>,
    just as there's a theoretical risk that atan2 will drag in strtok.
    But in the real world of both Standard C and Standard C++, you can
    largely ignore what you don't use in the library.

    > You should be able to learn a subset of the language and use it. Most
    > of us do. I don't use <valarray>, rarely if ever use <locale>, don't
    > use any of the time-formatting stuff...


    Right. And putting everything in namespace std neither helps nor
    hinders such subsetting. But namespace std sure as hell hinders
    a) upgrading existing code and b) teaching newbies. Where's the
    net benefit?

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, May 10, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    935
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,132
    Smokey Grindel
    Dec 2, 2006
  3. Peng Yu
    Replies:
    0
    Views:
    659
    Peng Yu
    Sep 14, 2008
  4. mlt
    Replies:
    2
    Views:
    892
    Jean-Marc Bourguet
    Jan 31, 2009
  5. parmenides
    Replies:
    1
    Views:
    173
    Stefan Ram
    Aug 21, 2013
Loading...

Share This Page