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]

Hattuari writes:

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]

On Thu, 26 Feb 2004 06:49:03 -0500, Hattuari
<su******@setidava.kushan.aa> wrote:

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
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[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" <su******@setidava.kushan.aa> napisal w wiadomosci
news:L6********************@speakeasy.net...
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 :P

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 :P (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]

* Hattuari <su******@setidava.kushan.aa> schriebt:

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.

[Gary]

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message
news:a8**************************@posting.google.c om...

Oh I sence a little flame :P <<snip>> Pascal's synonym for "header file" is "unit". Java's synonym for
"header file" is something I can't remember atm :P (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.
--
Gary

[Default User]

tom_usenet wrote:

On Thu, 26 Feb 2004 06:49:03 -0500, Hattuari
<su******@setidava.kushan.aa> wrote:

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.

After first checking the FAQ list, of course!

Brian Rodenborn

[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]

Hattuari <su******@setidava.kushan.aa> wrote in message news:<L6********************@speakeasy.net>...

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

"Hattuari" <su******@setidava.kushan.aa> schrieb im Newsbeitrag
news:L6********************@speakeasy.net...

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

[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...
Hattuari wrote:

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

[Gary]

"Julie J." <unlisted@.> wrote in message news:403E7A78.C0F60D24@....

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.

True, in many respects, but also adds the requirement that to do any editing
or compiling would require the action of a database engine.
Maybe not a bad thing since many of us use rather large IDE's for
development, but interchanging programs with other developers might become a
burden. Either they have to have the same engine or we have to export/import
all the time. Sending plain text cpp files still seems easier.

Look at all the export, scan, import, scan, intermediate files, and
interpreters needed to use the "modern" way of interchanging data: XML.
Would it be the same with database C++ system? Probably.
--
Gary

[Claudio Puviani]

"Julie J." <unlisted@.> wrote

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...

I, for one, would avoid a "language" that forced me to store my code in a
database that's hidden behind some GUI. Anyone who's worked with such tools as
Rational Rose or systems like Actor can tell you how frustratingly constraining
that approach can be.

Being able to manage the code as plain text files is a strength, once you're
used to it, not a weakness. You not only have access to hundreds of utilities to
do just about everything, but you get to choose which ones you want to use. With
database approach, you're stuck with whatever the compiler vendor provides. Even
if a common set of tools eventually surfaced, it would take years for such tools
to approach the versatility of things like Perl or your favorite
(non-database-enabled) editor, and even then, you'd only have limited
functionality.

As to the C++ model being obsolete, that may well fuel hours of theoretical
discussions, but the reality is that C++ does what it purports to do
spectacularly well and it's highly doubtful that many people would migrate from
C++ to some hypothetical pretty replacement just because it would satisfy some
abstract esthetics. There are already quite a few languages out there that "fix"
these esthetic irritants, yet I'm not seeing a mass exodus toward them.

No offense, but discussions of this nature rank right up there with "there
should be peace on earth", "every day should be a Saturday", and "William
Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure
flights of fancy.

Claudio Puviani

[Jorge Rivera]

I will top post, because I just got too many people anwering to this,
and I want to give YOU my answer.

Hattuari wrote:

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.
Try Prolog, Lisp, and COBOL (Ughhh)
Perhaps I'm not perceiving things accurately, but I have the sense that C++
is losing significant ground to other languages, expecially Java.
I don't mean to be rude, but who cares? C++ is a nice fit for certain
types of applications, Java for others, Prolog for others, etc....
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 don't understand why so many people are whining about header files. I
kinda like the fact that I can have just definitions of functions,
classes and namespaces, whith implementations in a different file.

My header files in general have no code in them. They are just the
inteface. It is nice when I can distribute my header files and binary
libraries, without exposing implementation details. Protects customers
from trying to "fix" code....

It can also help protect IP. Think about algorithms that you are trying
to protect. In Java, you have to go to great lenghts to mangle your code
before you compile it, so that decompilers will be rendered less useful,
whereas in C++, you can distribute binaries, allow people to use the
interfaces, all this without exposing any implementation details.

Just my opinion...

Jorge L.

[E. Robert Tisdale]

Hattuari wrote:

So in that sense, I will ask what good header files really are.

When properly constructed,
they serve the same purpose as modules
or module interfaces in other languages.

[Julie J.]

Interchanging would be a piece of cake -- there are plenty of methods out there
for centralized databases to a remote client.

Merges would go the way of the west as well...

Gary wrote:

"Julie J." <unlisted@.> wrote in message news:403E7A78.C0F60D24@....

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.

True, in many respects, but also adds the requirement that to do any editing
or compiling would require the action of a database engine.
Maybe not a bad thing since many of us use rather large IDE's for
development, but interchanging programs with other developers might become a
burden. Either they have to have the same engine or we have to export/import
all the time. Sending plain text cpp files still seems easier.

Look at all the export, scan, import, scan, intermediate files, and
interpreters needed to use the "modern" way of interchanging data: XML.
Would it be the same with database C++ system? Probably.
--
Gary

[Julie J.]

> No offense, but discussions of this nature rank right up there with "there

should be peace on earth", "every day should be a Saturday", and "William
Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure
flights of fancy.
Says you.

I'm sure that the punch-carders felt the same way that you do about new-fangled
text files. You are entitled to your opinion, but that doesn't obviate the
need for a better solution to code development and management than text files.

Claudio Puviani wrote:
"Julie J." <unlisted@.> wrote

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...

I, for one, would avoid a "language" that forced me to store my code in a
database that's hidden behind some GUI. Anyone who's worked with such tools as
Rational Rose or systems like Actor can tell you how frustratingly constraining
that approach can be.

Being able to manage the code as plain text files is a strength, once you're
used to it, not a weakness. You not only have access to hundreds of utilities to
do just about everything, but you get to choose which ones you want to use. With
database approach, you're stuck with whatever the compiler vendor provides. Even
if a common set of tools eventually surfaced, it would take years for such tools
to approach the versatility of things like Perl or your favorite
(non-database-enabled) editor, and even then, you'd only have limited
functionality.

As to the C++ model being obsolete, that may well fuel hours of theoretical
discussions, but the reality is that C++ does what it purports to do
spectacularly well and it's highly doubtful that many people would migrate from
C++ to some hypothetical pretty replacement just because it would satisfy some
abstract esthetics. There are already quite a few languages out there that "fix"
these esthetic irritants, yet I'm not seeing a mass exodus toward them.

No offense, but discussions of this nature rank right up there with "there
should be peace on earth", "every day should be a Saturday", and "William
Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure
flights of fancy.

Claudio Puviani

[Chris Mantoulidis]

"Gary" <gl*******@comcast.net> wrote in message news:<FZ********************@comcast.com>...

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message
news:a8**************************@posting.google.c om...

Oh I sence a little flame :P

<<snip>>

Pascal's synonym for "header file" is "unit". Java's synonym for
"header file" is something I can't remember atm :P (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.

I'm sorry, I don't really know Java; just seen code parts :) But you
get the central idea :)

[Claudio Puviani]

"Julie J." <unlisted@.> wrote

No offense, but discussions of this nature rank right up there with "there
should be peace on earth", "every day should be a Saturday", and "William
Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure flights of fancy.
Says you.

I'm sure that the punch-carders felt the same way that you do about

new-fangled text files. You are entitled to your opinion, but that doesn't obviate the
need for a better solution to code development and management than text files.

My point is that such "improvements" -- and the term is very subjective -- have
nothing to do with C++ and discussing them in the context of C++ is irrelevant.
I'm sure that you can't possibly have illusions that C++ will some day become
repository-based to the exclusion of files. Can some future language do that?
Sure. Along with many other niceties that theoretical linguists out there yearn
for. Wishing for C++ to become that language is, as I've said before, pure
flight of fancy.

As to your recurring comparison with punched cards, that's a total non sequitur.
Punched cards weren't a way to structure code. They were just an archaic way to
represent -- you guessed it -- files and streams. A slightly more appropriate
comparison would be the move from command-line interfaces to GUIs. For years,
the residents of the proverbial ivory tower predicted the demise of CLI's
because they were "obsolete", "too complicated", "not elegant enough". Yet, even
the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI
because GUIs simply can't offer the same versatility and fine-grained control.

Claudio Puviani

[Julie J.]

> the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI

because GUIs simply can't offer the same versatility and fine-grained control.
CLIs exist because of the need for automated/scripted/remote builds, not
because they offer more control than the GUI interface.

Claudio Puviani wrote:
"Julie J." <unlisted@.> wrote

No offense, but discussions of this nature rank right up there with "there
should be peace on earth", "every day should be a Saturday", and "William
Shatner shouldn't be allowed to sing." Pretty sentiments, to be sure, but pure flights of fancy.

Says you.

I'm sure that the punch-carders felt the same way that you do about

new-fangled

text files. You are entitled to your opinion, but that doesn't obviate the
need for a better solution to code development and management than text files.

My point is that such "improvements" -- and the term is very subjective -- have
nothing to do with C++ and discussing them in the context of C++ is irrelevant.
I'm sure that you can't possibly have illusions that C++ will some day become
repository-based to the exclusion of files. Can some future language do that?
Sure. Along with many other niceties that theoretical linguists out there yearn
for. Wishing for C++ to become that language is, as I've said before, pure
flight of fancy.

As to your recurring comparison with punched cards, that's a total non sequitur.
Punched cards weren't a way to structure code. They were just an archaic way to
represent -- you guessed it -- files and streams. A slightly more appropriate
comparison would be the move from command-line interfaces to GUIs. For years,
the residents of the proverbial ivory tower predicted the demise of CLI's
because they were "obsolete", "too complicated", "not elegant enough". Yet, even
the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI
because GUIs simply can't offer the same versatility and fine-grained control.

Claudio Puviani

[Claudio Puviani]

"Julie J." <unlisted@.> wrote

the knights protector of GUI -- Windows and the Macintosh -- still offers a CLI because GUIs simply can't offer the same versatility and fine-grained

control.
CLIs exist because of the need for automated/scripted/remote builds, not
because they offer more control than the GUI interface.

Doh. Automated/scripted/remote -- not to mention chained and parametrised --
tasks (not just builds) are precisely the kind of versatility and control that
you don't get from a GUI. Given your arguments, I'm beginning to question how
long you've been using development tools and on how many platforms.

Claudio Puviani