On 13 January 2011 13:06, Achilleas Margaritis wrote:
> 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")
You said that will cause it to look for foo.cpp, so there must be a
transformation from "foo.hpp" to "foo.cpp", no?
> 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 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.
Except the header wouldn't exist if you use other compilers, because
you need gcc to generate it.
If you need gcc around in order to generate the header for other
compilers, then it's effectively a separate tool (let's call it
cpp2hpp) and doesn't need to be part of gcc.
>>> 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.
GCC would not get it 100% either, you'd be better using a stricter
parser such as EDG.
>>> 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.
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.
If you are trying to convince someone to implement your idea you
should make sure you have a clear proposal in mind.
>>> 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).
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)
