>> 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.
