F
Frank Looper
..but seriously though, unless you're a hardened character-mode console
Frank
Just drag into a text editor.
Frank
A
Alan Johnson
Rolf said:
Job security.
Alan
J
John Carson
Tim Clacy said:
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.
D
David Fisher
Christopher Benson-Manica asked:
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:
rintf("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).
David Fisher
Sydney, Australia
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:
rintf("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).
David Fisher
Sydney, Australia
B
Bill Seurer
Tim said:
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".
P
P.J. Plauger
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
P
P.J. Plauger
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
A
Alf P. Steinbach
* "P.J. Plauger said:
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... ;-)
T
Tim Clacy
Bill said:
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.
B
Bill Seurer
Tim said:
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.
D
David Fisher
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
H
Howard
Bill Seurer said:
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
J
Jeff Schwab
Tim said:
Well, that's a limitation of Windows, isn't it?
R
Rolf Magnus
Tim said:
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.
P
P.J. Plauger
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
J
Jorge Rivera
And a question comes to mind. Why does STL need to consider the Windows
standard??????
It broke it, we all deal with it...
JLR
D
Duane Hebert
P.J. Plauger said:
grep "somefunctionname" *.h is a sight better than grep "somefunctionname" *.*
when I'm looking for a function declaration in a header file.
J
Julie
Rolf said:
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?
J
Jeff Schwab
P.J. Plauger said:
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 /* */.
J
Jeff Schwab
Julie said:
For the OS to neither know nor care about the exact types of files.