.h for standard headers

Peter van Merkerk wrote:

Did that era include, say, 1999?

No, C++ was standardized in 1998. Adding .h to the standard header
files may mean that some day your code will no longer compile when you
change/upgrade your compiler and/or the standard library
implementation. That may very well be the motivation for your boss to
insist on adding .h to standard headers.

I don't quite understand that statement. Why would the boss _want_ to
make sure that his programmers write code that will stop compiling on
modern compilers?

Jul 22 '05 #12

Tim Clacy

Christopher Benson-Manica wrote:

At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

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.

Jul 22 '05 #13

Julie

Christopher Benson-Manica wrote:

At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

1997/1998.

The compelling reason was that there wasn't a consensus on the appropriate C++
header extension (.h, .hpp, .hxx, ...), so it was agreed (not unanimously) to
drop the extension altogether.

Jul 22 '05 #14

Tim Clacy wrote:

Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

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.

Yeah, I'm crying my little heart out.

The new headers, unlike the old, place standard library constructs in
namespace std. Lots of legacy code already existed using the .h headers
and no namespace std. Having different names for the new (std-based)
headers allowed implementers to provide headers complying with the new
standard, without breaking the legacy code. For users of
implementations not providing the new headers, an easy work-around was
available:

// <iostream>

namespace std
{
#include <iostream.h>
}

Jul 22 '05 #15

Tim Clacy

Jeff Schwab wrote:

Tim Clacy wrote:
Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

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.

Yeah, I'm crying my little heart out.

...but seriously though, unless you're a hardened character-mode console
bashing hack, it is a pain not being able to easily identify or open header
files.
The new headers, unlike the old, place standard library constructs in
namespace std. Lots of legacy code already existed using the .h
headers and no namespace std. Having different names for the new
(std-based) headers allowed implementers to provide headers complying
with the new standard, without breaking the legacy code. For users of
implementations not providing the new headers, an easy work-around was
available:

// <iostream>

namespace std
{
#include <iostream.h>
}

Jul 22 '05 #16

Jeff Schwab wrote:

The new headers, unlike the old, place standard library constructs in
namespace std. Lots of legacy code already existed using the .h
headers and no namespace std. Having different names for the new
(std-based) headers allowed implementers to provide headers complying
with the new standard, without breaking the legacy code.

Which btw. brings up another point. The classes in the .h headers might
not be exactly the same as in the non-.h headers. So you might
experience surprises if you use the .h ones.

Jul 22 '05 #17

Tim Clacy wrote:

Jeff Schwab wrote:
Tim Clacy wrote:
Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...
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.

Yeah, I'm crying my little heart out.

..but seriously though, unless you're a hardened character-mode console
bashing hack, it is a pain not being able to easily identify or open header
files.

Well, I am pretty much a console-oriented kinda guy. However, I'm not
sure how relevant that is. I know what type of files are stored in
directories called "include", and my preferred editors can recognize
file-types based on names matching arbitrary patterns, not just the file
names' extensions.

Jul 22 '05 #18

Stephen Howe

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c8**********@chessie.cirr.com...

At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

Your boss needs re-educating.
Your boss should changes his views so that, "Whatever is standard C++, is
the company standard". That view will last a long time.

Stephen Howe

Jul 22 '05 #19

"David Fisher" <da***@hsa.com.au> wrote in message
news:dk****************@nasal.pacific.net.au...

Christopher Benson-Manica asked:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...
You may have a problem with <string.h> (should it be the one containing
strcpy() or the std::string class ?)

According to Chuck Alison in the article "What's New in Standard C++"
(http://www.freshsources.com/newcpp.html), old style library headers are
deprecated ... here is the relevant quote:

Invoking Standard C Headers with a .h suffix
--------------------------------------------

We traditionally think of headers as files, but a compiler is free to make

a header's declarations available in any manner it chooses. To encourage this point of view, the C++ standards committee voted rather early to drop the ..h suffix for C++ headers. This means that you should use "#include <
iostream>" instead of "#include <iostream.h>", although most compilers will allow both. When namespaces were added to the language, the committee
decided to wrap most C++ and all standard C library declarations in the
standard namespace std, and to rename the C headers by prepending a 'c' and dropping the .h suffix. This means that the preferred method of getting at C library features is the same for using C++ library elements, for example
#include <cstdio>

int main()
{
std::printf("hello, world\n");
}

Thinking that this might be too much of a culture shock, the committee
decided to deprecate instead of to disallow altogether the traditional ".h" method. For now, if you say "#include <stdio.h>", it's as if you had written "#include <cstdio>" followed by a using declaration for each identifier
defined in the header (so you don't have to use the std:: prefix).

True in theory, not always in practice.

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

Jul 22 '05 #20

Christopher Benson-Manica

Stephen Howe <stephenPOINThoweATtns-globalPOINTcom> spoke thus:

Your boss needs re-educating.
Your boss should changes his views so that, "Whatever is standard C++, is
the company standard". That view will last a long time.

That's unlikely - I got chewed out yesterday because I changed a
global character array to a global string, and I've been all but
forbidden to use vectors, maps, and sets, not to mention strings. I
can't use streams at all because they don't work correctly, and I
can't count on other things working because our implementation is two
versions out of date. Yes, I've decided to find myself another job,
if I can :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Jul 22 '05 #21

Frank Looper

> ..but seriously though, unless you're a hardened character-mode console

bashing hack, it is a pain not being able to easily identify or open header files.

Just drag into a text editor.

Frank

Jul 22 '05 #22

Alan Johnson

Rolf Magnus wrote:

Peter van Merkerk wrote:

Did that era include, say, 1999?

No, C++ was standardized in 1998. Adding .h to the standard header
files may mean that some day your code will no longer compile when you
change/upgrade your compiler and/or the standard library
implementation. That may very well be the motivation for your boss to
insist on adding .h to standard headers.

I don't quite understand that statement. Why would the boss _want_ to
make sure that his programmers write code that will stop compiling on
modern compilers?

Job security.

Alan

Jul 22 '05 #23

David Fisher

P.J. Plauger wrote:

David Fisher wrote:
According to Chuck Alison in the article "What's New in Standard C++"
(http://www.freshsources.com/newcpp.html), old style library headers are
deprecated ... here is the relevant quote:

Invoking Standard C Headers with a .h suffix
--------------------------------------------

We traditionally think of headers as files, but a compiler is free to make a header's declarations available in any manner it chooses. To encourage
this point of view, the C++ standards committee voted rather early to
drop the .h suffix for C++ headers. This means that you should use
"#include < iostream>" instead of "#include <iostream.h>", although
most compilers will allow both. When namespaces were added to the
language, the committee decided to wrap most C++ and all standard
C library declarations in the standard namespace std, and to rename
the C headers by prepending a 'c' and dropping the .h suffix. This
means that the preferred method of getting at C library features is the
same for using C++ library elements, for example

#include <cstdio>

int main()
{
std::printf("hello, world\n");
}

Thinking that this might be too much of a culture shock, the
committee decided to deprecate instead of to disallow altogether
the traditional ".h" method. For now, if you say "#include <stdio.h>",
it's as if you had written "#include <cstdio>" followed by a using
declaration for each identifier defined in the header (so you don't
have to use the std:: prefix).
True in theory, not always in practice.

Only with reference to the last bit, or some of the other statements too ?

Do you have a feel for how widely these guidelines are actually followed ?

Thanks for the reply,

David Fisher
Sydney, Australia

Jul 22 '05 #24

John Carson

"Tim Clacy" <no*******@nospamphaseone.nospamdk> wrote in message
news:40*********************@dread11.news.tele.dk

..but seriously though, unless you're a hardened character-mode
console bashing hack, it is a pain not being able to easily identify
or open header files.

If you are using VC++, you can easily do that from within the IDE by putting
the cursor in the header name and using the right-click menu.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

Jul 22 '05 #25

Bill Seurer

Tim Clacy wrote:

..but seriously though, unless you're a hardened character-mode console
bashing hack, it is a pain not being able to easily identify or open header
files.

So get a tool (or change the confguration of the one you have) that
understands that

#include <cstdio>

maps to a file called "cstdio.h" (or whatever) on your system. It's not
much harder than it understanding

#include <stdio.h>

maps to a file named "stdio.h".

Jul 22 '05 #26

"Bill Seurer" <se****@us.ibm.com> wrote in message
news:c8***********@news.rchland.ibm.com...

Tim Clacy wrote:
..but seriously though, unless you're a hardened character-mode console
bashing hack, it is a pain not being able to easily identify or open header files.

So get a tool (or change the confguration of the one you have) that
understands that

#include <cstdio>

maps to a file called "cstdio.h" (or whatever) on your system. It's not
much harder than it understanding

#include <stdio.h>

maps to a file named "stdio.h".

Hey, that sounds great. That means you could have <string> map to
<string.h> and <limits> map to <limits.h> too. Too bad there are
already headers with those names...

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

Jul 22 '05 #27

"David Fisher" <da***@hsa.com.au> wrote in message
news:RN*****************@nasal.pacific.net.au...

P.J. Plauger wrote:
David Fisher wrote:
According to Chuck Alison in the article "What's New in Standard C++"
(http://www.freshsources.com/newcpp.html), old style library headers are deprecated ... here is the relevant quote:

Invoking Standard C Headers with a .h suffix
--------------------------------------------

We traditionally think of headers as files, but a compiler is free to make a header's declarations available in any manner it chooses. To encourage this point of view, the C++ standards committee voted rather early to
drop the .h suffix for C++ headers. This means that you should use
"#include < iostream>" instead of "#include <iostream.h>", although
most compilers will allow both. When namespaces were added to the
language, the committee decided to wrap most C++ and all standard
C library declarations in the standard namespace std, and to rename
the C headers by prepending a 'c' and dropping the .h suffix. This
means that the preferred method of getting at C library features is the
same for using C++ library elements, for example

#include <cstdio>

int main()
{
std::printf("hello, world\n");
}

Thinking that this might be too much of a culture shock, the
committee decided to deprecate instead of to disallow altogether
the traditional ".h" method. For now, if you say "#include <stdio.h>",
it's as if you had written "#include <cstdio>" followed by a using
declaration for each identifier defined in the header (so you don't
have to use the std:: prefix).

True in theory, not always in practice.

Only with reference to the last bit, or some of the other statements too ?

Do you have a feel for how widely these guidelines are actually followed ?

The fundamental arrogance in the C++ Standard was thinking that
it could usurp the central role of the C headers in a typical
implementation. To conform fully to the C++ Standard, an
implementation effectively has to make <cstdio> the fundamental
header. It declares all names within namespace std. The newly
demoted <stdio.h> then would do much as Chuck says: include
<cstdio> and then hoist each declared name individually into
the global namespace with a separate using declaration. (You
can't use an omnibus declaration to hoist all the names at once,
for a variety of reasons. But that's just a nuisance for the
implementor.) As icing on the cake, the C++ Standard then puts
the world on notice that headers like <stdio.h> will one day go
away, because they're deprecated.

This is nonsense. As several of us vendors repeatedly warned the
C++ committee, the C headers are and will long remain the true
fundamental headers describing the Standard C library component
of the Standard C++ library. A gazillion technical, political,
and administrative reasons combine to keep most C++ implementations
from fully conforming to the C++ Standard in this regard. The
common practice is to leave the C headers alone (aside from a bit
more crud wrapped in #ifdef __cplusplus/#endif envelopes.) Instead,
<cstdio> includes <stdio.h> and hoists names from the global
namespace into namespace std. The differences in effect can be
kept small, with a not-unreasonable coding style, but they're there.
And they're one more reason (besides export templates) why many
implementations can't claim 100 per cent conformance to the C++
Standard.

FWIW, a couple of libraries do meet these requirements. Metrowerks
and RogueWave as shipped with Solaris C++ are two that spring to
mind. The Dinkumware libraries can be configured to fully
conform, but interestingly enough many of our OEM compiler vendors
still choose not to. Libraries like libstdc++ (shipped with gcc)
and STLport are dependent on underlying C libraries supplied by
others, so they can't fully conform. Needless to say, those
underlying C libraries seldom supply even the simple additions
required by the C++ Standard, much less accommodate draconian
restructuring for namespaces.

I also don't like the loss of the .h suffix on C++ headers. Too
many tools exist that are inconvenienced, to say the least, if
there's no *.xx for some xx to identify groups of files. But
that's another battle I lost.

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

Jul 22 '05 #28

Alf P. Steinbach

* "P.J. Plauger" <pj*@dinkumware.com> schriebt:

But that's another battle I lost.

Reason has no place in politics, except to lie & influence better.

From Scientific American May 2004, <url: http://tinyurl.com/2eh2q>:
"Bush-League Lysenkoism: The White House bends science to its will"

Uh, sorry, off-topic... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Jul 22 '05 #29

Tim Clacy

Bill Seurer wrote:

Tim Clacy wrote:
..but seriously though, unless you're a hardened character-mode
console bashing hack, it is a pain not being able to easily identify
or open header files.

So get a tool (or change the confguration of the one you have) that
understands that

#include <cstdio>

maps to a file called "cstdio.h" (or whatever) on your system. It's
not much harder than it understanding

#include <stdio.h>

maps to a file named "stdio.h".

We've crossed wires I think. I'm saying that files without an extension
can't be opened by double-clicking in a file-system explorer, nor can they
be listed with meaningful associated icons. If you only ever open header
files from within your editor, then there's no problem. If, however, you
want to open a file that you've found by exploring, then you do have a
problem.

Jul 22 '05 #30

Bill Seurer

Tim Clacy wrote:

We've crossed wires I think. I'm saying that files without an extension
can't be opened by double-clicking in a file-system explorer, nor can they
be listed with meaningful associated icons. If you only ever open header
files from within your editor, then there's no problem. If, however, you
want to open a file that you've found by exploring, then you do have a
problem.

That may be true on Windows but possibly not on all OSes. On Windows
you can also right click and choose something to do with any file,
either add your own selection to that menu for your favorite editor or
Send To and then the editor.

Jul 22 '05 #31

Howard

"Bill Seurer" <se****@us.ibm.com> wrote in message
news:c8***********@news.rchland.ibm.com...

Tim Clacy wrote:
We've crossed wires I think. I'm saying that files without an extension
can't be opened by double-clicking in a file-system explorer, nor can they be listed with meaningful associated icons. If you only ever open header
files from within your editor, then there's no problem. If, however, you
want to open a file that you've found by exploring, then you do have a
problem.

That may be true on Windows but possibly not on all OSes. On Windows
you can also right click and choose something to do with any file,
either add your own selection to that menu for your favorite editor or
Send To and then the editor.

That's a workaround for opening a file under Windows all right, but it
doesn't change the fact that the STL broke a standard that's been in Windows
for some time now, and that standard is "file type association via the
filename extension".

In addition to the icon and double-click issue, some features of my editors
and C++ tools are more difficult to use without file extensions.

Opening a file, for example. By default, when I go to open a source file in
Visual Studio, the files are filtered by the common C++ extensions (.c,
..cpp, .h, etc.). I have to go click on "All files" before I can even *see*
files with no extension!

No matter what workaraound there might be for a given problem, the fact
remains that this choice to have no extension for those file names broke the
Windows standard.

I am not suggesting that Windows ought to dictate how things are done in the
C++ world in general, but the simple fact is that Windows is used more
widely than any other OS in the world, and *some* consideration ought to be
made for that fact.

{/rant}

(BTW, I prefer the MacOS way of doing things, but half my work is on the PC.
Oh well, I don't get paid to do what I want. :-))

-Howard

Jul 22 '05 #32

Tim Clacy wrote:

Bill Seurer wrote:
Tim Clacy wrote:

..but seriously though, unless you're a hardened character-mode
console bashing hack, it is a pain not being able to easily identify
or open header files.

So get a tool (or change the confguration of the one you have) that
understands that

#include <cstdio>

maps to a file called "cstdio.h" (or whatever) on your system. It's
not much harder than it understanding

#include <stdio.h>

maps to a file named "stdio.h".

We've crossed wires I think. I'm saying that files without an extension
can't be opened by double-clicking in a file-system explorer, nor can they
be listed with meaningful associated icons. If you only ever open header
files from within your editor, then there's no problem. If, however, you
want to open a file that you've found by exploring, then you do have a
problem.

Well, that's a limitation of Windows, isn't it?

Jul 22 '05 #33

Tim Clacy wrote:

We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Jul 22 '05 #34

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...

Tim Clacy wrote:
We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Then call me brain damaged. 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. Absent a simple regular expression,
I've found it damned difficult to work with the new C++ style headers
on damn near *any* OS. Bash Windows if you will, or dismiss this as
not a problem, but it still annoys me on a daily basis.

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

Jul 22 '05 #35

Jorge Rivera

That's a workaround for opening a file under Windows all right, but it
doesn't change the fact that the STL broke a standard that's been in Windows
for some time now, and that standard is "file type association via the
filename extension".

And a question comes to mind. Why does STL need to consider the Windows
standard??????

It broke it, we all deal with it...

JLR

Jul 22 '05 #36

Duane Hebert

"P.J. Plauger" <pj*@dinkumware.com> wrote in message news:Ru****************@nwrddc03.gnilink.net...

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...
Tim Clacy wrote:
We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Then call me brain damaged. 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. Absent a simple regular expression,
I've found it damned difficult to work with the new C++ style headers
on damn near *any* OS. Bash Windows if you will, or dismiss this as
not a problem, but it still annoys me on a daily basis.

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

Jul 22 '05 #37

Julie

Rolf Magnus wrote:

Tim Clacy wrote:
We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Don't _most_ operating systems behave this way -- were type information is
stored w/ the name (extension)? I hardly think this is anything peculiar w/
Windows.

Mac is the only OS that I'm aware of that has a separate 'resource fork' that
handles file type information.

What is your suggestion that is better than this "braindamaged" way?

Jul 22 '05 #38

P.J. Plauger wrote:

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...

Tim Clacy wrote:

We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Then call me brain damaged. 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. Absent a simple regular expression,
I've found it damned difficult to work with the new C++ style headers
on damn near *any* OS. Bash Windows if you will, or dismiss this as
not a problem, but it still annoys me on a daily basis.

What other sorts of files do you store in your "include" directories? I
sometimes have a README file, but it's easy enough to wrap its contents
in /* */.

Jul 22 '05 #39

Julie wrote:

Rolf Magnus wrote:
Tim Clacy wrote:

We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.
That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Don't _most_ operating systems behave this way -- were type information is
stored w/ the name (extension)?

No.
I hardly think this is anything peculiar w/
Windows.

Mac is the only OS that I'm aware of that has a separate 'resource fork' that
handles file type information.

What is your suggestion that is better than this "braindamaged" way?

For the OS to neither know nor care about the exact types of files.

Jul 22 '05 #40

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?

Jul 22 '05 #41

Old Wolf

"Tim Clacy" <no*******@nospamphaseone.nospamdk> wrote:

Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...

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

Jul 22 '05 #42

Old Wolf

"Duane Hebert" <sp**@flarn2.com> wrote:

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.

Jul 22 '05 #43

P.J. Plauger wrote:

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...
Tim Clacy wrote:
> We've crossed wires I think. I'm saying that files without an
> extension can't be opened by double-clicking in a file-system
> explorer, nor can they be listed with meaningful associated icons.
That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific
operating systems. The idea of finding a file's type by name only is
quite braindamaged anyway.

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.

Jul 22 '05 #44

"Jeff Schwab" <je******@comcast.net> wrote in message
news:tp********************@comcast.com...

P.J. Plauger wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...

Tim Clacy wrote:
We've crossed wires I think. I'm saying that files without an
extension can't be opened by double-clicking in a file-system
explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.

Then call me brain damaged. 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. Absent a simple regular expression,
I've found it damned difficult to work with the new C++ style headers
on damn near *any* OS. Bash Windows if you will, or dismiss this as
not a problem, but it still annoys me on a daily basis.

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

Jul 22 '05 #45

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"Tim Clacy" <no*******@nospamphaseone.nospamdk> wrote:
Christopher Benson-Manica wrote:
At what point was the .h dropped from the STL headers? I just had a
discussion yesterday with my boss, who said he wanted .h on all the
STL includes, despite me protesting that it was not standard...
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.)

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

Jul 22 '05 #46

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"Duane Hebert" <sp**@flarn2.com> wrote:
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).

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

Jul 22 '05 #47

P.J. Plauger wrote:

"Jeff Schwab" <je******@comcast.net> wrote in message
news:tp********************@comcast.com...

P.J. Plauger wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...

Tim Clacy wrote:

>We've crossed wires I think. I'm saying that files without an
>extension can't be opened by double-clicking in a file-system
>explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific operating
systems. The idea of finding a file's type by name only is quite
braindamaged anyway.
Then call me brain damaged. 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. Absent a simple regular expression,
I've found it damned difficult to work with the new C++ style headers
on damn near *any* OS. Bash Windows if you will, or dismiss this as
not a problem, but it still annoys me on a daily basis.
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.

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

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.

Think harder.

Jul 22 '05 #48

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...

P.J. Plauger wrote:
"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c8*************@news.t-online.com...
Tim Clacy wrote:

> We've crossed wires I think. I'm saying that files without an
> extension can't be opened by double-clicking in a file-system
> explorer, nor can they be listed with meaningful associated icons.

That's a problem of your OS. I don't see why the C++ standard should
have to provide workarounds for the shortcomings of specific
operating systems. The idea of finding a file's type by name only is
quite braindamaged anyway.
Then call me brain damaged.

Why? Did you invent it?

You're being a jerk.

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?

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?

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?

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.

Bash Windows if you will,

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.

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.

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

Jul 22 '05 #49