Eric Lemings wrote:
Consider the following:
file $TOPDIR/include/memory:
...
30 #ifndef _RWSTD_MEMORY_INCLUDED
31 #define _RWSTD_MEMORY_INCLUDED
32
33 #include <rw/_allocator.h>
34 #include <rw/_autoptr.h>
35 #include <rw/_iterbase.h>
36 #include <rw/_pair.h>
37 #include <rw/_rawiter.h>
38 #include <rw/_specialized.h>
39 #include <rw/_defs.h>
40
41 #endif // _RWSTD_MEMORY_INCLUDED
Any idea why <rw/_defs.h> is included last? I've noticed this in a
couple other standard headers also.
As opposed to being first, or in the middle? What would be the
rationale?
The (undocumented) style for #include directives in stdcxx goes
something like this:
In all library headers:
1. standard headers (C++, including stdcxx own, C, or POSIX are
never included (there are a shrinking number of exceptions to
this rule)
2. include directives are in alphabetical order, with rw/_defs.h
being last (it still ends up getting included first, indirectly,
by the first header); the exception here is when a stdcxx config
macro needs to be tested before the first #include directive
3. each #include directive in every standard header is guarded with
a preprocessor conditional testing the XXX_INCLUDED macro for
the corresponding header for compile-time efficiency
In library sources:
1. sets of C++, C, POSIX, and stdcxx-private headers are included
in separate blocks of their own, in alphabetical order within
each block
2. C headers are included using the xxx.h form (as opposed to the
cxxx form) for better portability
Martin
