Do header files really serve a useful purpose?

[Hattuari]

I'm learning C++ after having spent several years in the computer industry
doing both system administration and engineering. I've written code in
Perl, Bash, Pascal, Ada, C, Mathematica (hundreds of lines of OO code, not
1+1), JavaScript, Lisp, and Java, as well as C++. Each of these languages
has it's strengths and weaknesses. My experience with C++ has shown me
that it is by far the most difficult for me to learn.

I have the sense that some of the features in C++ are unnecessary, and
server little real purpose. None the less, they do serve to add to the
complexity, and hence the difficulty, of learning the language. I know
there is a good deal of excellent software written in the language.
Perhaps I'm not perceiving things accurately, but I have the sense that C++
is losing significant ground to other languages, expecially Java.

I'm not really sure why I'm motivated to follow this course, but I have a
real desire to determine what part of C++ could be extracted from the
entire body of the language, modified in certain ways, and still provide
virtually all the capabilities of the current language. Disregarding
Stroustrup's paraphrase of Shakespeare, I believe it might be fine sport to
basically put the language on trial. Perhaps such a thing has already been
done. I'm talking about a sicere critique, not an emotional attack.

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

For me, they are simply one more point of confusion when trying to remember
all the rules of declaring and defining programming constructs. These
rules are not, to my knowledge isolated to a compact, accessible reference.
I find myself flipping through several chapters trying to find the answer
to specific questions regarding parameter assigning defaults to optional
parameters, and the like.

So, now that I've said a lot of bad things about the language, let me
mention something I really like, though they are still new to me. Functors
are cool!

STH

 

[osmium]

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

For me, they are simply one more point of confusion when trying to remember
all the rules of declaring and defining programming constructs. These
rules are not, to my knowledge isolated to a compact, accessible reference.
I find myself flipping through several chapters trying to find the answer
to specific questions regarding parameter assigning defaults to optional
parameters, and the like.

There is less need for header files in C++ than there is/was for C, that is
certainly true. But they still have at least two vital functions.
Inclusion guards and producing customized versions of programs. For
example: a browser that comes in three flavors: crippled so it can't post
(for libraries), crippled in many other respects (for a free demo) and a
full bells and whistles browser.

 

[tom_usenet]

I'm learning C++ after having spent several years in the computer industry
doing both system administration and engineering. I've written code in
Perl, Bash, Pascal, Ada, C, Mathematica (hundreds of lines of OO code, not
1+1), JavaScript, Lisp, and Java, as well as C++. Each of these languages
has it's strengths and weaknesses. My experience with C++ has shown me
that it is by far the most difficult for me to learn.

Learning it completely is very hard. Learning enough to start writing
useful programs is quite easy (try Accelerated C++, by Koenig and
Moo).

I have the sense that some of the features in C++ are unnecessary, and
server little real purpose. None the less, they do serve to add to the
complexity, and hence the difficulty, of learning the language. I know
there is a good deal of excellent software written in the language.
Perhaps I'm not perceiving things accurately, but I have the sense that C++
is losing significant ground to other languages, expecially Java.

I think Java has lost a lot of ground recently - it had a huge boom a
few years ago but growth has stopped. C++ demand has surely but
steadily increased, as I understand it.

Searching for "Java" and "C++" in your favourite job search engine is
a good way to get a rough idea.

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

Header files (and the whole preprocessor) are an unfortunate
carry-over from C. In C they make more sense than in C++, since C
doesn't have the esoteric name lookup, overloading and template
instantiation of C++.

Some kind of code module/database system would be better, although I
think people would be loathe to give up the preprocessor, however much
it makes the job of continuous code analyzers (as used in modern Java
IDEs like Eclipse and IntelliJ IDEA) much harder to do efficiently.

For me, they are simply one more point of confusion when trying to remember
all the rules of declaring and defining programming constructs. These
rules are not, to my knowledge isolated to a compact, accessible reference.
I find myself flipping through several chapters trying to find the answer
to specific questions regarding parameter assigning defaults to optional
parameters, and the like.

You can always ask in here - answers usually only take minutes to
appear. Alternatively, learning your way around a particular reference
book (such as "The C++ Programming Language") can be helpful - it gets
easier to find what you're looking for.

Tom

 

[Marcin Kalicinski]

Hi,

I agree. When I want to use some specific C++ entity, I should tell name of
this entity, not name of some weird include file. For example:

Instead of:

#include <fstream>
// use std::ifstream

do, for example, this:

include std::ifstream;
// use std::ifstream;

Header files are ugly because they are not a part of the language - they
live in a completely different namespace, with different rules (which are
system dependent). They introduce another, unneccesary set of names and
rules to remember when programming. They are dangerous, because one seldom
knows what he exactly includes. Especially when using less-standarized
libraries than STL is.

They should never be banned (as macros were not), but they should not be a
foundation of whole C++ programming, as they are now.

Kind regards,
Marcin

Uzytkownik "Hattuari" <[email protected]> napisal w wiadomosci
I'm learning C++ after having spent several years in the computer industry
doing both system administration and engineering. I've written code in
Perl, Bash, Pascal, Ada, C, Mathematica (hundreds of lines of OO code, not
1+1), JavaScript, Lisp, and Java, as well as C++. Each of these languages
has it's strengths and weaknesses. My experience with C++ has shown me
that it is by far the most difficult for me to learn.

I have the sense that some of the features in C++ are unnecessary, and
server little real purpose. None the less, they do serve to add to the
complexity, and hence the difficulty, of learning the language. I know
there is a good deal of excellent software written in the language.
Perhaps I'm not perceiving things accurately, but I have the sense that C++
is losing significant ground to other languages, expecially Java.

I'm not really sure why I'm motivated to follow this course, but I have a
real desire to determine what part of C++ could be extracted from the
entire body of the language, modified in certain ways, and still provide
virtually all the capabilities of the current language. Disregarding
Stroustrup's paraphrase of Shakespeare, I believe it might be fine sport to
basically put the language on trial. Perhaps such a thing has already been
done. I'm talking about a sicere critique, not an emotional attack.

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

For me, they are simply one more point of confusion when trying to remember
all the rules of declaring and defining programming constructs. These
rules are not, to my knowledge isolated to a compact, accessible reference.
I find myself flipping through several chapters trying to find the answer
to specific questions regarding parameter assigning defaults to optional
parameters, and the like.

So, now that I've said a lot of bad things about the language, let me
mention something I really like, though they are still new to me. Functors
are cool!

STH

 

[Chris Mantoulidis]

Oh I sence a little flame

I'm learning C++ after having spent several years in the computer industry
doing both system administration and engineering. I've written code in
Perl, Bash, Pascal, Ada, C, Mathematica (hundreds of lines of OO code, not
1+1), JavaScript, Lisp, and Java, as well as C++.

You have learned Pascal, C and Java. Then how can you ask "what are
header files good for?"?

Pascal's synonym for "header file" is "unit". Java's synonym for
"header file" is something I can't remember atm (but you include it
in your code with import NAME). C's "header files" synonym is "header
files".

But you got a problem with C++'s header files? That's is really MORE
than weird.

Each of these languages
has it's strengths and weaknesses. My experience with C++ has shown me
that it is by far the most difficult for me to learn.

This depends on the person who is learning it. For me it's one of the
best langs out there and totally not difficult to learn.

I have the sense that some of the features in C++ are unnecessary, and
server little real purpose. None the less, they do serve to add to the
complexity, and hence the difficulty, of learning the language. I know
there is a good deal of excellent software written in the language.
Perhaps I'm not perceiving things accurately, but I have the sense that C++
is losing significant ground to other languages, expecially Java.

Well Java is platform independent ok that's a good characteristic I
must say. But Java (in _most_ [not all] cases) is really five times
slower than C++. Java is really good for networking stuff whereas C++
is good in many other sections.

I'm not really sure why I'm motivated to follow this course, but I have a
real desire to determine what part of C++ could be extracted from the
entire body of the language, modified in certain ways, and still provide
virtually all the capabilities of the current language. Disregarding
Stroustrup's paraphrase of Shakespeare, I believe it might be fine sport to
basically put the language on trial. Perhaps such a thing has already been
done. I'm talking about a sicere critique, not an emotional attack.

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

For me, they are simply one more point of confusion when trying to remember
all the rules of declaring and defining programming constructs. These
rules are not, to my knowledge isolated to a compact, accessible reference.
I find myself flipping through several chapters trying to find the answer
to specific questions regarding parameter assigning defaults to optional
parameters, and the like.

Then you haven't really understood header files. Let's say you write a
class and want to share it... What are you going to do? Put it in a
header file and give it to other ppl. Let's say you DON'T like this
example.

In C++ when you use a certain data type (that is not a native data
type), the compiler of course cannot know how it's been defined and
other details about this data type unless you specify WHERE this data
type definition is; that is the header file. Same goes for functions.

If there weren't header files, then you would have to write yourself
EVERY SINGLE thing you want to use in your program. The only solution
to that would be to let the compiler know of everything that can be
used by a C++ program. But that would make the executable really big
and the compilation time really big as well. Not to mention that you
would have to recompile your compiler every time you would want it to
have a new characteristic.

So, now that I've said a lot of bad things about the language, let me
mention something I really like, though they are still new to me. Functors
are cool!

STH

I wonder why you had such a question specifically about C++...

 

[Alf P. Steinbach]

I've written code in Perl, Bash, Pascal, Ada, C, Mathematica
(hundreds of lines of OO code, not 1+1), JavaScript, Lisp, and Java,
as well as C++.

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me.

So, now that I've said a lot of bad things about the language, let me
mention something I really like, though they are still new to me. Functors
are cool!

Idiot.

 

[Default User]

On Thu, 26 Feb 2004 06:49:03 -0500, Hattuari


You can always ask in here - answers usually only take minutes to
appear. Alternatively, learning your way around a particular reference
book (such as "The C++ Programming Language") can be helpful - it gets
easier to find what you're looking for.

After first checking the FAQ list, of course!



Brian Rodenborn

 

[Gary]

Oh I sence a little flame

Pascal's synonym for "header file" is "unit". Java's synonym for
"header file" is something I can't remember atm (but you include it
in your code with import NAME). C's "header files" synonym is "header
files".

Just a nit. Java has nothing like #include. The import statement is not the
Java equivalent of #include.

 

[PlasmaDragon]

Do you know a better way of including 1000s of lines of code in your
program w/o cutting and pasting and having that expressed in just one
line (instead of 1000s)?

 

[Michael Klatt]

So in that sense, I will ask what good header files really are. They seem
to be nothing but administrative overhead to me. I believe they encourage
programmers to avoid deviding their work into appropriately selfcontained
objects. The also seem to encourage programmers to avoid using namespaces.

I'm surprised you don't find header files useful if you're already
experienced in C. I think the semantics of header files are extremely
useful for OO programming; they are much more flexible than, for
example, Fortran's MODULE implementation. I have a C++ library that I
ported to Fortran 95. There are two classes (derived types in
Fortran) that are mutually dependent. In C++ it is easy to seperate
these into two different source files because I can seperate the
interfaces into header files:

// Portal.hpp
#include "Cursor.hpp"
class Portal
{
private :
std::set<Cursor*> m_cursors;
}

// Cursor.hpp
#include "Portal.hpp"
class Cursor
{
private :
Portal& m_portal;
}

In Fortran, MODULE interfaces are generated during compilation. In
order for the MODULE defining the Portal type to use the Cursor type,
the MODULE containing the Cursor type has to be compiled first.
However, the Cursor type uses the Portal type, so the Portal MODULE
has to be compiled first. The only way around this circular
dependency is to put all of the Portal and Cursor code into one huge
MODULE source file. Anything defined in a MODULE is accessible to
everything else in the MODULE. By putting my Cursor and Portal code
in the same MODULE I am exposing the implemenations and making it
easier to accidentally violate encapsulation. In this case, the
concept of header files greatly increases modularity.

 

[Razvan Popovici]

Hello,

You are right about headers files, it's an additional overhead for a
programmer, introduces redundancy in the source, but their need comes from
the history of C and C++.
My oppinion would be that the compile would need to generate automatically
those header files when compiling the cpp file, maybe embended to the obj
file. That's the way java works.
Of course this approach will need to change the language radically and
surely won't happen. It's just too much C++ code in the world to be ported.
On the other hand tools like Visual C++ allow you to keep an overview on
your source files and eliminate a part of redundant work.
Namespaces and headers are completly different concepts in C++, they don't
substitute each other.
If you hate header files, you can use Microsoft extensions of C++ an import
COM objects with #import directive. This will generate your header files
each compilation automatically. The disadvantage: it's very probable that
your program will only compile with a Microsoft compiler, and it will only
be able to run on Windows.

Regards,
Razvan

 

[Julie J.]

Header files (and in fact source! files) are a complete waste and 100% the
wrong way to write code.

File-based source is an artifact (unfortunately long-lasting) from the 50's and
60's, and was a step up from punch cards.

40+ years later, we are still using this IMMENSELY outdated mode of writing
code.

The truth of the matter is that there should be *NO* files, but code should be
just written in an editor, and stored in an abstract container (such as a
database). The (header) definition/declaration model is a holdover from the
ancient past of functional C.

Long compiles would be a thing of the past, immediate access to symbols, types,
functions, classe, etc. would be available in the editor. Everything could be
optimized for the compile/build, and could occur incrementally as code is
written and committed.

I'm amazed that new language after new language continues to use the bad old
plain old regular text file and the basis for code entry and maintenance. I
thought that IBM was working on some database-based model back in the early
90's, but I guess it never materialized.

Too bad -- writing code can be more of an exercise of managing files (and and
inclusions), than actually *writing* the code...