On 12-05-25 14:54 , Joseph S. Myers wrote:
On Fri, 25 May 2012, Diego Novillo wrote:
On 12-05-25 12:25 , Jason Merrill wrote:
On 05/25/2012 11:37 AM, Joseph S. Myers wrote:
and it should be possible to eliminate the __need_* special cases
for some system headers by having more, smaller headers set up to define
individual types.
I was thinking the same thing.
Yes. Increased modularity in system headers is a must. That is likely going
to be one of the hard things to fix. I'd rather have that discussion in the
standards forums, as I suspect some of the same will be discussed for the
module proposal.
If feature test macros (or, similarly, assert.h depending on NDEBUG) are
the problem then that would need to be addressed for standards - but if
it's __need_* conditionals then those are an implementation detail for GCC
and glibc and any changes would need sorting out in the communities for
those toolchain components. (I don't know how good the libstdc++ headers
are at modularity, so I'm thinking about C headers, both those provided by
GCC and those provided by glibc.) Or is the issue with system headers
something else entirely?
There were several problems:
- Lack of double inclusion guards.
- Lack of modularity. For instance, accepting parameters to change the
meaning of the file, stddef.h is the canonical example.
- Mutually recursive inclusion. Some files seem to work in tandem, they
include each other conditionally just in case the other has not been
included yet.
- Some files refuse to be compiled in isolation because they are always
included by a wrapper file (e.g. the bits/* files).
- Files that use #include_next (they cannot be compiled in isolation).
- Some files give syntax errors when compiled in isolation because they
are missing symbols. for example, ext/algorithm needs __gnu_cxx::is_sorted.
Those are the ones I could gather on a quick grep through my build logs.
Lawrence may remember more.
Diego.
