Related articles |
---|
Automatic header generation for C++ thp@cs.ucr.edu (2002-03-11) |
Re: Automatic header generation for C++ michael_spencer@btclick.com (Michael Spencer) (2002-03-17) |
From: | Michael Spencer <michael_spencer@btclick.com> |
Newsgroups: | comp.compilers |
Date: | 17 Mar 2002 22:10:09 -0500 |
Organization: | Compilers Central |
References: | 02-03-062 |
Keywords: | C++, tools |
Posted-Date: | 17 Mar 2002 22:10:09 EST |
thp@cs.ucr.edu wrote:
> I'm interested in obtaining a tool that takes a C++ source file
> (.cc-files) and generates the corresponding header file (.h-file)
> including:
>
> - all #include directives from the .cc-file.
> - all function prototypes from the .cc-file.
> - the prototype of each function defined in the .cc-file.
> - all extern declarations from the .cc-file.
> - an extern declaration for each data item defined in the .cc-file.
> - all typedef's from the .cc-file
> - all declarations of struct or class types in the .cc-file
> - whatever else the .h-file ought to have.
>
> In addition it would have to have code to adjust the line numbers to
> correspond to those of widget.cc, so that if there were an error in
> compiling the .h-file, the programmer could edit the corresponding
> line of the .cc-file.
lzz (http://www.lazycplusplus.com) does something very similar. In
lzz you write your component in one file. Lzz reads this file and
puts things where they belong (according to generally accepted
guidelines).
It does not however recognize #include directives (or other
preprocessing directives) outside of function bodies. You must
explicitly indicate where the directives go:
$hdr
#include "A.h"
$end
$src
#define BAR FOO
$end
Do you really want all your #include directives to go in the header
file?
If you choose, Lzz will output inline definitions to a .inl-file,
template definitions to a .tpl-file, and inline template definitions
to a .tnl-file. You'd use a .tpl-file if you prefer to explicitly
instantiate your templates. (All the extensions can be changed.)
The biggest drawback for some people is the lack of macro support.
Lzz does not recognize macros (except in one special case) outside of
expressions and function bodies, unless the code is still recognizable
as C++. I find this to be an advantage: I do not need to dig through
header files to understand the syntax of the code I'm looking at (I
know I'm part of the minority here :).
Lzz can save you lots of time: you will never forget to edit a header
file after modifying a source file. I just can't happen. You'll also
write safer code. For example, using directives are output to the
source file. And the header file has to be self contained or the
source file won't compile.
Lzz uses a (minimum state, context-aware) backtracking LR(1) parser
generator. It is available at http://www.lazycplusplus.com/basil.
Mike
Return to the
comp.compilers page.
Search the
comp.compilers archives again.