From what I understand, the namespace std contains all of C++ standard libraries, and one of the standard libraries is the iostream and it has the objects cout and cin.
std namespace
|
iostream
|
cout, cin
Is the above structure correct? Or is it different?
From what I understand, the namespace std contains all of C++ standard
libraries, and one of the standard libraries is the iostream and it
has the functions cout and cin.
Not quite.
Although almost all of the standard library is in namespace std, we also have the C components outside of std when using the old header form (<stdio.h> instead of <cstdio>), and the assert macro, which is not scoped.
std::cin and std::cout are not functions but objects.
<iostream> is just the name of a header which contains parts of what the C++ ISO standard officially names "Input/output library" (std::iostream is a rarely used typedef for the std::basic_iostream<char> class).
Certain components of the library can be pulled in by different #includes. For example, std::initializer_list becomes available through <initializer_list> or through includes like <vector>.
Without going into too much detail, header files and scoping are two orthogonal concepts in C++. In other words, they exist in parallel to each other. There is no useful hierarchy among/between them.
You are correct when you assume that everything that's in the standard library is contained in the std namespace, with a few exceptions, as per 17.6.1.1/§3 in the standard:
All library entities except macros, operator new and operator delete are defined within the namespace std or namespaces nested within namespace std. It is unspecified whether names declared in a specific namespace are declared directly in that namespace or in an inline namespace inside that namespace.
Then, when you say "the libraries", there's only one library here, the "standard library". iostream is a header of this library. But that doesn't mean everything from a header is in a specific namespace.
For example, cin and cout are directly in the std namespace, but are included with the <iostream> header.
Related
How come this piece of code doesn't need std namespace.
#include <stdio.h>
int main()
{
printf("Hello World");
return 0;
}
Because you included a C header, not a C++ header.
[library.c/1]: The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety.
[depr.c.headers.other/1]: Every C header other than <complex.h>, <iso646.h>, <stdalign.h>, <stdbool.h>, and <tgmath.h>, each of which has a name of the form <name.h>, behaves as if each name placed in the standard library namespace by the corresponding <cname> header is placed within the global namespace scope, except for the functions described in [sf.cmath], the declaration of std::byte ([cstddef.syn]), and the functions and function templates described in [support.types.byteops]. [..] It is unspecified whether these names are first declared or defined within namespace scope ([basic.scope.namespace]) of the namespace std and are then injected into the global namespace scope by explicit using-declarations ([namespace.udecl]).
The last bolded part above says that you may have been able to use std::printf as well, but that there is no guarantee of that.
Also note that the header is deprecated:
[diff.mods.to.headers/1]: For compatibility with the C standard library, the C++ standard library provides the C headers enumerated in [depr.c.headers], but their use is deprecated in C++.
On the flip side of the coin, if you'd included cstdio instead, you'd be guaranteed to get std::printf but the availability of ::printf (the fully-qualified name of the global symbol you used) would not be guaranteed:
[headers/4]: Except as noted in [library] through [thread] and [depr], the contents of each header cname is the same as that of the corresponding header name.h as specified in the C standard library. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope of the namespace std. It is unspecified whether these names (including any overloads added in [language.support] through [thread] and [depr]) are first declared within the global namespace scope and are then injected into namespace std by explicit using-declarations ([namespace.udecl]).
Short version:
C headers like stdio.h are in the global namespace, and possibly also in std;
C++ headers like cstdio are in the namespace std, and possibly also in the global namespace.
You only need using namespace std or std:: when you're using the namespace std,
The stdio.h header file allows you to use additional methods in the standard library that do not exist in all C++ code by default. By adding the line #include , you are instructing the compiler to copy the declarations in that header file into your code so you have access to them.
The line using namespace std allows you to utilize methods in the standard namespace without having to call out the standard name space each time. This helps eliminate typos, but could introduce other errors (if two namespaces have the same method signature).
For example,
#include <iostream>
std::cout << "Hello World!" << std::endl;
Could be written as:
#include <iostream>
using namespace std;
cout << "Hello World!" << endl;
using namespace std makes names from the standard namespace visible in your namespace.
stdio.h i a header that doesn't use its own namespace but instead puts its functions (e.g. printf) etc. in the namespace in which you include it (in your case the global namespace). Therefore you can access them directly.
Note that including headers in a namespace is not generally recommended (see first comment for an example), I only mentioned it for the sake of completeness since it might not be obvious for a beginner that the placement of the include makes a difference.
My program originally used using namespace std; but I have heard from numerous people that this is bad programming practice so I want to break the habit. I changed all of the couts and endls in my program to std::cout and std::endl;.
Aside from cout and endl, what uses the namespace std? For example: I have vectors and strings in my program; do they use std::?
A list would be nice if it's not too long or too much of a hassle.
For example: I have vectors and strings in my program; do they use std::?
Yes. Vectors and strings are part of the standard library. The members of the std namespace are in the standard library.
A list would be nice if it's not too long or too much of a hassle.
I can't give you a long, concise list. But I can show you how to find the members of the standard library. For example, take your other question. Are strings and vectors part of the standard library?
http://en.cppreference.com/w/
If we go here, click on 'Strings library' we can infact see the different types of strings we can employ in our C++ program. This process is the same for vectors, under the 'Containers library' section we can see vector, list, map etc.
If you have an IDE, you can also view the members of the standard library by prefacing your statement with std:: -
Although you do have to have a matching header file included to see members of the standard library, the headers are named as you'd expect,
#include <list>
#include <vector>
#include <string>
Dumping the entire std namespace into your program is perhaps not the wisest choice, but I wouldn't be troubled by using specific elements from std. So instead of writing using namespace std you can use using std::cout, using std::endl, etc. Having to qualify lots and lots of code does not, in my opinion, help readability.
As for what's in std, it's a very long list, including all of STL. Just try to compile and see where the compiler complains.
In short:
For everything in the C++ standard library.
That includes datastructures, algorithms, input output functions, type_traits, string manipulation, almost everything you can find in the C standard library... . You can find a list e.g. at cppreference.com
Almost all types and functions provided by the C++ standard library are in namespace std. Roughly speaking, this includes everything in standard headers without a .h in their filename - like <vector>, <iostream> (which brings in std::cout), <string> (std::string), <algorithm> (standard algorithms), and EVERY other standard C++ header file. It does not include the C standard library (<stdio.h>, <stdlib.h>, etc) although these do have equivalents in the C++ standard library (<cstdio>, <cstdlib>, etc) which do place their declarations into namespace std.
There is no point in writing a list. If you are using any part of the C++ standard library, you will be working with namespace std. So any reference of the C++ standard library is the defacto list.
There are a couple of exceptions (e.g. names in the standard headers that are specified to be macros) but those are rare.
So this is something that I've always wondered but was never quite sure about. So it is strictly a matter of curiosity, not a real problem.
As far as I understand, whenyou do something like #include <cstdlib> everything (except macros of course) are declared in the std:: namespace. Every implementation that I've ever seen does this by doing something like the following:
#include <stdlib.h>
namespace std {
using ::abort;
// etc....
}
Which of course has the effect of things being in both the global namespace and std. Is this behavior guaranteed? Or is it possible that an implementation could put these things in std but not in the global namespace? The only way I can think of to do that would be to have your libstdc++ implement every c function itself placing them in std directly instead of just including the existing libc headers (because there is no mechanism to remove something from a namespace). Which is of course a lot of effort with little to no benefit.
The essence of my question is, is the following program strictly conforming and guaranteed to work?
#include <cstdio>
int main() {
::printf("hello world\n");
}
EDIT: The closest I've found is this (17.4.1.2p4):
Except as noted in clauses 18 through
27, the contents of each header cname
shall be the same as that of the
corresponding header name.h, as
specified in ISO/IEC 9899:1990
Programming Languages C (Clause 7), or
ISO/IEC:1990 Programming Languages—C
AMENDMENT 1: C Integrity, (Clause 7),
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 (3.3.5) of the namespace std.
which to be honest I could interpret either way. "the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in ISO/IEC 9899:1990 Programming Languages C" tells me that they may be required in the global namespace, but "In the C + + Standard Library, however, the declarations and definitions (except for names
which are defined as macros in C) are within namespace scope (3.3.5) of the namespace std." says they are in std (but doesn't specify any other scoped they are in).
Here's a nice synopsis of the situation (with some reality vs. what the standard says) from Stephan T. Lavavej of the MSVC team (http://blogs.msdn.com/vcblog/archive/2008/08/28/the-mallocator.aspx#8904359):
> also, <cstddef>, <cstdlib>, and std::size_t etc should be used!
I used to be very careful about that. C++98 had a splendid dream wherein <cfoo> would declare everything within namespace std, and <foo.h> would include <cfoo> and then drag everything into the global namespace with using-declarations. (This is D.5 [depr.c.headers].)
This was ignored by lots of implementers (some of which had very little control over the C Standard Library headers). So, C++0x has been changed to match reality. As of the N2723 Working Paper, http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf , now <cfoo> is guaranteed to declare everything within namespace std, and may or may not declare things within the global namespace. <foo.h> is the opposite: it is guaranteed to declare everything within the global namespace, and may or may not declare things within namespace std.
In reality and in C++0x, including <cfoo> is no safeguard against everything getting declared in the global namespace anyways. That's why I'm ceasing to bother with <cfoo>.
This was Library Issue 456, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456 .
(C++0x still deprecates the <foo.h> headers from the C Standard Library, which is hilarious.)
I've never been fond of the <cfoo> headers myself, and found that I've always use <foo.h>. Now I feel like I can stop being anxious about my lack of C++ 'purity' in that regard.
At the present time, no. In fact, even though the code will work with every compiler I now of, it's really not supposed to work at all -- #includeing one of the c* headers is only supposed to give you access to the names inside of namespace std.
Since implementation of this was such a pain (getting it right essentially required duplicating the entire C library as a C++ library in the right namespace), in C++ 0x they've changed the requirements a bit -- your code is now allowed to work, though (at least if memory serves) it's still not required to work.
I cannot speak for the standards, as I have not read them, but one could envision a C++ environment that is not built on top of a C environment, or where the C environment is a compatibility layer on top of underlying C++ APIs. In such a case, these guarantees may not be made. I would be surprised if such an implementation would be prohibited from being a compliant implementation.
Does the runtime library pollute the global namespace?
I don't think you really understand the terms you are using, but the names in the C++ Standard Library exist in the std namespace, so the answer is no. The names in the header files that originated in the C Standard Library are placed in the global namespace, if you #include them via the .h filenames, such as:
#include <stdio.h>
if you #include them like this:
#include <cstdio>
then the names exist in both global and std namespaces.
The reason for placing objects in the std namespace is not so much to avoid "namespace polution", which is hardly a value neutral term, but to avoid name clashes.
The runtime library is required to use reserved identifiers. Without namespace qualification, these must begin with two underscores: __start, etc.
You are not allowed to use reserved names. The library is not allowed to use your names. If either crosses over to the other, it is "pollution" which is illegal.
Essentially, the situation is the same for C and C++ except, as the other answers point out, in C++ most standard library names have namespace qualification.
Most of the library cleanly goes in namespace std: -- however, for backwards compatibility with C, you may choose to "pollute" the global namespace by including old headers like <math.h> (which puts lots of names in the global namespace) instead of the proper new ones like <cmath> (which uses the std: namespace properly).
The C++ Programming Language : Special Edition states on page 431 that...
For every header < X.h > defining part of the C standard library in the global namespace and also in namespace std, there is a header < cX > defining the same names in the std namespace only.
However, when I use C headers in the < cX > style, I don't need to qualify the namespace. For example...
#include <cmath>
void f() {
double var = sqrt( 17 );
}
This would compile fine. Even though the book says that using the < cX > header defines names in the std namespace only, you are allowed to use those names without qualifying the namespace. What am I missing here?
P.S. Using the GNU.GCC compiler
Stephan T. Lavavej, a member of the MSVC team, addresses the reality of this situation (and some of the refinements to the standard) in this comment on one of his blog postings (http://blogs.msdn.com/vcblog/archive/2008/08/28/the-mallocator.aspx#8904359):
> also, <cstddef>, <cstdlib>, and std::size_t etc should be used!
I used to be very careful about that. C++98 had a splendid dream wherein <cfoo> would declare everything within namespace std, and <foo.h> would include <cfoo> and then drag everything into the global namespace with using-declarations. (This is D.5 [depr.c.headers].)
This was ignored by lots of implementers (some of which had very little control over the C Standard Library headers). So, C++0x has been changed to match reality. As of the N2723 Working Paper, http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf , now <cfoo> is guaranteed to declare everything within namespace std, and may or may not declare things within the global namespace. <foo.h> is the opposite: it is guaranteed to declare everything within the global namespace, and may or may not declare things within namespace std.
In reality and in C++0x, including <cfoo> is no safeguard against everything getting declared in the global namespace anyways. That's why I'm ceasing to bother with <cfoo>.
This was Library Issue 456, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456 .
(C++0x still deprecates the <foo.h> headers from the C Standard Library, which is hilarious.)
I'm in 100% agreement with Lavavej, except I never tried to be very careful about using the <cfoo> style headers even when I first started using C++ - the standard C ones were just too ingrained - and there was never any real world problem using them (and apparently there was never any real world benefit to using the <cfoo> style headers).
The rule for the C libraries differs from C++ libraries for namespaces
gcc interprets the standard in Gcc docs as
The standard specifies that if one includes the C-style header (<math.h> in this case), the symbols will be available in the global namespace and perhaps in namespace std:: (but this is no longer a firm requirement.) One the other hand, including the C++-style header (<cmath>) guarantees that the entities will be found in namespace std and perhaps in the global namespace.
In the draft C0X++ spec it says in section 17.6.2.3 Headers
It is unspecified whether these names are first declared within the global namespace scope and are then injected
into namespace std by explicit using-declarations
It's hard to fix this without implementing the C library twice. See DR 456, which basically proposes giving up on the problem.
Why do you say "This would compile fine" when it violates the Standard? Who allows you to use those names without qualifying the namespace? Have you tested this on a particular implementation and found that it works?
I strongly advise against using some particular non-standard feature because it happens to work on your compiler of choice. Such things break easily, perhaps with a later version of the same compiler.
You are probably missing using a standards-conformant compiler (or the one you use is configured to be compatible with pre-standard code).