I was just checking an answer and realized that CHAR_BIT isn't defined by headers as I'd expect, not even by #include <bitset>, on newer GCC.
Do I really have to #include <climits> just to get the "functionality" of CHAR_BIT?
As you may know, whether or not an implementation wants to include other headers is unspecified. It's allowed, but not mandated. (§17.4.4.1) So you either have to be explicit or know your guarantees.
The only time a C++ header must include another is if it requires a definition in another. For example, <bitset> is required to include <cstddef> for std::size_t, as this is explicitly stated in the standard. (§23.3.5, for this example)
For a counter-example, consider <limits>. It may include <climits> and define the values for numeric_limits in terms of the macros within, and it often does since that's easiest for an implementation. But all the standard says is things like: "Equivalent to CHAR_MIN, SHRT_MIN, FLT_MIN, DBL_MIN, etc." but doesn't say it must to be implemented in terms of those, which means <climits> doesn't have to be included.
So the only way you can be guaranteed that a CHAR_BIT is defined is by including <climits> or some other header where it's explicitly stated it must include it. And as far as I can tell, none have to; an implementation is free to just hard-code the value everywhere it's needed, for example, or include <limits> and use std::numeric_limits<unsigned char>::digits (which is equivalent).
Unless you're programming for DSPs, a better name for it is 8. POSIX and Windows both require CHAR_BIT==8, and that covers pretty much every interesting target conceivable except DSPs. (I would not consider 1970s mainframes a potentially interesting target anymore, but perhaps someone will beg to differ...)
<climits> is where CHAR_BIT is required to be by the C++ standard. Even if you happened to find it in <bitset>, its not guaranteed to be there, so you're better off going straight to the source. Its not like there's something wrong with including <climits>.
Define "newer". A random Linux system gave me these results:
~> gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2)
[snip]
~> grep CHAR_BIT /usr/include/*.h
/usr/include/limits.h:# define CHAR_BIT 8
Doesn't that qualify? In C, I think it should always be enough to include limits.h to get CHAR_BIT.
Yes, you should #include <limits.h> to get the definition of CHAR_BIT. It's not a bottleneck at all for your program (see comment below), and later down the line you might find yourself porting to different platforms. Not every implementation has the value of 8
I keep the following function in my .profile to check compiler defined constants. On my system __CHAR_BIT__ is in there, which means no header is required if you can live with the double underscore form, which may only work with gcc.
defines ()
{
touch /tmp/defines.h;
cpp -dD "$#" /tmp/defines.h | awk '$1!="#"{COUNT+=1;print;}END{printf("count %d\n",COUNT);}' | sort;
rm /tmp/defines.h
}
Related
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.
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.
What's the meaning of bits in '/usr/include/c++/4.4/bits/'
Linux, gcc of course.
The official designation of that folder according to the libstdc++ documentation is:
"Files included by standard headers
and by other files in the bits
directory"
Where "bits" probably just means something trivial as "the bits that make up the implementation of what you include via the standard headers".
For example, if you include the standard <algorithm> header, you really include bits/c++config.h, bits/stl_relops.h, bits/stl_pair.h bits/stl_algobase.h and bits/stl_algo.h under the hood, each of which defines the odd bits that alltogether give you what someone including <algorithm> would expect to get.
Boost calls the conceptually same folder "detail".
It means that the file is internal to gcc's implementation of the standard library, and you shouldn't include it directly. Where the name "bits" came from, I don't know.
What is the difference between <cstdint> and <tr1/cstdint>? (apart from that one puts things in namespace std:: and the other in std::tr1::)
Since this stuff isn't standard yet I guess it's compiler specific so I'm talking about gcc. To compile with the non-tr1 one I must compile with -std=c++0x, but there is no such restriction when using tr1.
Is the answer perhaps that there is none but you can't go around adding things to std:: unless there, well, standard. So until c++0x is standardised an error must be issued using <cstdint> but you dont need to worry when adding to the tr1:: namespace, which makes no claim to things in it being standard? Or is there more to this?
Thanks.
p.s - If you read "std" as standard, as I do, I do apologise for the overuse of the word in this Q.
At least as far as I know, there was no intent to change <cstdint> between TR1 and C++0x. There's no requirement for #includeing <cstdint> to result in an error though -- officially, it's nothing more or less than undefined behavior. An implementation is allowed to specify exact behavior, and in this case it does.
I think you've got it. On my system, they're very similar, but with different macro logic. For instance, /usr/include/c++/4.4/tr1/cstdint has:
# define _GLIBCXX_BEGIN_NAMESPACE_TR1 namespace tr1 {
# define _GLIBCXX_END_NAMESPACE_TR1 }
# define _GLIBCXX_TR1 tr1::
but /usr/include/c++/4.4/cstdint has:
# define _GLIBCXX_BEGIN_NAMESPACE_TR1
# define _GLIBCXX_END_NAMESPACE_TR1
# define _GLIBCXX_TR1
So if it's being included as <cstdint> the TR1 namespace is simply defined into oblivion.
<tr1/cstdint> is defined, as name suggests, in TR1, while <cstdint> is defined in c++0x.
From gcc manual, -std=c++0x is needed to enable experimental features that are likely to be included in C++0x. However, <tr1/cstdint> is defined in TR1, not c++0x, so -std=c++0x is no needed.
The following is gcc manual for -std=c++0x for your reference.
The working draft of the upcoming ISO C++0x standard. This
option enables experimental features that are likely to be
included in C++0x. The working draft is constantly changing,
and any feature that is enabled by this flag may be removed
from future versions of GCC if it is not part of the C++0x
standard.
which compiling a multithreaded program we use gcc like below:
gcc -lpthread -D_REENTRANT -o someprogram someprogram.c
what exactly is the flag -D_REENTRANT doing over here?
Defining _REENTRANT causes the compiler to use thread safe (i.e. re-entrant) versions of several functions in the C library.
You can search your header files to see what happens when it's defined.
Excerpt from the libc 8.2 manual:
Macro: _REENTRANT
Macro: _THREAD_SAFE
These macros are obsolete. They have the same effect as defining
_POSIX_C_SOURCE with the value 199506L.
Some very old C libraries required one of these macros to be defined
for basic functionality (e.g. getchar) to be thread-safe.
We recommend you use _GNU_SOURCE in new programs. If you don’t specify
the ‘-ansi’ option to GCC, or other conformance options such as
-std=c99, and don’t define any of these macros explicitly, the effect is the same as defining _DEFAULT_SOURCE to 1.
When you define a feature test macro to request a larger class of
features, it is harmless to define in addition a feature test macro
for a subset of those features. For example, if you define
_POSIX_C_SOURCE, then defining _POSIX_SOURCE as well has no effect. Likewise, if you define _GNU_SOURCE, then defining either
_POSIX_SOURCE or _POSIX_C_SOURCE as well has no effect.
JayM replied:
Defining _REENTRANT causes the compiler to use thread safe (i.e. re-entrant) versions of several functions in the C library.
You can search your header files to see what happens when it's defined.
Since OP and I were both interested in the question, I decided to actually post the answer. :) The following things happen with _REENTRANT on Mac OS X 10.11.6:
<math.h> gains declarations for lgammaf_r, lgamma_r, and lgammal_r.
On Linux (Red Hat Enterprise Server 5.10), I see the following changes:
<unistd.h> gains a declaration for the POSIX 1995 function getlogin_r.
So it seems like _REENTRANT is mostly a no-op, these days. It might once have declared a lot of new functions, such as strtok_r; but these days those functions are mostly mandated by various decades-old standards (C99, POSIX 95, POSIX.1-2001, etc.) and so they're just always enabled.
I have no idea why the two systems I checked avoid declaring lgamma_r resp. getlogin_r when _REENTRANT is not #defined. My wild guess is that this is just historical cruft that nobody ever bothered to go through and clean up.
Of course my observations on these two systems might not generalize to all systems your code might ever encounter. You should definitely still pass -pthread to the compiler (or, less good but okay, -lpthread -D_REENTRANT) whenever your program requires pthreads.
In multithreaded programs, you tell the compiler that you need this feature by defining the _REENTRANT macro before any #include lines in your program. This does three things, and does them so elegantly that usually you don’t even need to know what was done:
Some functions get prototypes for a re-entrant safe equivalent.
These are normally the same function name, but with _r appended so
that, for example, gethostbyname is changed to gethostbyname_r.
Some stdio.h functions that are normally implemented as macros
become proper re-entrant safe functions.
The variable errno, from errno.h, is changed to call a function,
which can determine the real errno value in a multithread safe way.
Taken from Beginning Linux Programming
It simply defined _REENTRANT for the preprocessor. Somewhere in the associated code, you'll probably find #ifdef _REENTRANT or #if defined(_REENTRANT) in at least a few places.
Also note that the name "_REENTRANT: is in the implementer's name space (any name starting with an underscore followed by another underscore or a capital letter is), so defining it means you've stepped outside what the standard defines (at least the C or C++ standards).