std namespace and headers

This is a discussion on std namespace and headers within the C++ Programming forums, part of the General Programming Boards category; Hi, As far as i understand, when i want to use an STL function i shall 1) include the header ...

  1. #1
    Registered User
    Join Date
    Dec 2006
    Posts
    60

    std namespace and headers

    Hi,
    As far as i understand, when i want to use an STL function i shall
    1) include the header file in which it is declared so as to get a link to its definition
    2) Use the using declaration because it is out of its namespace

    However, in the following code


    Code:
    #include<ctime>
    #include<iostream>
    using std::cout;
    
    main(){
           char time[9];
    cout<<_strtime(time);
    system("pause");
    }
    there is no need to use the using declaration for _strtime function. May someone explain me why?

  2. #2
    MFC killed my cat! manutd's Avatar
    Join Date
    Sep 2006
    Location
    Boston, Massachusetts
    Posts
    870
    It is because that function was from C's <time.h> library, which had no namespaces, including std.
    Silence is better than unmeaning words.
    - Pythagoras
    My blog

  3. #3
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    In order to use size_t, I've been including <cstddef> and then using size_t without the std:: qualifier. Is this guaranteed to work, or should I be using std::size_t to be safe?

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> there is no need to use the using declaration for _strtime function. May someone explain me why?
    I'm not sure if _strtime is a C or C++ function. It might be a compiler extension, in which case it wouldn't need to be in the std namespace.

    In addition, the library that comes with your compiler might include standard library names both in the std namespace and the global namespace, so it is possible that even a standard library name could be used without the std::. For example, Dinkumware (the company that supplies Visual C++'s standard library) mentions in their documentation that some names in <ctime> are declared in the global namespace in addition to the std namespace.

    So if you are using a standard name, use the std namespace just to maintain portability even if the compiler allows code without it.

    >> Is this guaranteed to work, or should I be using std::size_t to be safe?
    I believe you should be using std::size_t to be safe, although the part of the standard I just looked at didn't specifically mention that.
    Last edited by Daved; 12-18-2006 at 01:30 PM.

  5. #5
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    The code in my <cstddef> is
    Code:
    #ifndef _GLIBCXX_CSTDDEF
    #define _GLIBCXX_CSTDDEF 1
    
    #pragma GCC system_header
    
    #include <stddef.h>
    
    namespace std
    {
      using ::ptrdiff_t;
      using ::size_t;
    }
    
    #endif
    so on my system, size_t is originally in global and then added to std. I take it that it's not guaranteed that when including a <cXXXXX> header, the objects in it are in the global namespace, only that they're in std?

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    In general, the <cXXXX> headers are supposed to take the <XXXX.h> headers and wrap them in the std namespace. Keeping names in the global namespace as well is not required. However, I didn't see at quick glance at the standard the part that specifies this, so I won't say absolutely for certain.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The clauses that are relevant are:
    17.3.1.1 &#167;2: "All library entities except macros, operator new and operator delete are defined within the namespace std or namespaces nested within namespace std."

    137.3.1.2 &#167;4: "Except as noted in Clauses [...], the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in [C standards], as appropriate, as if by inclusion. In the C++ Standard library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope of the namespace std."

    Note that it is therefore, strictly speaking, non-compliant to have the contents visible in the global namespace after including a <c*> header. However, due to the extremely common implementation technique of including the .h and importing into the std namespace, this is a very commonly violated part of the spec.

    Annex 0 1.5 &#167;2: "Each C header, whose name has the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration."

    In other words, including the C-style header actually has to make the stuff available in std:: and in ::. I don't think any popular implementation actually conforms to this.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Quote Originally Posted by CornedBee
    The clauses that are relevant are:
    17.3.1.1 §2: "All library entities except macros, operator new and operator delete are defined within the namespace std or namespaces nested within namespace std."

    137.3.1.2 §4: "Except as noted in Clauses [...], the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in [C standards], as appropriate, as if by inclusion. In the C++ Standard library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope of the namespace std."

    Note that it is therefore, strictly speaking, non-compliant to have the contents visible in the global namespace after including a <c*> header. However, due to the extremely common implementation technique of including the .h and importing into the std namespace, this is a very commonly violated part of the spec.
    Are you sure? It sounds to me like it's only saying that the contents have to be visible in std::, not that they can't also be visible in other namespaces such as ::.

    Quote Originally Posted by CornedBee
    Annex 0 1.5 §2: "Each C header, whose name has the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration."

    In other words, including the C-style header actually has to make the stuff available in std:: and in ::. I don't think any popular implementation actually conforms to this.
    That is consistent with my situation, where size_t is in both std:: and ::, and appears to contradict your interpretation of the first clause (not that there couldn't be contradictions in the standard itself).

  9. #9
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,434
    > Are you sure? It sounds to me like it's only saying that the contents have to be visible in std::, not that they can't also be visible in other namespaces such as ::.

    As far as the new header style is concerned, they can't be visible in the global namespace. Only in the std namespace.

    So <cstddef> (the new style) should introduce all names in the std namespace only, while stddef.h (the old style) should introduce names both in the std and the global namespaces.

    > That is consistent with my situation, where size_t is in both std:: and ::, and appears to contradict your interpretation of the first clause (not that there couldn't be contradictions in the standard itself).

    There isn't any contradiction. Just remember that C-Style headers refers to headers in the form "name.ext", not <name>.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #10
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,434
    Just noticed your previous post to the one I just replied.

    What happens is that there are some exceptions to the std namespace. cstddef, cstdlib, and ctime, are some of the ones I remember about... also cstdarg, and just a few more.

    These libraries are meant to be the same as their C counterparts, and names are added also to the std namespace. But this is the exception.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The stuff defined by C to be macros (NULL, offsetof, ...) are to be macros in the C++ version too, so they are obviously not bound by namespace constraints. All other symbols are to be in the std namespace. The standard permits all names not starting with two underscores or an underscore followed by an uppercase letter to appear in standard-compliant programs. In other words, including standard headers must not use any of these names except those explicitly defined in the standard. That's what the std namespace is for.

    As for the "contradiction", that paragraph was about the .h form of the header, to which different rules apply.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. namespace tm?
    By cunnus88 in forum C++ Programming
    Replies: 3
    Last Post: 01-28-2009, 02:02 PM
  2. what's wrong with this piece of code
    By studentc in forum C++ Programming
    Replies: 4
    Last Post: 01-11-2006, 06:58 PM
  3. code does not compile
    By aldajlo in forum C++ Programming
    Replies: 19
    Last Post: 10-13-2004, 02:54 PM
  4. Headers that use each other
    By nickname_changed in forum C++ Programming
    Replies: 7
    Last Post: 10-03-2003, 04:25 AM
  5. [B]using namespace std[/B]
    By Magos in forum C++ Programming
    Replies: 6
    Last Post: 02-05-2002, 08:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21