Re: Proposal for automatic generation of c++ header files

[Achilleas Margaritis <axilmar at gmail dot com>]

>> There is a solution to that: the compiler, knowing that foo::bar is
>> not an inline function, it does not inline the function but it
>> automatically compiles the relevant symbol in the foo.o object file.
>
> Which is a change to the language semantics!

The compiler can inline the trivial member functions and leave the
rest as is. Although technically it is a change in language semantics,
it's a very minor change, that I doubt will have anyone worried.

Look at the benefit of not having to create headers though...for me,
it's a good trade off.

> A change to how the compiler processes the source code is a change to
> the language. ?The rules on template instantiation, inline functions,
> symbol visibility, inline namespaces etc. would probably all be
> affected.

I do not see how anything else other than inlining is to be affected.

Care to show an example?

>
> You also don't seem to have considered header dependencies. ?If
> foo.cpp #includes ten files, some of which are needed for the
> interface and some for the implementation, how many of them should be
> copied to foo.hpp by your "simple" copy'n'paste? ?Should the compiler
> analyse which headers are needed just for the interface declarations,
> and only include those headers? ?Or auto-generate forward-declarations
> of all the needed entities?
> Or just include all of them, even though some headers may only be
> needed for the implementations, resulting in namespace pollution in
> other translation units and possible ambiguities, conflicts, or
> dependency cycles?

All of them.

I'll take automatic generation of headers + increased compilation
times any day over manual generation of headers. New computers and
hard disks can always be purchased and are much cheaper than people.

If I encountered a problem with dependency cycles, then I would use
the old way of manually writing headers, which will still be
available.