Automatic generation of header file.

[Kannan Goundan]

Maintaining a C++ header file can be painful. I want a way to
automatically generate header files from the implementation file. Does
anybody know of a program that does this?

If not, I'd like to try writing one. The input file would consist of
function definitions and class definitions (with all methods defined
inline). The program would extract all the signatures and place them in a
header file. I can see some small problems related to namespaces and
includes, but are there any show-stoppers?

- Kannan

 

[Victor Bazarov]

Maintaining a C++ header file can be painful. I want a way to
automatically generate header files from the implementation file.
Does anybody know of a program that does this?

If not, I'd like to try writing one. The input file would consist of
function definitions and class definitions (with all methods defined
inline). The program would extract all the signatures and place them
in a header file. I can see some small problems related to
namespaces and includes, but are there any show-stoppers?

Show-stoppers I ain't sure of, but consider if your class needs to have
a base class or two. How is that going to be automatically generated?

V

 

[Matthias Kaeppler]

Show-stoppers I ain't sure of, but consider if your class needs to have
a base class or two. How is that going to be automatically generated?

V

Why? He can obtain its name from the ": public BC " part of the child
class definition (which can be found in the source file if I got that
right).
You could then (given that the filenames are identical to the class
names) produce an include directive in the generated header which
includes the base class definition (#include BC.hpp).

 

[Joe Seigh]

Maintaining a C++ header file can be painful. I want a way to
automatically generate header files from the implementation file. Does
anybody know of a program that does this?

If not, I'd like to try writing one. The input file would consist of
function definitions and class definitions (with all methods defined
inline). The program would extract all the signatures and place them in a
header file. I can see some small problems related to namespaces and
includes, but are there any show-stoppers?

Being that the header file defines the api which is used by more than
just the implementation, I'd think you'd want it to not be easily
changed. Maybe you haven't been on the short end of an api change
often enough to appreciate that.

 

[EventHelix.com]

You can ease the pain of managing C++ by following
some rules that are covered in the following article:

http://www.eventhelix.com/RealtimeMantra/HeaderFileIncludePatterns.htm

Deepa

 

[Kannan Goundan]

Being that the header file defines the api which is used by more
than just the implementation, I'd think you'd want it to not be
easily changed. Maybe you haven't been on the short end of an
api change often enough to appreciate that.

There are a few reasons I don't like C++ header files:

1. The C++ header file also includes stuff that isn't part of an API
contract (private methods/fields, inline method implementations).

2. I should only have to worry about API compatibility for external
APIs. When I'm changing the implementation details of my classes, I
don't want to have to make every signature change in two places.

I want to be able to do things the way they are done in Java and C#.

 

[Andrew McDonagh]

There are a few reasons I don't like C++ header files:

1. The C++ header file also includes stuff that isn't part of an API
contract (private methods/fields, inline method implementations).

2. I should only have to worry about API compatibility for external
APIs. When I'm changing the implementation details of my classes, I
don't want to have to make every signature change in two places.

I want to be able to do things the way they are done in Java and C#.

You can do this in C++ as you can in Java.

In Java we have classes and interfaces. When these are used as part of a
public API, everything they contain is viewable by the end user. Its
the same with C++ header files.

However, the external public API is just that, its an Application
Programming INTERFACE.

What we do in Java, is define a series of Interfaces which are our
public API, no concrete classes should be exposed. We do the same in
C++, we use Pure Abstract Classes (which are mere header files) as our
public API and again no concrete C++ class should be exposed.

 

[Kannan Goundan]

Show-stoppers I ain't sure of, but consider if your class needs to
have a base class or two. How is that going to be automatically
generated?

Why? He can obtain its name from the ": public BC " part of the
child class definition (which can be found in the source file if I
got that right).
You could then (given that the filenames are identical to the class
names) produce an include directive in the generated header which
includes the base class definition (#include BC.hpp).

I was planning on allowing an optional "public" modifier to cover that
case.

#include "Base.h" @public
#include "Helper.h"
struct PointerOnly; @public

Includes and forward declarations marked "@public" would be put in the
header file, others would be put in the CPP file. This would, I think,
allow for most of the flexibility you'd have if you were writing the
header and CPP files by hand.

However, I've also been considering providing more automation (such as
the one Matthias described) for those who are willing to follow certain
naming/coding conventions.

 

[Kannan Goundan]

Kannan Goundan wrote:
[snip]

You can do this in C++ as you can in Java.

In Java we have classes and interfaces. When these are used as
part of a public API, everything they contain is viewable by
the end user. Its the same with C++ header files.

However, the external public API is just that, its an
Application Programming INTERFACE.

What we do in Java, is define a series of Interfaces which are
our public API, no concrete classes should be exposed. We do
the same in C++, we use Pure Abstract Classes (which are mere
header files) as our public API and again no concrete C++ class
should be exposed.

The problem I was trying to solve is the one of having to maintain C++
header files. I want a program to generate my header files for me.
That's what I meant when I said I wanted something like Java.

About only exposing pure abstract classes... I'm not convinced that all
libraries can withstand such a limitation. First of all, there's the
performance hit virtual calls. Second, all objects will have to be
heap allocated. You'll have to use some wrapper class to get RAII.
Third, you can't inherit from a class in the library. You'd have to
roll your own fake adaptor-like inheritance technique. This will be
slower because of the extra indirection and will punish the heap by
creating two objects for every instance of the base class.

This may be acceptable for many libraries (large objects, relatively
few app->library calls), but definitely not for all. BTW, I use the
term API for any library interface. If you use it to describe only a
certain category of libraries then my objections may not apply.

 

[Hang Dog]

There are a few reasons I don't like C++ header files:

1. The C++ header file also includes stuff that isn't part of an API
contract (private methods/fields, inline method implementations).

You don't have to put any private methods or fields in the header files,
nor do you have to write inline methods either.

I want to be able to do things the way they are done in Java and C#.

The main problem you'll encounter is the compile-the-world syndrome
unless you are very careful about not recreating the headers unless
absolutely necessary.

 

[E. Robert Tisdale]

Maintaining a C++ header file can be painful.
I want a way
to automatically generate header files from the implementation file.

Like Fortran 90/95.

Does anybody know of a program that does this?

I used Google

http://www.google.com/

to search for

+"automatic header file generation"

and I found lots of stuff including:

Automatic Header File Generation by Cay S. Horstmann

http://profesores.elo.utfsm.cl/~agv/elo329/Java/horstmann/mdgen/MDGEN.TXT

If not, I'd like to try writing one.
The input file would consist of function and class definitions
(with all methods defined inline).
The program would extract all the signatures
and place them in a header file.
I can see some small problems related to namespaces and includes,
but are there any show-stoppers?

All that is meant by the term "header file"
is that it is included near the top [head]
of a source file or another header file.
Apparently, you want a utility to generate a *module* interface
from a *module* implementation.

You should investigate languages such as modula-2

http://www.modula2.org/

or even Fortran 90/95.
Don't allow yourself to be confused
by the way that the term "interface" is used in Java.

Anyway, lots of C (and C++) programmers have been doing this for years
but it is "wrong headed" from a designer's point of view.
You should write the module interface *first*
then write the implementation to conform with the interface.

 

[Kannan Goundan]

You don't have to put any private methods or fields in the header files,
nor do you have to write inline methods either.

How can you get away without listing the private fields in a header file?
I thought that they were necessary to let others instantiate your class on
the stack.

The main problem you'll encounter is the compile-the-world syndrome
unless you are very careful about not recreating the headers unless
absolutely necessary.

Yeah... I think that can be solved by doing:

# autogen File.in File.cpp File.h.new
# if [ `diff File.h File.h.new | wc -l` -gt 0 ]; then
mv File.h.new File.h
fi

I've also got to figure out how to get GNU make to cooperate. I remember
there being some problem with these kinds of "maybe" dependencies.

 

[Hang Dog]

How can you get away without listing the private fields in a header file?
I thought that they were necessary to let others instantiate your class on
the stack.

Google "Cheshire Cat" + C++.

 

[Kannan Goundan]

Maintaining a C++ header file can be painful. I want a way to
automatically generate header files from the implementation file.

[snip]

Automatic Header File Generation by Cay S. Horstmann

http://profesores.elo.utfsm.cl/~agv/elo329/Java/horstmann/mdgen/MDGEN.TXT

This does let you keep everything in one file, but it forces you to
duplicate things in the same ways (which I'd rather not have to do).

If not, I'd like to try writing one. The input file would consist of
function and class definitions (with all methods defined inline).
The program would extract all the signatures and place them in a header
file. I can see some small problems related to namespaces and includes,
but are there any show-stoppers?

All that is meant by the term "header file" is that it is included near
the top [head] of a source file or another header file. Apparently, you
want a utility to generate a *module* interface from a *module*
implementation.

Ahh...yes. My terminology was imprecise. I want to take a class
implementation and generate a class header. The input would be of the
form:

class MyClass {
public:
MyClass(int x) {
this->x = x;
}
void Run() {
cout << "Run " << x << endl;
}
inline void Set(int x)
{
this->x = x;
}
private:
int x;
}

Only the parts required in the class header file would be copied there.
The type signatures for "MyClass()", "Run()", and "x" and the
implementation for "Set()", because it is marked "inline".

You should investigate languages such as modula-2

http://www.modula2.org/

or even Fortran 90/95.
Don't allow yourself to be confused
by the way that the term "interface" is used in Java.

Anyway, lots of C (and C++) programmers have been doing this for years
but it is "wrong headed" from a designer's point of view. You should
write the module interface *first* then write the implementation to
conform with the interface.

Though I feel that there are cases where a separate interface file for
each class is too much, C++ requires even more than that. As far as I
know, you must also list all the private fields and methods in the header
file. This is what annoys me the most because I have to muck around in two
files when some implementation detail changes.

 

[Kannan Goundan]

Kannan Goundan wrote: [snip]

How can you get away without listing the private fields in a header
file? I thought that they were necessary to let others instantiate your
class on the stack.

Google "Cheshire Cat" + C++.

But this doesn't let you keep things on the stack, right? As far as I
can tell, the implementation class will still be instantiated with "new".

 

[Hang Dog]

Kannan Goundan wrote:
[snip]

How can you get away without listing the private fields in a header
file? I thought that they were necessary to let others instantiate your
class on the stack.

Google "Cheshire Cat" + C++.

But this doesn't let you keep things on the stack, right? As far as I
can tell, the implementation class will still be instantiated with "new".

Your original post simply whined about having to have everything in the
header file. Its not necessary, and in many cases undesireable too.