• Dave (36/36) Nov 12 2005 With a start from dmdfe (http://home.comcast.net/~benhinkle/dmdfe/), it ...

Dave <Dave_member pathlink.com> writes:

With a start from dmdfe (http://home.comcast.net/~benhinkle/dmdfe/), it looks
feasible to create a header file generator using the reference compiler front
end. Here's what's been tried so far:

a) Emit legal source code for relavant declarations and definitions at any
nesting level (*).
b) Emit template declarations so they can be mixed with non template code in the
same module and also imported/used by other 'header' files (*).
c) Emit function bodies for 'inlinable' functions and methods (so the compiler
can inline from header file imports - important for things like math libraries).
d) Exclude private members if they are not referenced elsewhere (except in
template declarations where everything is emitted). However, this could cause
subtle and hard to find and fix bugs related to things like classinfo and member
offsets (and make the header generator quite a bit more complicated).
e) Exclude template declarations and/or template members not used (instantiated)
in the same module (excluding unused template members hasn't been tested but
looks possible).
f) Exclude all function bodies, private members and template declarations. This
would generate a header that is basically just a stub for the binary only.

I guess the features will come down to if the header files could be
used as both source code and 'stubs' for binaries, or for just stubs. For
example, for a large general purpose library like phobos or Ares, I think +a,
+b, +c, -d, -e, -f would be the feature set.

Or, would just option f) be what is expected, and full source code could be
shipped for things like math and template libraries?

The goal would be to create a general purpose header generator that would make
it very convenient to generate header files w/o adding a bunch of option
switches to the tool or compiler itself.

An assumption has been made that emitting source code for just 'inlineable'
(typically small and simple) functions would be acceptable even for proprietary
libraries. Is this a poor assumption?

Opinions?

Thanks,

- Dave

* An exception found so far is some typeid(...) because some build-in type
information is part of the "backend" and is not included in the compiler source
code.