.h for standard headers

[P.J. Plauger]

Re: .h for standard headers

"Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
news:843a4f78.0 405192221.53739 e0e@posting.goo gle.com...
[color=blue]
> "Tim Clacy" <nospamtcl@nosp amphaseone.nosp amdk> wrote:[color=green]
> > Christopher Benson-Manica wrote:[color=darkred]
> > > 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...[/color]
> >
> > Presumably the idea of omitting an extension was thought up by someone[/color][/color]
who[color=blue][color=green]
> > doesn't use Windows; we have lost the conveniences of double clicking to
> > open and meaningful icon associations in one fell swoop.[/color]
>
> 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.)[/color]

Uh, yes. But what does that have to do with omitting the suffix?
[color=blue]
> There does not have to be any file "iostream", and in fact, the
> implementation does not even have to have a filesystem.[/color]

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.
[color=blue]
> On my Windows system there is in fact only the file "iostream.h ",
> which gets included when you issue the above instruction,[/color]

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.
[color=blue]
> and I can
> still do the double-click trick (which, incidentally, I almost never
> do, since I use a shell with tab completion).[/color]

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]

Re: .h for standard headers

"Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
news:843a4f78.0 405192227.2c16c c2f@posting.goo gle.com...
[color=blue]
> "Duane Hebert" <spoo@flarn2.co m> wrote:
>[color=green]
> > grep "somefunctionna me" *.h is a sight better than grep
> > "somefunctionna me" *.* when I'm looking for a function
> > declaration in a header file.[/color]
>
> "grep foo *.*" will not find things in files that don't contain a dot
> (except on retarded filesystems).[/color]

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.
[color=blue]
> Why not list all your implementation' s
> standard headers into a file (that won't ever need to change),[/color]

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.
[color=blue]
> and then
> you can go:
>
> grep foo *.h `cat stdhdrs`[/color]

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).
[color=blue]
> 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.[/color]

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]

Re: .h for standard headers

P.J. Plauger wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> wrote in message
> news:tpmdnUq1B-wdtDHdRVn-vA@comcast.com. ..
>
>[color=green]
>>P.J. Plauger wrote:
>>[color=darkred]
>>>"Rolf Magnus" <ramagnus@t-online.de> wrote in message
>>>news:c8gpto$ g8h$03$2@news.t-online.com...
>>>
>>>
>>>
>>>>Tim Clacy wrote:
>>>>
>>>>
>>>>
>>>>>We've crossed wires I think. I'm saying that files without an
>>>>>extensio n 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
>>>>braindamage d 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.[/color]
>>
>>What other sorts of files do you store in your "include" directories?[/color]
>
>
> 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.[/color]

:) 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!
[color=blue]
> 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.[/color]

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".
[color=blue][color=green]
>>sometimes have a README file, but it's easy enough to wrap its contents
>>in /* */.[/color]
>
>
> I suppose this is a relevant comment, but I can't imagine how.[/color]

Think harder.

[P.J. Plauger]

Re: .h for standard headers

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:c8i61l$k9i $07$1@news.t-online.com...
[color=blue]
> P.J. Plauger wrote:
>[color=green]
> > "Rolf Magnus" <ramagnus@t-online.de> wrote in message
> > news:c8gpto$g8h $03$2@news.t-online.com...
> >[color=darkred]
> >> 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.[/color]
> >
> > Then call me brain damaged.[/color]
>
> Why? Did you invent it?[/color]

You're being a jerk.
[color=blue][color=green]
> > 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.[/color]
>
> Well, you found it to be the most convenient out of how many different
> ways?[/color]

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?
[color=blue]
> 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.[/color]

And nobody said that it was the only way, just that it's a damned
convenient way that's now gone for C++ headers.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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?
[color=blue][color=green]
> > Absent a simple regular expression, I've found it damned difficult to
> > work with the new C++ style headers on damn near *any* OS.[/color]
>
> What exactly do you mean?[/color]

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.
[color=blue][color=green]
> > Bash Windows if you will,[/color]
>
> This is not about Windows. It's about a concept that (among others)
> Windows just happens to use.[/color]

*Other* people in this thread have tried to make it about Windows.
I agree that it is not.
[color=blue][color=green]
> > or dismiss this as not a problem, but it still annoys me on a daily
> > basis.[/color]
>
> It might be a problem, but I think it's not the C++ standard's task to
> solve it.[/color]

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]

Re: .h for standard headers

Julie wrote:[color=blue]
> Let's try a different tack:
>
> - What was K&R's original intention of appending .h to includes?[/color]

To make the types of files readily apparent to people and tools.
[color=blue]
> - Why is that intention no longer considered valid w/ C++ standard includes?[/color]

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

[P.J. Plauger]

Re: .h for standard headers

"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:ipGdnVwx4N NYNzHdRVn-ug@comcast.com. ..
[color=blue][color=green][color=darkred]
> >>What other sorts of files do you store in your "include" directories?[/color]
> >
> >
> > 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.[/color]
>
> :) 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![/color]

So you *are* telling me that I have bad work habits, however much you
pretend otherwise. Noted.
[color=blue][color=green]
> > 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.[/color]
>
> 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/*.[/color]

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.
[color=blue]
> If you're developing some
> other set of headers, you can call them whatever you like; mine end in
> ".hh".[/color]

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.
[color=blue][color=green][color=darkred]
> >>sometimes have a README file, but it's easy enough to wrap its contents
> >>in /* */.[/color]
> >
> >
> > I suppose this is a relevant comment, but I can't imagine how.[/color]
>
> Think harder.[/color]

Your work habits are not mine.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Jeff Schwab]

Re: .h for standard headers

P.J. Plauger wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> wrote in message
> news:ipGdnVwx4N NYNzHdRVn-ug@comcast.com. ..
>
>[color=green][color=darkred]
>>>>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.[/color]
>>
>>:) 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
>>subsequentl y 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![/color]
>
>
> So you *are* telling me that I have bad work habits, however much you
> pretend otherwise. Noted.
>
>[color=green][color=darkred]
>>>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.[/color]
>>
>>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/*.[/color]
>
>
> 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.
>
>[color=green]
>> If you're developing some
>>other set of headers, you can call them whatever you like; mine end in
>>".hh".[/color]
>
>
> 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.
>
>[color=green][color=darkred]
>>>>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.[/color]
>>
>>Think harder.[/color]
>
>
> Your work habits are not mine.[/color]


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]

Re: .h for standard headers

"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:aO2dneOhE6 ByLjHd4p2dnA@co mcast.com...
[color=blue][color=green]
> > Your work habits are not mine.[/color]
>
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Thanks. Me too.
[color=blue]
> 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.[/color]

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.)
[color=blue]
> 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.[/color]

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).
[color=blue]
> 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.[/color]

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]

Re: .h for standard headers

"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:8YGdnSVu_e xtMTHd4p2dnA@co mcast.com...
[color=blue]
> Julie wrote:[color=green]
> > Let's try a different tack:
> >
> > - What was K&R's original intention of appending .h to includes?[/color]
>
> To make the types of files readily apparent to people and tools.[/color]

Still a good goal.
[color=blue][color=green]
> > - Why is that intention no longer considered valid w/ C++ standard[/color][/color]
includes?[color=blue]
>
> Because a different solution has now become virtually universal: the
> standard includes are stored in a dedicated directory.[/color]

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]

Re: .h for standard headers

Rolf Magnus wrote:[color=blue]
> This is not about Windows. It's about a concept that (among others)
> Windows just happens to use.
>[color=green]
> > or dismiss this as not a problem, but it still annoys me on a daily
> > basis.[/color]
>
> It might be a problem, but I think it's not the C++ standard's task to
> solve it.[/color]

Rolf -- please pay attention.

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

[Julie]

Re: .h for standard headers

Jeff Schwab wrote:[color=blue]
>
> Julie wrote:[color=green]
> > Let's try a different tack:
> >
> > - What was K&R's original intention of appending .h to includes?[/color]
>
> To make the types of files readily apparent to people and tools.
>[color=green]
> > - Why is that intention no longer considered valid w/ C++ standard includes?[/color]
>
> Because a different solution has now become virtually universal: the
> standard includes are stored in a dedicated directory.[/color]

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_standardiza tion -- 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]

Re: .h for standard headers


"Old Wolf" <oldwolf@inspir e.net.nz> wrote in message
news:843a4f78.0 405192227.2c16c c2f@posting.goo gle.com...[color=blue]
> "Duane Hebert" <spoo@flarn2.co m> wrote:
>[color=green]
> > grep "somefunctionna me" *.h is a sight better than grep
> > "somefunctionna me" *.* when I'm looking for a function
> > declaration in a header file.[/color]
>
> "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.[/color]

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

[Minti]

Re: .h for standard headers

oldwolf@inspire .net.nz (Old Wolf) wrote in message news:<843a4f78. 0405192221.5373 9e0e@posting.go ogle.com>...[color=blue]
> "Tim Clacy" <nospamtcl@nosp amphaseone.nosp amdk> wrote:[color=green]
> > Christopher Benson-Manica wrote:[color=darkred]
> > > 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...[/color]
> >
> > 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.[/color]
>
> 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.[/color]

As pjp has already remarked you are using a preprocessor directive not
an instruction.
[color=blue]
>
> On my Windows system there is in fact only the file "iostream.h ",
> which gets included when you issue the above instruction,[/color]

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

namespace std{
#include <iostream.h>
}[color=blue]
> and I can
> still do the double-click trick (which, incidentally, I almost never
> do, since I use a shell with tab completion).[/color]

--
Imanpreet Singh Arora

[Minti]

Re: .h for standard headers

Julie <julie@nospam.c om> wrote in message news:<40AC3C33. 38F777B2@nospam .com>...[color=blue]
> 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?[/color]


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.

--
Imanpreet Singh Arora
i"kaur" At acm DOT org
Replace "kaur" by "singh"

[Old Wolf]

Re: .h for standard headers

"P.J. Plauger" <pjp@dinkumware .com> wrote:[color=blue]
> "Old Wolf" <oldwolf@inspir e.net.nz> wrote:[/color]
[color=blue][color=green]
> > 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.)[/color]
>
> Uh, yes. But what does that have to do with omitting the suffix?[/color]

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.
[color=blue][color=green]
> > On my Windows system there is in fact only the file "iostream.h ",
> > which gets included when you issue the above instruction,[/color]
>
> 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.[/color]

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.