.h for standard headers

[P.J. Plauger]

The point is, it is not a requirement that the thing in between
the < > be an actual file on the system,

Well, yes. But the same rule is in Standard C, which kept the .h
suffixes. So this *still* has nothing to do with omitting the
suffix.

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.

Oh, I've looked long and hard at the Borland packaging. It's gotten
better, but there for a while it was so determined to remap suffixes
that us third-party library vendors didn't have a chance at
selectively displacing parts of the library. Sun went through
much the same exercise. It's telling that both have backed down
considerably from their earlier positions.

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

What you have to do to deliver standard-conforming C++ is way
more complex than you've outlined.

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.

Yeah, I do. Borland's packaging is *not* compelling evidence
that omitting the .h from the Standard C++ headers leads tp
better technology.

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

 

[Bill Seurer]

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

#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.


There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.

 

[P.J. Plauger]

#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.


There is nothing magic about ".h".

You mean, aside from the fact that it has been used to designate
C headers for over 30 years? Or that it is still used for header
names mandated by both the C and C++ Standards?

In fact, many people use .H or .hpp
or .h++ or something else.

Yes, "many people" do. But we're talking about what the C++ Standard
mandates, which is suffix-less header names. Moreover, it does *not*
mandate that these names be mapped into names with nice suffixes,
so most preprocessors simply take the header name as the filename
in one or more candidate include directories. The real-life
situation is thus that the world is now awash with filenames that
lack suffixes, while most shells are geared toward naming groups
with wildcards that are *much* easier to write for names with a
common suffix. And developers *do* have occasion to want to name
all the C++ headers as a group.

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

 

[Prateek R Karandikar]

The standard does NOT dictate how headers are stored on your system.
<iostream> is a header, not a header file. A header is just an
abstraction that guarantees that the required declarations are
available, not necessarily mapping to a disk file. If your system
stores header in an inconvenient manner, the standard cannot solve
that problem. C++ is a cross-platform, system-independent language.
Why should it be guided by Windows' file conventions?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

[Julie]

The standard does NOT dictate how headers are stored on your system.
<iostream> is a header, not a header file. A header is just an
abstraction that guarantees that the required declarations are
available, not necessarily mapping to a disk file. If your system
stores header in an inconvenient manner, the standard cannot solve
that problem. C++ is a cross-platform, system-independent language.
Why should it be guided by Windows' file conventions?

For the informed, this is *NOT* a discussion about Windows (or any other
specific) OS issue.

It is about the inappropriate change of a de facto standard of a .h header
suffix by the C++ standards committee.

 

[Jorge Rivera]

It is about the inappropriate change of a de facto standard of a .h header

suffix by the C++ standards committee.

Your opinion on the standard comitee's decision to drop the .h extension
from the headers doesn't make the chane an inappropriate one. I like
the fact that standard headers don't have an extension.

JLR

 

[Howard]

Your opinion on the standard comitee's decision to drop the .h extension
from the headers doesn't make the chane an inappropriate one. I like
the fact that standard headers don't have an extension.

JLR

That's nice. Does your opinion make it an appropriate change?

One of the main contributors to this thread was apparently on the committee
that made the decision, and he disagrees with it. And many of us agree.

What was gained by the decision? (And I'm wondering...why *do* you like
it..because you don't have that whopping extra workload of typing in .h
after the name?)

It changed the way it had been done for ages, and resulted in problems for
many of us. Am I incorrect on either of those points?

-Howard

 

[Jorge Rivera]

It changed the way it had been done for ages, and resulted in problems for

many of us. Am I incorrect on either of those points?

I am not interested in what's correct or not. Do you think changing it
back will be any better?

I like it because anywhere I see something without a .h, typically it
means I am using a standard header. Anything else is not standard C++.
Hence I don't have to carefully check each file to look for non
standard additions.

I do understand the pain involved in the change. All I'm saying is that
I like it. A judgement of "inappropiate" comes usually from the fact
that someone doesn't like it. Who cares how many people in the comitee
dind't like this idea? The majority did, and so it is. Deal with it.

JLR

 

[P.J. Plauger]

I am not interested in what's correct or not. Do you think changing it
back will be any better?

I like it because anywhere I see something without a .h, typically it
means I am using a standard header. Anything else is not standard C++.

Like assert.h, ctype.h, errno.h, float.h, iso646.h, limits.h, locale.h,
math.h, setjmp.h, signal.h, stdarg.h, stddef.h, stdio.h, stdlib.h,
string.h, time.h, wchar.h, or wctype.h? An implementation that *fails*
to provide any of these headers is not Standard C++. Good rule.

Hence I don't have to carefully check each file to look for non
standard additions.

Like project1st, project2nd, select1st, select2nd, iota, etc. etc.?
I've found all of these, and then some, in those "standard" headers
with no suffixes. Another good rule.

I do understand the pain involved in the change. All I'm saying is that
I like it. A judgement of "inappropiate" comes usually from the fact
that someone doesn't like it.

Not entirely. It also comes from a failure of the committee to "codify
existing practice." That's a legitimate gripe, particularly because
on practically every occasion where WG21 abandoned existing practice,
they've caused on-going pain.

Who cares how many people in the comitee
dind't like this idea? The majority did, and so it is. Deal with it.

That part I agree with. I accept majority rule and I deal with it
on a daily basis. IMO, most of this thread has been about some
people pretending there is no problem, or defining it out of
existence, and others (like me) doggedly explaining that there
*is* a problem and it won't go away. I'd be the last person to
suggest, at this late date, that we change the C++ Standard in
an attempt to undo the damage. It would only cause more. And
I note that none of the other "complainers" are asking for a
change either.

OTOH, I've heard several reasons advanced for why this change
is a good idea, and I haven't heard one yet that I think
holds water. YMMV.

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

 

[Minti]

#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.


There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.

Yes it could be even .cpp[ As has been used in case of Algorithms in
C++ by Sedgwick ], but the point is the emphasis shown in case of the
above quotes. Why emphasize that your headers are genuine header files
in every implementation, system headers aren't.


IMO the probablity of having non-suffix user headers is/should be the
same that of non-suffix system headers [ Which is 1.0 ].

If the standard wants to take away the suffix it should do it as a
whole.

I don't have the copy of standard right now on my desktop, but I am
quite sure it also uses .h as a suffix for denoting header files.

 

[Julie]

#include <babalooie>

as well as

#include <babalooie.xyz>

will work just fine.


There is nothing magic about ".h". In fact, many people use .H or .hpp
or .h++ or something else.

Yes it could be even .cpp[ As has been used in case of Algorithms in
C++ by Sedgwick ], but the point is the emphasis shown in case of the
above quotes. Why emphasize that your headers are genuine header files
in every implementation, system headers aren't.

IMO the probablity of having non-suffix user headers is/should be the
same that of non-suffix system headers [ Which is 1.0 ].


If the standard wants to take away the suffix it should do it as a
whole.

The standards committee exists for the *benefit* of the users (us), not the
other way around.

The standards committee is charged w/ purpose of making changes to the standard
that are in the best interest of the _community_. I'd like to hear one reason
where extensionless headers have BENEFITED the users (us), excluding
preferential opinions.

The standards committee usurped authority that it didn't have when making the
extensionless change. Fortunately the effects haven't had too negative of an
impact, but we (THE COMMUNITY) should be vigilant for other
unwarranted/unjustified changes to the standard that may have far greater
(negative) consequences...

Remember, the standards (and committee) exist for *OUR* benefit and pleasure.

 

[bartek]

(...)

The standards committee exists for the *benefit* of the users (us),
not the other way around.

The standards committee is charged w/ purpose of making changes to the
standard that are in the best interest of the _community_. I'd like
to hear one reason where extensionless headers have BENEFITED the
users (us), excluding preferential opinions.

The standards committee usurped authority that it didn't have when
making the extensionless change. Fortunately the effects haven't had
too negative of an impact, but we (THE COMMUNITY) should be vigilant
for other unwarranted/unjustified changes to the standard that may
have far greater (negative) consequences...

Remember, the standards (and committee) exist for *OUR* benefit and
pleasure.

Actually it's characteristic to all collective efforts on decision making
(committees, governments, boards, etc...). That's how the world works.
There are bad decisions made by good people and vice versa. We just have
to live with it...

.... or ... we can put machines in charge...

Cheers.