On Thu, Jan 13, 2011 at 2:41 PM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 13 January 2011 11:09, Achilleas Margaritis wrote:
>> On Wed, Jan 12, 2011 at 6:16 PM, David Brown <da...@westcontrol.com> wrote:
>>>
>>> I can see how such a feature could be useful, but is there any reason why it
>>> should be part of gcc, rather than a separate program that takes a cpp file
>>> and generates an hpp file? Such a program would be much easier to develop
>>> and maintain than a new gcc pragma, and more flexible (for example, it could
>>> be used with other compilers). Your timestamp checking features are easily
>>> accomplished with make.
>
> A makefile is a better place to do it than in the compiler, as well as
> the reasons David gave, a separate tool invoked by make allows
> project-specific filename conventions. Otherwise, if it was done by
> the compiler, should it consider any of foo.cpp, foo.cp, foo.cxx,
> foo.cc, foo.C etc. as a valid source for foo.hpp? Or are only
> certain transformations allowed e.g. .cpp -> .hpp, .cc -> .hh, .cxx ->
> .hxx (?)
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")
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 also don't need any special pragma, just list foo.hpp as a
> dependency and define a rule for generating foo.hpp from foo.cpp
>
> main.o: foo.hpp
>
> foo.hpp: foo.cpp
> cpp2hpp $^ -o $@
>
> That would work, and the code would be 100% valid C++ without a
> non-portable pragma.
The pragma can be ignored by other compilers. Conditional compilation
would help in including the header for other compilers.
>
>> The GCC contains all the necessary code for parsing C++. An external
>> program would have to use a custom parser (which is a lot of work,
>> since C++ is a very complex language), or LLVM (which may or may not
>> be 100% compatible with GCC yet, and which may or may not contain all
>> the GCC features). Doing it from within GCC guarantees code reuse and
>> consistency with the compiler, plus compatibility with the new c++
>> standard, which GCC already largely implements.
>
> The tool doesn't need to fully parse C++, it only needs to recognise a
> definition and produce a declaration for it,
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.
>
>> Furthermore, the compiler would need to handle the clash of
>> declarations between the generated header and the implementation file.
>> As any compiler is implemented right now, declaring the same class
>> twice will generate an error.
>
> That would only be a problem if foo.cpp includes foo.hpp, but why
> would it do that if foo.hpp is generated?
If foo.cpp does not include foo.hpp, then the definitions in foo.cpp
would not be recognized by the compiler.
>
>> Additionally, providing such a functionality through GCC would not
>> have the maintenance overhead of an externally managed application:
>> once GCC is updated to a version with this functionality, this
>> functionality would become instantly available.
>>
>> Finally, GCC is one of the most visible projects when it comes to c++
>> compilers. If GCC had such a functionality, I think that many people
>> would jump to the opportunity to use this functionality, and therefore
>> it could be part of the language standard in the far future.
>
> I seriously doubt that. The modules proposal Ian referred to is far
> more likely to become part of the standard.
I don't see the modules proposal happening in this decade. It took 13
years to update the C++ standard. My gut feeling is that it would be
after 2020 that we are going to see working implementations of a
module system.
>
> However, if you think this feature would be useful you are free to
> implement it, or pay someone else to do so - that's the beauty of Free
> Software.
>
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).
