I've been looking over some code for a class and I see in one place it has this line:
#ifndef __SGI_STL_PORT
What is __SGI_STL_PORT ?
When will this be defined?
This is a "feature test macro"; it will be defined when using the STL port implementation of the standard template library (so, for example, if you include <vector> and it was provided by the STL port version of the library, then this macro will be defined). This can be useful for taking advantage of implementation-specific extensions which are not guaranteed to exist by the C++ standard.
Related
I am a newbie in c++, and I suspect, that, of course the question relates not only to tuple.
So, I've watched a tutorial with roughly this code:
#include <tuple>
std::tuple<...> t(...)
Why #include <tuple>? Especially, given the fact that we explicitly write std::tuple. The code compiles without that #include line just well...
Because <tuple> is a header file which contains the tuple class inside the namespace std. Just because you're explicitliy saying std:: doesn't mean the compiler will just be able to find it if it's not included.
The reason it worked for you in this case is probably because another header you have included already includes <tuple> and thus your code includes <tuple> indirectly or because the compiler you're building with includes it automatically. This is not guaranteed by the standard and should not be relied upon. Always include the headers you'll need to make your code portable.
You always should include the specific headers for any types that you use in your code.
The code compiles without that #include line just well...
That your code compiles without is just by chance, because it might have been included by another standard header you use in your program, and not guaranteed by the standard, and thus not portable.
Especially, given the fact that we explicitly write std::tuple.
The explicit use of the std:: namespace doesn't have any significance about that rule.
You should also always be explicit about using classes or types from the std namespace to prevent getting into ambiguity troubles.
Related stuff:
Why is “using namespace std;” considered bad practice?
Why should I not #include ?
How do I include the string header?
In C++ you need to include the header for everything you use. The std:: is about the namespace, it's completely different.
Apparently your compiler is smart enough to deal with it, but most of the compilers won't.
Some standard headers shall include other standard headers according to the C++ Standard. For example the header <algorithm> must include the header <initializer_list>.
However implementations are allowed to include standard headers in other standard headers at their discretion.
You should not rely on this because your program compiled with one compiler will not compile using another compiler.
Even if one standard header is included in another standard header according to the requirements of the C++ Standard nevertheless it is a good practice to include such a header explicitly because the user of the program (some other programmer) should bother about dependencies of the headers and will be free to include or exclude other headers.
I am used to writing codes using stl pair without including any specific header file for using pair. But a friend today told me that I should use utility header whenever I use pair else I will have problem on some compilers. Please tell if this is true. And what is the use of utility header if I can write codes without using it.
You should almost always include header file for every class which you use in your program, otherwise you depend on the fact that some headers internally use a class of your interest, but this can change on another compiler or version. You need to read reference of a class (for example on cppreference.com - http://en.cppreference.com/w/cpp/utility/pair ) and check which header file you need to include - in case of std::pair you should add #include <utility> . You cannot depend on the fact, that, for example, iostream already includes iomanip and your code compiles when you use manipulators like setw etc. You cannot - you always should refer to language specs and include required headers.
The point is that you may have had indirectly included the <utility> header through the inclusion of some other header. Usually it is the case that headers are included by other headers in a C++ implementation without that inclusion being mandated by the standard. So, by including <utility>, you make sure your code is portable across standard compliant implementations (at least with respect to this particular issue).
The standard specifies that std::pair is in <utility>, so you should include this whenever you use an std::pair.
You always need to include the headers defining the components you use. Some standard libraries will be implemented to include other declarations they use internally butyou can't rely on this, at all. I consider it an error that standard libraries make declarations available they are not required to make available.
The class template std::pair is made available by <utility>.
In what cases should we include cassert?
In short, don't use it; use <assert.h>.
C++11 removed any formal guarantee of a "c...." header not polluting the global namespace.
It was never an in-practice guarantee, and now it's not even a formal guarantee.
Hence, with C++11 there is no longer any conceivable advantage in using the "c...." header variants, while there is the distinct and clear disadvantage that code that works well with one compiler and version of that compiler, may fail to compile with another compiler or version, due to e.g. name collisions or different overload selection in the global namespace.
SO, while cassert was pretty meaningless in C++03 (you can't put a macro in a namespace), it is totally meaningless -- even as a special case of a general scheme -- in C++11.
Addendum, Dec 22 2013:
The standard defines each C++ C header <X.h> header in terms of the <cX> header, which in turn is defined in terms of the corresponding C library header.
C++11 §D.5/2:
“Every C header, 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.”
C++11 §D.5/3 (non-normative example):
“The header <cstdlib> assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header <stdlib.h> assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std.”
Stack Overflow user C.R.’s comment made me aware that some versions of g++, such as MinGW g++ 4.7.2, are quite non-standard with respect to the <X.h> headers, lacking the overloads of e.g. sin that the C++ standard requires:
I already knew that MinGW g++ 4.7.2 also entirely lacks functions such as swprintf, and that it has ditto shortcomings in the pure C++ library such as lacking C++11 std::to_string. However, the information about it lacking the C function overloads was new to me.
In practice the lacking overloads with g++ means
ignoring the g++ issue, or
avoiding using the missing g++ overloads,
e.g. using only double sin( double ), or
using the std namespace overloads
(one then needs to include <cmath> to guarantee their presence with g++).
In order to use the g++ std namespace overloads unqualified, one practical approach is to define headers wrappers for this compiler. I've used that approach to address g++ shortcomings wrt. to the printf family. For as David Wheeler once remarked, “All problems in computer science can be solved by another level of indirection”…
Then things can be arranged so that standard code that uses g++'s missing overloads, also compiles with g++. This adjusts the compiler to the standard, with a fixed amount of code.
Just like any other header file, you #include <cassert> when you use something declared in that header file, such as assert().
See an easily accessible reference
#include <iostream>
// uncomment to disable assert()
// #define NDEBUG
#include <cassert>
int main()
{
assert(2+2==4);
std::cout << "Execution continues past the first assert\n";
assert(2+2==5);
std::cout << "Execution continues past the second assert\n";
}
assert.h defines one macro function that can be used as a standard debugging tool.
Could someone say me where I can found the source file where are the definitions of the standard libraries?
For example, where is the file string.c that contains the definitions of the function prototyped in string.h? And above all, it exists?
its all in compilled state, some of maybe optimized by asm. You need find sources of your compiler to see definitions
For GCC, which is open source, you can download the sources for the libstdc++ library from their mirror sites here. Included in the download is the source for the std library. Bear in mind that different vendors will have different implementations, so the link provided is merely how the developers of GCC decided to implement the standard library
You're probably not going to like this.
The C++ Standard does not say specifically where anything in the Standard Libraries are actually implemented. It says where things are declared, but only to the degree that it names the file(s) you must #include in order to bring the names in. For example, the Standard says that:
std::string
is a typedef for basic_string<...>, and in order to bring that typedef in to your program, you must #include <string>. It doesn't actually say that basic_string or string are defined in <string> however, and it doesn't say where, on your hard drive <string> is even located. In fact, it's often not in <string> in the real world. In my implementation, (MSVC10) string is defined in a different file, <xstring>, and it looks like this:
typedef basic_string<char, char_traits<char>, allocator<char> >
string;
Useful, huh?
There's another aspect. A lot of the stuff in the Standard Library is template stuff, like string, so because of the way templates work in C++ these facilities must be so-called "include libraries." But not everything in the Standard Library is made up of templates.
Consider sprintf. The Standard says that this declaration is provided by #include <cstdio> but that, like string isn't even where it's declared. And sprintf isn't a template thing. the implementation is in what's often called the CRT -- the C Runtime Library. This is a collection of DLLs and LIBs (in MSVC10, anyway) that your program links to to run code like sprintf.
Now the bad news is those components that are in the CRT are generally shipped without source code. You don't know where sprintf is implemented and you can't look at the source code. You're left with little alternative in these cases except get a job with MicroSoft so you can take a look at the source code. :)
Are there any predefined macros for C++ in order the code could identify the standard?
e.g. Currently most compilers puts "array" into "tr1" folder but for C++11 it would be part of STL. So currently
#include <tr1/array>
but c++11
#include <array>
What is the predefined macros for 03 standard and 11 standard in order I can use #ifdef to identify?
Also, I suppose there are macros for C90 and C99?
Thanksx
From Stroustrup's C++11 FAQ
In C++11 the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.
You can likely test it's value to determine if it's c++0x or not then.
Nitpick...
Your particular issue does not depend on your compiler, it depends on the Standard Library implementation.
Since you are free to pick a different Standard Library that the one provided by your compiler (for example, trying out libc++ or stlport), no amount of compiler specific information will help you here.
Your best bet is therefore to create a specific header file yourself, in which you will choose either one or the other (depending on a build option).
// array.hpp
#ifdef STD_HAS_TR1_ARRAY_HEADER
#include <tr1/array>
#else
#include <array>
#endif
You then document the compiler option:
Passing -DSTD_HAS_TR1_ARRAY_HEADER will mean that std::tr1::array is defined in <tr1/array> instead of the default <array>.
And you're done.
From the draft N3242:
16.8 Predefined macro names [cpp.predefined]
...
The name _ _ cplusplus is defined to the value 201103L when
compiling a C++ translation unit. 155)
...
155) It is intended that future versions of this standard will
replace the value of this macro with a greater value.
Non-conforming compilers should use a value with at most five
decimal digits.
Ultimately, you're going to have to use compiler-specific information. At least, until C++0x becomes more widespreadly implemented. You basically need to pick driver versions that implement something and test compiler-specific macros on them.
The Boost.Config library has a number of macros that can help you.