Re: Proposal for automatic generation of c++ header files
On Thu, Jan 13, 2011 at 9:53 PM, Ian Lance Taylor i...@google.com wrote: Achilleas Margaritis axil...@gmail.com writes: How much do you spend in maintaining headers? answers welcomed from other members as well. In C++, I personally spend very little time doing what I would describe as maintaining headers. I write class definitions in .h files and function implementations in .cc files. The only data which appears in both places is the function signature. Yes, it would be slightly nice if I didn't have to write that twice. But it's a minor issue. Don't you ever had to modify the classes after you've written them? I am surprised, because I have talked to other developers and they have too said that it would be nice if headers could be avoided. Of course these days I mostly work on Go, which doesn't have this issue at all, because the language implements something along the lines of the C++ modules proposal. Which I think is the right way to go. Don't get confused by the language standardization process here; your proposal is also a change to the language. The pace of the standardization process is independent of whether gcc should implement a language change. The important point is that in order to implement what you want, the question is not whether to change the language, it is how to change it. And how it should be changed is the way that works best for most people, which need not be the way that most nearly replicates the way the language currently works. Ian I do think that the modules proposal is the way to go, but I don't see that happening soon. I may have retired when the modules proposal is usable :-). My proposal does not change the language in any way, it only is a copy-and-paste job.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 3:35 PM, Robert Dewar de...@adacore.com wrote: Ian Lance Taylor i...@google.com wrote: In C++, I personally spend very little time doing what I would describe as maintaining headers. I write class definitions in .h files and function implementations in .cc files. The only data which appears in both places is the function signature. Yes, it would be slightly nice if I didn't have to write that twice. But it's a minor issue. Interesting, as an Ada person, I actually LIKE the idea of writing the signature in both places. The Ada view here is that it serves very different purposes, in the header, it is part of the specification, and in the implementation it is there for easy access to anyone reading the implementation, and is a reminder that the implementation must conform to this spec. I think it helps readability to have it in both places (with of course the compiler checking that it is the same). Its a slight pain for the writer, but in Ada we never care even a little bit about the convenience of the writer over the convenience of the reader, and of course appropriate tools could simplify the duplication. Don't you ever had to modify the classes after you've written them? I am surprised, because I have talked to other developers and they have too said that it would be nice if headers could be avoided. Again, I like using headers in this way, I think it clarifies the structure of the program. As I say, I am influenced by Ada. It is always interesting to see the range of possible views of C headers from a) annoying junk required by the compiler, spend the least possible time messing with them, and certainly don't bother commenting them. to b) headers function like package specifications in Ada, and should be regarded as specifications and fully commented accordingly. If you follow path b) you end up with C or C++ code that has quite an Ada-like feel with regard to separation of spec and implementation. I've heard this argument in other places that headers serve as specification, aiding in readability and conformance. I strongly disagree, for the following reasons: 1) conformance is checked by the compiler. There is no need for the programmer to check the conformance of the implementation to the specification. If it compiles without errors, the implementation is ok. 2) the actual knowledge about the program stored in a header is, from my rough estimation, up around 20% of what the program actually does. In order to incorporate the actual knowledge required, a lot of documentation has to be written. I comment my code with docified comments heavily in order to document every little detail of my program. This knowledge can never be deduced by the headers. The docified comments result in a nicely formatted documentation which is actually much easier to read than code in headers. So, if the compiler checks the code, and the documentation says whatever must be said about the program, headers are completely redundant.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:09 PM, Robert Dewar de...@adacore.com wrote: On 1/14/2011 8:47 AM, Achilleas Margaritis wrote: 2) the actual knowledge about the program stored in a header is, from my rough estimation, up around 20% of what the program actually does. In order to incorporate the actual knowledge required, a lot of documentation has to be written. I comment my code with docified comments heavily in order to document every little detail of my program. This knowledge can never be deduced by the headers. The docified comments result in a nicely formatted documentation which is actually much easier to read than code in headers. The task of documenting specifications (what needs to be known by clients) is radically different from documenting implementations (what needs to be known by people fiddling with the implementation, the client should NEVER need to look at the implementation, and implementation details are not only irrelevant to the client, but it is evil for the client to depend on them). I never said anything about documenting the implementation. I am talking about documentation about the 'client' (I assume that you mean the programmers that will use a library or the programmers that will inherit the codebase). Documenting the implementation is done through comments in the implementation. It's totally irrelevant. I am talking about documenting the way an API is supposed to be used. That's the Ada philosophy in a nutshell, for Ada people, it is the single most important feature of the language that it encourages and to some extent mandates separation of spec and implementation (I say to some extent, because I have seen C folk writing Ada who regard the Ada specs as nuisance headers and don't document them at all, which is a horrible sin from an Ada perspective). So, if the compiler checks the code, and the documentation says whatever must be said about the program, headers are completely redundant. But then you don't have proper documentation of the specification. Yes, you have: you run Doxygen (or your favorite doc extraction program) and you get nicely formatted and searchable HTML.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:14 PM, Robert Dewar de...@adacore.com wrote: I guess I would just summarize things as follows. You can possibly generate headers automatically (just as you could generate subprogram specifications in Ada automatically). No one would ever think of suggesting doing this automatically in Ada. Why not? Because you might be able to generate the syntax of the specs, but you can never extract the specification from the implementation. That's because by its nature the implementation over-specifies. For example, if you have a sort package, the spec may simply require sorting, but not stable sorting. The implementation may happen to use an algorithm that happens to be stable. But if you have only the implementation you won't be able to tell if the stabilitiy is part of the specification. Then if you find later that you could speed things up hugely by abandoning the stability, you won't know if clients are legitimately depending on this or not. So from my narrow Ada perspective, I don't like any suggestion of automatic generation of c++ header files, but on the other hand, I understand that there are lots of people who have view a of headers (nuisance required by the compiler), and for such people it may ease writing to have such automatic generation. As I said before I never care at all about ease of writing code, compared to ease of reading it (and in the case of library packages, clients are readers). There is nothing that prevents the specification code to be in the same file as the implementation code, other than the will of the language author. All newer languages don't have header files...
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:55 PM, Robert Dewar de...@adacore.com wrote: On 1/14/2011 9:23 AM, Achilleas Margaritis wrote: All newer languages don't have header files... And to me, it is a serious flaw :-) One of several, e.g. in Java. Actually, it is not a flaw, it is a blessing :-).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely jwakely@gmail.com wrote: On 14 January 2011 13:26, Achilleas Margaritis wrote: My proposal does not change the language in any way, it only is a copy-and-paste job. That's not true, your example with an inline member function demonstrates that the compiler must be changed to support your proposal, so that functions defined inline are given a non-inline definition that can be linked to by other translation units. If it was a copy'n'paste job, it could be done by an external tool, which you've disputed. My proposal doesn't change anything of the language from the programmer's perspective. The #autoinclude pragma can select to inline only those member functions that are good candidates for inlining. I.e. it can inline trivial code. I believe the GCC code already contains such criteria, like any other good compiler. Anyway, you don't seem to be convincing anyone of your proposal, but if you want to see it in gcc you are free to download and modify the source, or pay someone else to do it for you. There is a lot of resistance to this idea, I admit; but I haven't seen any concrete argument about why my proposal is not good. It seems the resistance comes in two flavors: 1) It is not interesting work for me, so you do it or pay someone else to do it (you seem to be into that camp). 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). Hey, at least I tried :-).
Re: Proposal for automatic generation of c++ header files
1) It is not interesting work for me, so you do it or pay someone else to do it (you seem to be into that camp). That's always an appropriate response! The remedy is to propose a patch yourself (or pay someone to do it), then we can see if it makes sense when the details are worked out. Is it? I don't think so. If you don't care, don't respond. Don't come up with excuses like 'it cannot be done' or 'no one cares about that'. Anyway, enough politics. If one does not care about this proposal, you don't have to respond. And proposing a patch myself is not a realistic solution. It can take many months for me to get acquainted with the GCC codebase.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 5:29 PM, Axel Freyn axel-fr...@gmx.de wrote:
On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 14 January 2011 13:26, Achilleas Margaritis wrote:
My proposal does not change the language in any way, it only is a
copy-and-paste job.
That's not true, your example with an inline member function
demonstrates that the compiler must be changed to support your
proposal, so that functions defined inline are given a non-inline
definition that can be linked to by other translation units.
If it was a copy'n'paste job, it could be done by an external tool,
which you've disputed.
My proposal doesn't change anything of the language from the
programmer's perspective.
I think the point Jonathan wanted to make is the following: your
original example does not compile -- and can not compile without a
change of the language. If you create by hand the auto-include file you
proposed:
main.cpp:
#include foo.hpp
int main() {
Foo *foo = new Foo;
foo-bar();
foos.push_back(foo);
}
foo.cpp:
#include list
class Foo {
public:
void bar() {}
};
std::listFoo * foos;
static int data = 0;
foo.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include list
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
There is a violation of the C++-standard:
- when main.cpp is compiled, the compiler reads foo.hpp -- and it
learns that the class Foo has a member-function bar which can be
call from within main.cpp -- so main.cpp is compiled without problem.
- when foo.cpp is compiled, the compiler does not read foo.hpp and
thus it sees that the function bar is defined INLINE. So the
compiler will NOT export Foo::bar() -- it will be impossible to
link to Foo::bar() from another compilation unit.
- finally, you try to link both compilation units. Result: main() tries
to call a function Foo::bar() -- but that does not exist ==
compilation error.
On my machine, I get exactly that:
g++ main.cpp foo.cpp
/tmp/ccszFpug.o: In function `main':
main.cpp:(.text+0x27): undefined reference to `Foo::bar()'
collect2: ld returned 1 exit status
So in fact you have to change the language, I believe (at least it is
necessary to remove the rule if a member function is defined inline in
a class, it is marked as inline and NOT exported). But may be there
are also other problems?
HTH,
Axel
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.
The trick is to let the compiler know that foo::bar is not an inline
function. The information that foo::bar is not an inline function is
contained in the header, as I've shown:
foo.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include list
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
So, if the compiler was informed about foo::bar not being inlined, it
could then produce the appropriate symbol. This could happen if the
autogenerated header is automatically included when the implementation
file that produced the autogenerated header is compiled.
The compiler could check if there is an autogenerated header in the
same folder as the implementation file; if there is, then it is
included automatically in the implementation file.
Then the compiler manages the clash of symbols as needed.
From the programmer's language perspective, it is not a change in the language.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 5:59 PM, Paul Koning paul_kon...@dell.com wrote: ... 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). I think that's a matter of opinion, and language-specific as well. I disagree that it is 'a matter of opinion'. It is not. The concepts we are discussing are specific and concrete, they are not abstract. We are not talking religion or morality. It's not a philosophical subject. C is such a loose language that applying the notion of specification is hard. Ada is quite another story. From what little I know of it, I would go along with the Ada experts' comments. Just like any other language, Ada has declarations and definitions. The Ada people call their headers 'specifications', because a lot of program specifications are placed in those headers. But they are not specifications in a sense that you can have multiple implementations of them. I.e. there is a 1-to-1 correspondence between Ada package declarations and package bodies. Feel free to correct me if I am mistaken. And as an implementer of large C/C++ based embedded systems, I tend to the view that, while some programmers don't think of headers as specifications, they should, and doing so is helpful to achieving high quality. paul How do headers thought of specifications are helpful in achieving high quality? please give us a concrete example of a case that not having the headers provides less quality.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:07 PM, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote: And as an implementer of large C/C++ based embedded systems, I tend to the view that, while some programmers don't think of headers as specifications, they should, and doing so is helpful to achieving high quality. Back many years ago when I was doing VLSI design, there was one large CAD system written in C (I forget which one now) that had extensive documentation in their header files. I think that was a major part of the quality of that tool. The same documentation can be put in the implementation file. The Qt source code contains all the documentation in the implementation files (for a good reason: headers are parsed again and again).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote: The Ada people call their headers 'specifications', because a lot of program specifications are placed in those headers. But they are not specifications in a sense that you can have multiple implementations of them. I.e. there is a 1-to-1 correspondence between Ada package declarations and package bodies. Feel free to correct me if I am mistaken. You are mistaken. ;-) I am not mistaken. For a single Ada program that compiles successfully, there is 1-to-1 correspondence of a package declaration and package body. It's not uncommon to have multiple different implementations of the same specification, for example for different target architectures or one might be production and the other development. That's what conditional compilation, modules and build systems are for.
Re: Proposal for automatic generation of c++ header files
There you are definitely wrong. Of course headers are specifications, they specify the parameter types etc. Headers contain specifications, I agree to that. However: 1) headers could contain anything, at least in C/C++. 2) said specifications can be part of a single file of code; there is no need to split it in too. Now the question is whether to go beyond that (after all that's all the Ada syntax really does itself) and regard them as the proper repository of all the information that is part of the specification. That *is* a matter of taste and viewpoint. I am not saying that separating specifications from implementations is wrong. There is a use case for that. What I am saying is that the artificial separation of code into header and implementation files hurts productivity. **A lot**. The same result (coding against specifications) can be achieved without the separation of headers and implementation files OR without the duplication of work. You are free to disagree with that as a desirable approach, but it is indeed a matter, not of religeon or morality (truly weird references in this discussion) but of desirable viewpoint. And you saying categorically that they aren't does not help the discussion. Ok. The proper viewpoint to take here to support the idea of automatic generation is to recognize that there is a legitimate difference of opinion, but that there are lots of people whose opinion (not statement of fact) matches yours, that headers should not be regarded as specifications, and therefore it is useful to generate them automatically. I think if you take the attitude that everyone has to agree with your viewpoint, you will have even less success than you already have in pushing this idea. Let's stay clear of politics. Please. I am not interested. I have a job to do and many headers to create :-). There are two issues here really 1. How do we deal with the language distortion that your proposal causes. this seems a significant problem to me, and I have not really seen you address it. I have already explained it, but I don't mind explaining it once more: 1) the pragma #autoinclude (foo.hpp, foo.cpp) instructs the compiler to generate the header 'foo.hpp' from the implementation file 'foo.cpp'. 2) the compiler opens the file 'foo.cpp'. 3) for every class found in the file 'foo.cpp', a relevant class is placed into the header. 4) for every member function that is not a candidate for inlining, the compiler puts a function declaration in the header. 5) for every member function that is a good candidate for inlining, the compiler puts the definition the header. 6) for every non-static variable in the implementation file, it puts an 'extern' declaration in the header. 7) for every non-static standalone function in the implementation file, it puts the relevant function declaration in the header. 8) for every namespace in the implementation file, the relevant namespace is put in the header file. 9) when the compiler compiles foo.cpp, it checks if there is a relevant autogenerated header in the same place. If there is not one, then it proceeds to compile the implementation file as usual. If there is an autogenerated header: 10) if a class in the implementation file is part of the header, then: 11) if a member function has only a declaration in the header, then the function body is retrieved from the implementation file and the function is compiled as if it was defined outside of the class. 12) otherwise, the header definition is used. This is completely wrong, it is quite normal to have specifications in Ada with multiple bodies, e.g. for different targets, then you select the body you want to use. This is one of the advantages of this approach. For example, this approach is used extensively in the GNAT Ada run time. Does this happen at run-time? I don't think so. How do headers thought of specifications are helpful in achieving high quality? please give us a concrete example of a case that not having the headers provides less quality. You can definitely answer this question yourself, I don't think you can expect anyone to give you a long tutorial on why this separation is desirable. A lot has been written on this subject, and there are lots of programs to use as examples. Links? I am asking this because in most of the links I have found, people wish that headers did not exist. The only legitimate case is that of multiple compilation targets, and it is not something that cannot be handled with conditional compilation and a nice module system. And I am not exactly proposing banning headers already :-).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:22 PM, Robert Dewar de...@adacore.com wrote: On 1/14/2011 11:10 AM, Achilleas Margaritis wrote: The same documentation can be put in the implementation file. Yes, if you have formal conventions for documentation you can achieve the separation (as is done in well-written Java programs), but it is so much easier to do if you have separate specs, There is a lot more to documentation beyond 'specs'. Surely you are not claiming that parsing comments in header files takes a significant amount of time, if so, that's a patently incorrect claim, which you cannot back up with quantitative data since it is false (how do I know it is false, we DO have such data for Ada, from early on when we wondered whether to bother with it, and that was with machines of the speed of 20 years ago, and the answer was no then, and is even more definitely no now). Oh yes it does. Have you seen a Qt source code file? we are talking about some comments being many pages long. Multiply that with multiple inclusions of the same header, add lots of files, and you get the idea.
Re: Proposal for automatic generation of c++ header files
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.
Re: Proposal for automatic generation of c++ header files
the compiler non-conforming makes it a non-starter. This would have to be done under some switch. The switch idea is fine by me, although not necessarily required, since it can be implicit anyway (it's like saying to the end-users: hey, you don't have all the functions inline with #autoinclude as in headers, but this may increase your productivity).
Re: Proposal for automatic generation of c++ header files
On Wed, Jan 12, 2011 at 6:16 PM, David Brown da...@westcontrol.com wrote:
On 12/01/2011 16:22, Achilleas Margaritis wrote:
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds the pragma
#pragma autoinclude(foo.hpp)
it does the following:
1) searches the include path for the header foo.hpp.
2) if the header does not exist, then the compiler searches for the
file 'foo.cpp'
3) if the file 'foo.cpp' is found, then the header 'foo.hpp' is
generated automatically from the the .cpp file.
4) if the header exists, then the compiler compares the file dates of
the header and the implementation files. If the header is older than
the implementation file, then a new header is generated from the
implementation file.
When the compiler finds a declaration in a .cpp file that is 100% the
same as a declaration in a header file, then the declaration in the
implementation file is ignored, because it has been created
automatically in the header by the compiler. If there is a difference,
then an error is declared.
Example:
file main.cpp:
#pragma autoinclude (foo.hpp)
int main() {
Foo *foo = new Foo;
foo-bar();
foos.push_back(foo);
}
file foo.cpp:
#includelist
class Foo {
public:
void bar() {
}
};
std::listFoo * foos;
static int data = 0;
The compiler generates the following header:
#ifndef FOO_HPP
#define FOO_HPP
#includelist
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
If such a feature existed, it would greatly speed up application
development for c++ applications.
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.
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.
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.
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.
Re: Proposal for automatic generation of c++ header files
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).
Re: Proposal for automatic generation of c++ header files
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::listFoo * 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.
Re: Proposal for automatic generation of c++ header files
Why not? doesn't GCC contain all that is required for that parsing to
succeed?
GCC has bugs and doesn't parse everything 100% correctly, given the
complexity of the language.
Oh, ok then. But I think consistence is more important than
correctness in this case: the result header file should be as if it
was manually written, which means that whatever bugs GCC has when
parsing a file, these bugs should be reproducible from the generated
header.
My point was that your foo.cpp doesn't have an #include (or
#autoinclude) for foo.hpp, and doesn't need one either.
foo.cpp contains all the necessary declarations already - it MUST do,
or you couldn't generate foo.hpp!
So there's no need for foo.cpp to include foo.hpp (and doing so would
require the compiler to handle duplicate class definitions, which is
more implementation work, for no good reason.)
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.
That's because you've defined Foo::bar as inline but not used it in foo.o
The point though is to avoid writing things twice. For me, the
following is not acceptable:
class Foo {
public:
void bar();
};
void Foo::bar() {
}
If I have to do the above, I didn't gain anything by the
auto-generated headers. I still have to write things twice. The point
is to generate the header from this class definition:
class Foo {
public:
void bar() {
}
};
This is a detail which only a compiler can handle.
How much do you spend in maintaining headers? answers welcomed from
other members as well.
I don't see how it will save 40% of my time if I only have to edit one
file instead of two.
The change still has to be made *somewhere* and I spend more time
deciding what to change and testing it than I do dealing with
separating declarations from definitions.
The point is not mainly about editing one or two files, but about
avoiding writing (and maintaining) things twice.
Proposal for automatic generation of c++ header files
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds the pragma
#pragma autoinclude(foo.hpp)
it does the following:
1) searches the include path for the header foo.hpp.
2) if the header does not exist, then the compiler searches for the
file 'foo.cpp'
3) if the file 'foo.cpp' is found, then the header 'foo.hpp' is
generated automatically from the the .cpp file.
4) if the header exists, then the compiler compares the file dates of
the header and the implementation files. If the header is older than
the implementation file, then a new header is generated from the
implementation file.
When the compiler finds a declaration in a .cpp file that is 100% the
same as a declaration in a header file, then the declaration in the
implementation file is ignored, because it has been created
automatically in the header by the compiler. If there is a difference,
then an error is declared.
Example:
file main.cpp:
#pragma autoinclude (foo.hpp)
int main() {
Foo *foo = new Foo;
foo-bar();
foos.push_back(foo);
}
file foo.cpp:
#include list
class Foo {
public:
void bar() {
}
};
std::listFoo * foos;
static int data = 0;
The compiler generates the following header:
#ifndef FOO_HPP
#define FOO_HPP
#include list
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
If such a feature existed, it would greatly speed up application
development for c++ applications.
