.h for standard headers

[Julie]

Let's try a different tack:

- What was K&R's original intention of appending .h to includes?

- Why is that intention no longer considered valid w/ C++ standard includes?

 

[Old Wolf]

Presumably the idea of omitting an extension was thought up by someone who
doesn't use Windows; we have lost the conveniences of double clicking to
open and meaningful icon associations in one fell swoop.

Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)
There does not have to be any file "iostream", and in fact, the
implementation does not even have to have a filesystem.

On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction, and I can
still do the double-click trick (which, incidentally, I almost never
do, since I use a shell with tab completion).

 

[Old Wolf]

grep "somefunctionname" *.h is a sight better than grep
"somefunctionname" *.* when I'm looking for a function
declaration in a header file.

"grep foo *.*" will not find things in files that don't contain a dot
(except on retarded filesystems). Why not list all your implementation's
standard headers into a file (that won't ever need to change), and then
you can go:

grep foo *.h `cat stdhdrs`

or make an alias or small script to do that. If you want to search
headers in many directories (eg. if you're working on a project with
3rd party libraries) regularly, you have to do something like this anyway.

 

[Rolf Magnus]

Then call me brain damaged.

Why? Did you invent it?

For several decades now I've found it convenient to select all the
headers in a directory by typing *.h, or all the C files by *.c, etc.

Well, you found it to be the most convenient out of how many different
ways? Btw, I didn't really say that file name extensions themselves are
braindead, but rather that the idea of the desktop/file
browser/whatever depending only on that for finding out a file's type
is.
And with your *.h pattern, what about .hpp or .hxx or .tcc or whatever
else people use for (some of) their headers? I'd rather like to see a
shell that can give you a list of all files that have a specific
mimetype.
And - since we were specifically talking about the standard headers -
how many other file types than headers do you have in the include
directory of your standard library?

Absent a simple regular expression, I've found it damned difficult to
work with the new C++ style headers on damn near *any* OS.

What exactly do you mean?

Bash Windows if you will,

This is not about Windows. It's about a concept that (among others)
Windows just happens to use.

or dismiss this as not a problem, but it still annoys me on a daily
basis.

It might be a problem, but I think it's not the C++ standard's task to
solve it.

 

[P.J. Plauger]

What other sorts of files do you store in your "include" directories?

So you're telling me that I shouldn't have the problem I have if only
my work habits were correct? That's the usual (non)defense of somebody
who either doesn't see the problem or doesn't want to admit it exists.

As someone who develops libraries all the time, I often have mixes of
"standard" headers and other code in the same directory for periods
of time. With the C headers, I can grep all of them with no fear of
sweeping up an odd assortment of executables, etc. in the process.
That's not so easy with the new C++ headers, and it's a real loss,
IMO, for no real gain.

I
sometimes have a README file, but it's easy enough to wrap its contents
in /* */.

I suppose this is a relevant comment, but I can't imagine how.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)

Uh, yes. But what does that have to do with omitting the suffix?

There does not have to be any file "iostream", and in fact, the
implementation does not even have to have a filesystem.

True. That was a principle we introduced with the C Standard, and
I ensured that it was picked up by the C++ Standard. But *in the
real world* headers are real live files almost all the time,
and some of us are continually grepping them, or copying them,
or doing all sorts of other things where we'd like to name them
as a group. That's not so easy any more.

On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction,

It's actually a preprocessing directive, FWIW. You must have an
unusual compiler, because all the ones I use on Windows consider
iostream.h to be the pre-standard legacy version of iostreams.
The file iostream is the one that gets read by the include you
show above.

and I can
still do the double-click trick (which, incidentally, I almost never
do, since I use a shell with tab completion).

I'm happy for you. Doesn't diminish the problem that others have
stated here, however.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

"grep foo *.*" will not find things in files that don't contain a dot
(except on retarded filesystems).

And even there, you're at the mercy of the particular tool. It is a
rare system that has the equivalent of the old Unix /etc/glob, which
uniformly expanded wild-card patterns on a command line for all
comers. NB: There is such a critter with the MKS Toolkit, but
heaven help you if you try to make sense out of it. Just try
contriving a wild-card pattern that matches only files with no .*
suffix. This would all be a non-problem if the C++ Committee had
settled on *any* .xx suffix, even if they wanted to get away from .h.

Why not list all your implementation's
standard headers into a file (that won't ever need to change),

What planet do you live on? They change regularly. In particular,
the subset of headers you want to look at on any given occasion
changes all the time. You can't make a problem go away by redefining
it out of existence.

and then
you can go:

grep foo *.h `cat stdhdrs`

which doesn't exactly roll trippingly off the tongue even if stdhdrs
is in your current directory (looking like a C++ header file, I
might add).

or make an alias or small script to do that. If you want to search
headers in many directories (eg. if you're working on a project with
3rd party libraries) regularly, you have to do something like this anyway.

No I don't. The beauty of the shell language developed so many
decades ago is that it is a) terse and b) easy to type correctly.
(It is also c) easy to encapsulate in scripts, but that's another
dimension.) None of the kludges proposed to make up for the loss
of the suffix satisfy either a) or b).

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

So you're telling me that I shouldn't have the problem I have if only
my work habits were correct? That's the usual (non)defense of somebody
who either doesn't see the problem or doesn't want to admit it exists.

I'm not telling you anything, I'm asking you a question. If your
point is that, theoretically, somebody could be storing other stuff in
the standard "include" directory, and that the same people may
subsequently whine that their environment is cluttered, then you got me.
The cat's out of the bag; the traditional file-based C++ development
model is open to abuse!

As someone who develops libraries all the time, I often have mixes of
"standard" headers and other code in the same directory for periods
of time. With the C headers, I can grep all of them with no fear of
sweeping up an odd assortment of executables, etc. in the process.
That's not so easy with the new C++ headers, and it's a real loss,
IMO, for no real gain.

What do you mean "standard" headers? When you're implementing the
standard C++ headers, just keep a subdirectory full of symlinks to the
standard headers, and grep through $subdir/*. If you're developing some
other set of headers, you can call them whatever you like; mine end in
".hh".

I suppose this is a relevant comment, but I can't imagine how.

Think harder.

 

[P.J. Plauger]

Why? Did you invent it?

You're being a jerk.

Well, you found it to be the most convenient out of how many different
ways?

I've been programming for a living for over forty years. Let's just
say that I've developed software *many* different ways. But would it
diminish the loss of convenience if I found it most convenient out
of only three different ways?

Btw, I didn't really say that file name extensions themselves are
braindead, but rather that the idea of the desktop/file
browser/whatever depending only on that for finding out a file's type
is.

And nobody said that it was the only way, just that it's a damned
convenient way that's now gone for C++ headers.

And with your *.h pattern, what about .hpp or .hxx or .tcc or whatever
else people use for (some of) their headers? I'd rather like to see a
shell that can give you a list of all files that have a specific
mimetype.

That's nice. What does it have to do with the loss of functionality
that's the topic of this thread? But in fact it's still easier to
type *.h* *.tcc than all the kludges proposed to name just files
that have no .xx suffix.

And - since we were specifically talking about the standard headers -
how many other file types than headers do you have in the include
directory of your standard library?

This question was raised in another comment, and I replied. But why
are you making me wrong for having a problem that's still a real
problem?

What exactly do you mean?

I mean that the wild-card patterns supported by all the shells
I use (DOS, Unix, Linux, etc.) are uniformly weak at letting you
specify the set of all filenames that don't have a .xx suffix
of any sort.

This is not about Windows. It's about a concept that (among others)
Windows just happens to use.

*Other* people in this thread have tried to make it about Windows.
I agree that it is not.

It might be a problem, but I think it's not the C++ standard's task to
solve it.

But it *was* the C++ Standard's task not to introduce problems in
program development that weren't there to begin with, and they
failed this responsibility on several occasions -- despite repeated
warnings from me and other committee members.

The problem wouldn't need solving if Standard C++ hadn't created
it to begin with.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

Let's try a different tack:

- What was K&R's original intention of appending .h to includes?

To make the types of files readily apparent to people and tools.

- Why is that intention no longer considered valid w/ C++ standard includes?

Because a different solution has now become virtually universal: the
standard includes are stored in a dedicated directory.

 

[P.J. Plauger]

I'm not telling you anything, I'm asking you a question. If your
point is that, theoretically, somebody could be storing other stuff in
the standard "include" directory, and that the same people may
subsequently whine that their environment is cluttered, then you got me.
The cat's out of the bag; the traditional file-based C++ development
model is open to abuse!

So you *are* telling me that I have bad work habits, however much you
pretend otherwise. Noted.

What do you mean "standard" headers? When you're implementing the
standard C++ headers, just keep a subdirectory full of symlinks to the
standard headers, and grep through $subdir/*.

Say, thanks for telling me how to do my job. Now that you've
defined my problem in terms of "clutter" and "abuse" I see
that it really doesn't exist at all.

If you're developing some
other set of headers, you can call them whatever you like; mine end in
".hh".

Next time I develop extensions to Standard C++, I'll suggest that
we give all future headers a .hh suffix. Unfortunately, the current
contract I'm working under has already decided that I must use
unsuffixed names.

Think harder.

Your work habits are not mine.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

So you *are* telling me that I have bad work habits, however much you
pretend otherwise. Noted.




Say, thanks for telling me how to do my job. Now that you've
defined my problem in terms of "clutter" and "abuse" I see
that it really doesn't exist at all.




Next time I develop extensions to Standard C++, I'll suggest that
we give all future headers a .hh suffix. Unfortunately, the current
contract I'm working under has already decided that I must use
unsuffixed names.




Your work habits are not mine.

PJ, I'm not attacking you personally in any way. All I know about your
work habits is what you've told this group, and what I've read in CUJ;
I'm not trying to criticize you or your techniques. I see that from
your point of view, the move to extensionless standard headers caused an
unpleasant change. Things that used to work stopped working. I'm sorry
for this.

To be frank, though, I think that the removal of filename extensions
from the standard headers was the right move. It helps decouple C++
from any particular development model or file system. C++ developers
working with particular IDE's or sets of platforms can still use
whatever conventions are appropriate. Ways of working with the standard
headers in the same way one works with other headers are readily
available, using links, shortcuts, or other platform-specific techniques.

I'm certainly not trying to tell you your job; I don't have anything
like the depth of experience that you do. I do however think that file
naming conventions have little or no place in the C++ standard. If you
are working on some other set of libraries, and (as you said above) are
forced to used extensionless headers for them, it's an issue with that
contract, not the C++ standard.

 

[P.J. Plauger]

PJ, I'm not attacking you personally in any way. All I know about your
work habits is what you've told this group, and what I've read in CUJ;
I'm not trying to criticize you or your techniques.

Use of the terms "whine", "cluttered", and "abuse" are pejorative.
Thanks for clarifying your goal, but I encourage you to be a bit
more careful in how you achieve it in future.

I see that from
your point of view, the move to extensionless standard headers caused an
unpleasant change. Things that used to work stopped working. I'm sorry
for this.

Thanks. Me too.

To be frank, though, I think that the removal of filename extensions
from the standard headers was the right move. It helps decouple C++
from any particular development model or file system. C++ developers
working with particular IDE's or sets of platforms can still use
whatever conventions are appropriate. Ways of working with the standard
headers in the same way one works with other headers are readily
available, using links, shortcuts, or other platform-specific techniques.

None of what you say is improved in any way that I can see by the
removal of filename extensions. Given that *.h headers had been in
use for roughly a quarter century when the committee decided to
remove them, and given that they continue to be used as C headers,
it's hard to argue that any existing platform would be inconvenienced
by retaining them. OTOH, the C++ committee violated its charter, in
part, by breaking with past practice. There are many ways they could
have achieved their stated goals without eliminating filename
suffixes altogether. (I do accept the fact that they did. I only
complain when the topic rears up anew, as it does from time to time,
as part of the overall discussion.)

I'm certainly not trying to tell you your job; I don't have anything
like the depth of experience that you do. I do however think that file
naming conventions have little or no place in the C++ standard.

And I think they're one of the central aspects of the C++ Standard.
We certainly give a lot of thought to consistent header naming for
each new proposed addition (and did so during the drafting of the
original standard).

If you
are working on some other set of libraries, and (as you said above) are
forced to used extensionless headers for them, it's an issue with that
contract, not the C++ standard.

Except that this particular part of the contract is written that way
*because* of the decision made by the C++ committee. That decision
also circumscribes the naming options for all sorts of headers being
proposed with various Technical Reports, all of which Dinkumware is
implementing. This is *not* a problem confined to a fixed set of
files ghettoized in their own private directory. Certainly not for
us, and often not for others. (But see separate reply for more details.)

I'm truly happy that this change has little or no effect on your work
habits. That means it's less disruptive than I first feared.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

To make the types of files readily apparent to people and tools.

Still a good goal.

includes?

Because a different solution has now become virtually universal: the
standard includes are stored in a dedicated directory.

Yep, but They Are Not Alone. I just checked half a dozen compilers I
use on a regular bases, on my Windows laptop, a Linux system, and a
Solaris system. *Every one of them* had other files in the same directory
as the C++ headers. If you try to grep the headers for a given name,
there's no easy way to eliminate:

-- binary files, such as DLLs

-- subdirectories

-- supplemental "internal" headers with funny suffixes

all of which generate garbage, long search times, and/or false positives.
Maybe this is Bad Practice (TM) on the part of the tool packagers,
but it's damn near universal.

IME, grepping include files is not a practice reserved to a handful
of us library vendors. Everybody I know does it all the time. And
it's now appreciably less productive since include/*.h no longer
does the job.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Julie]

This is not about Windows. It's about a concept that (among others)
Windows just happens to use.


It might be a problem, but I think it's not the C++ standard's task to
solve it.

Rolf -- please pay attention.

The committee _CREATED_ the problem by changing the de facto standard of .h for
library includes.

 

[Julie]

To make the types of files readily apparent to people and tools.


Because a different solution has now become virtually universal: the
standard includes are stored in a dedicated directory.

Game, set, match.

The change from having the file type defined by the extension (context _free_)
to file type defined by file location (context _sensitive_) is a FUNDAMENTAL
change that honestly I think the C++ std committee didn't have the authority to
change. This change wasn't a standardization, but a _DE_standardization -- the
de facto standard regarding .h had been set years prior, and the committee
undid that.

I'd like to hear from anyone that has _BENEFITED_ from the change to
extensionless headers.

 

[Duane]

"grep foo *.*" will not find things in files that don't contain a dot
(except on retarded filesystems). Why not list all your implementation's
standard headers into a file (that won't ever need to change), and then
you can go:

grep foo *.h `cat stdhdrs`

or make an alias or small script to do that. If you want to search
headers in many directories (eg. if you're working on a project with
3rd party libraries) regularly, you have to do something like this anyway.

How is any of this simpler than grep foo *.h ?

 

[Minti]

Whatever. The instruction

#include <iostream>

means that the functions and objects which form part of the iostream
library (as defined by the Standard) are now in scope (etc. etc. etc.)
There does not have to be any file "iostream", and in fact, the
implementation does not even have to have a filesystem.

As pjp has already remarked you are using a preprocessor directive not
an instruction.

On my Windows system there is in fact only the file "iostream.h",
which gets included when you issue the above instruction,

How do you know for sure about that? Does your iostream file has the
following

namespace std{

 

[Minti]

Let's try a different tack:

- What was K&R's original intention of appending .h to includes?

- Why is that intention no longer considered valid w/ C++ standard includes?

Well Andrew Koenig in AC++ on page 66-67 says that

<quote>
The reason is[Why we refer to our own headers as header files and
implementation supplied headers as standard headers rather than
standard header files] that header files are genuine files in every
C++ implementation, but system headers need not be implemented as
files.
</quote>


I am not quite sure about this, I haven't worked on am implementation
on which header files are NOT implemented as files(Database
Systems(?)). But I believe that any implmentation that supports system
headers to be stored in a format other than in files IMO must support
storing/using/saving header files in non file format.

Why have a non suffix system headers but not non suffix header files.

 

[Old Wolf]

Uh, yes. But what does that have to do with omitting the suffix?

The point is, it is not a requirement that the thing in between
the < > be an actual file on the system, as evinced by my one
(Borland C++Builder 5 (with Rogue Wave)). There are in fact no
files without extensions, if you look in the system include directory.

It's actually a preprocessing directive, FWIW. You must have an
unusual compiler, because all the ones I use on Windows consider
iostream.h to be the pre-standard legacy version of iostreams.
The file iostream is the one that gets read by the include you
show above.

If you write "#include <iostream.h>" you get the legacy crap. If
you write "#include <iostream>" you get the standard stuff.
Obviously the system does a bit of 'beind the scenes' stuff when
you write "#include <iostream>" (I imagine it would be something
like: enter namespace std, define some macros, and then open the
file iostream.h, and so on, you probably have a better idea of
this than I do).

The same goes for all the standard headers. Some of the other files
in the system include dir:
cctype.h
iterator.h
function.h (corresponds to #include <functional>)
algorith.h (corresponds to #include <algorithm>)
string.h (corresponds to #include <string.h>)
string.stl (corresponds to #include <string>)

You get the idea.