>> A makefile will not work. I explain why below in the section about the
>> problem of clashing of symbols.
>>
>> There is no default transformation. The header's filename extension
>> will be defined in the include string name. For example:
>>
>> #pragma autoinclude("foo.hh")
>> #pragma autoinclude("foo.hpp")
>
> You said that will cause it to look for foo.cpp, so there must be a
> transformation from "foo.hpp" to "foo.cpp", no?
Indeed. The #pragma could be:
#pragma autoinclude("foo.hpp", "foo.cpp")
The second part may be optional.
The default would be to use a translation like the one you proposed
(hpp => cpp, hh => cc, hxx => cxx etc), which is used in most cases
anyway.
>> The pragma's purpose is not only to generate the file, but also to include
>> it.
>>
>> Furthermore, doing it externally with a tool means a huge amount of
>> work. Makefiles, project files, IDEs, scripts etc all would need to be
>> changed in order to accommodate the tool. If this is part of the
>> compiler, then no external tool modification would be required; only
>> source code modifications, which is much easier to do.
>
> You don't *have* to define rules in the makefile, you could just run
> the tool (called cpp2hpp in my example make rule) once and the headers
> exist. Which you need to do for other compilers anyway, see below ...
You have to define rules in the makefile, because the header files
would need to be regenerated each time the implementation file
changes.
If you don't define rules, then how it is going to work?
And then there are lots of other tools that won't work (IDEs for example).
>>
>> The pragma can be ignored by other compilers. Conditional compilation
>> would help in including the header for other compilers.
>
> Except the header wouldn't exist if you use other compilers, because
> you need gcc to generate it.
No, in other compilers you would have to provide the header manually.
The idea is this: if you use gcc, the headers may be generated for
you. If you don't use gcc, then you have to create the headers
yourself.
>> The declaration would be entangled with the definition, and the tool
>> would have to untangle them. It doesn't sound so easy to me.
>>
>> An external tool would have to duplicate a lot of code from GCC, and
>> it would possibly not get the result 100% correct, given the
>> complexity of the language.
>
> GCC would not get it 100% either, you'd be better using a stricter
> parser such as EDG.
Why not? doesn't GCC contain all that is required for that parsing to succeed?
>> If foo.cpp does not include foo.hpp, then the definitions in foo.cpp
>> would not be recognized by the compiler.
>
> Eh?
> Your OP said foo.cpp looked like:
>
> file foo.cpp:
>
> #include <list>
>
> class Foo {
> public:
> void bar() {
> }
> };
>
> std::list<Foo *> foos;
>
> static int data = 0;
>
> So it doesn't include foo.hpp and doesn't need to.
Can the GCC linker find the symbol Foo::bar() in the above code?
I did a test (with mingw), and the result is that if I don't define
Foo::bar() outside the class, then the linker doesn't find the
function.
The same thing happens with Microsoft's compiler.
> If you are trying to convince someone to implement your idea you
> should make sure you have a clear proposal in mind.
I think I did. If I haven't nail down every little detail, I
apologize, no one is perfect.
>> Do you think such a feature would not be useful? asking out of
>> curiosity. Personally, I would find it extremely useful. It would cut
>> down project development by almost 40% (estimation out of experience).
>
> I don't spend 40% of my development time putting declarations in
> separate files from definitions. I don't think it would be more
> useful than Vandevoorde's modules proposal, and I'd rather spend time
> on that (something I plan to do when the proposal is resurrected,
> post-C++0x)
>
How much do you spend in maintaining headers? answers welcomed from
other members as well.
