Re: Standard header format.

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Steven,

I have read this thread with amusement without commenting (I've only
worked on improving corners of libstdc++-v3 by standing on the
shoulders of others).  I've re-read your first post and gone back to
your first questions...  I've decided that you are not a troll but
rather a somewhat misunderstood questioner and/or somewhat misguided.
[Really, this is not an insult, but an observation to set context.]

> I've discovered that the files representing the Standard Library
> headers in a GCC distrubution are not direct representations of the
> interface described in ISO/IEC 14882.  The files I'm talking about
> are listed by the following command, assuming GNU_GCC points to the
> root of the gcc-3.3.3 installation.

True.  For reasons, which you may or may not like, outlined in this
ever-expanding thread...

> [...] If I want to automatically process the standard header
> interface to create a code completion or edit-time error detections
> mechanism, I cannot directly use the files generated by the command
> above.  I'm not even sure I could create the kind of data structure
> necessary to support the functionality by processing the GCC
> headers.

The statement is True, False, or Maybe.  Even using plain etags, you
could automatically process our complete library headers for use with
code completion.  I know this works because I have done it myself.
That is proof by example that it can work if you feed the process
correctly.  Now, it is true that you will get a lot of implementation
detail exposed with default etags processing rules.  However, we
document our internal coding conventions in great detail, such that
you could get very close to just standard defined stuff with the right
filter rules. (I'm not giving them here since I haven't written them
but I know that a regular expression may be written to exclude
implementation detail symbols and run over the TAGS file.  Modern tag
systems, including latest etags, will also take them at creation time.)

> Is there an easy way to extract the interface declarations for the
> Standard Library from the GCC include hierarchy?  If not, I propose
> that either that mechanism be created, or some means of providing a
> direct representation of the standard headers be part of the GCC
> distribution.

Reading between the lines, it appears that you want one file,
somewhere on disk or to feed an automatic process, which defines
exactly what e.g. <vector> exposes.  You might also want it filtered
to appear exactly/somewhat as the standard implies.  In all
seriousness, have you considered:

$ echo '#include <vector>' | g++ -E -x c++ - | any_tool_which_consumes_C++_text

I hereby make the assumption that any_tool_which_consumes_C++_text
designed to support "code completion or edit-time error detections
mechanism" must have symbol filtering at least as good as etags or it
deserves to lose in the market...

Regards,
Loren