"John H. Spicer" wrote:
>
> Fergus Henderson wrote:
> > a9804814@unet.univie.ac.at (Thomas Mang) writes:
> >
> >>BTW, which suffix would you recommend? ".h" is commonly used, but doesn't
> >>make difference between C and C++ language.
> >>Then there are "hpp", "hxx" and some more.
> >
> > I recommend ".hpp".  The standard ought to have recommended that
> > (or ".hxx" -- it doesn't really matter which, just so long as it picked one).
> >
> > [...]
> >
> > That's why the standard should just contain a recommendation, not a
> > requirement.  That is, it should use the word "should" rather than the
> > word "shall".
>
> IMO, the standard should have picked a suffix such as .hpp so that header names
> would be specified using names like <vector.hpp>.  That in no way constrains an
> implementor to actually use .hpp as the underlying file suffix, although most
> would choose to do so.  Likewise, it is no way requires the underlying file
> system to support file extensions.  On such systems the compiler would have to
> map a .hpp name into one without an extension.  The advantage would be that the
> "obvious" implementation would do what most people want -- to have header files
> that can be found by saying "*.hpp".

I take the opposite side. If the suffix used in the actual filename
can be different from the one used inside < > in C++ source files,
why should the language standard choose *the official* suffix (or
extension, or filetype, whatever)? The mapping is up to the
implementation and the standard remains neutral: a nice picture.

I see the #include <...> as something like "use" or "import" directive.
It makes sense because the C++ standard does not require the names
inside < > to be real filenames; they are just names that represent
grouped features in the standard library.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>
> On behalf of programmers using MSWindows ME, MSWindows 98, MSWindows 95,
> etc., I have to ask:
>     "What the heck is a link?"
> (I also use MSWindows NT, MSWindows 2k, MSWindows XP, and sometimes even
> Unix -- and I really do understand what a link is. My point is, not all
> OS's support them -- and they're certainly beyond the definition of C++!)

Neither is the concept of file suffix (or extension, or filetype). :-)
Who knows, if some system might use a file prefix instead?
Choice of filenames should be left to the implementors and users.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Does "#include" specifies an OS-dependent file name,
or a module name?  Typically, implementations do something
in between; for example, many C and C++ implementations
accept "/" even where the operating system expects "\".
I'd prefer

 using "modulename";

but that's not likely to happen.

Given that, I'd argue that #include, with no suffix on
the filename, should be interpreted by implementations as
"accept any file of a type understood by this implementation
as a C or C++ header file".

Unfortunately, there are already libraries out there that
contain instances of, for example, "iostream" and "iostream.h"
in the same directory, so that creates problems.

It's arrogant for C++ to appropriate the null suffix to itself.
Yet more cruft from a bad design decision.

    John Nagle
    Animats

John H. Spicer wrote:

> Fergus Henderson wrote:
>
>> a9804814@unet.univie.ac.at (Thomas Mang) writes:
>>
>>
>>> BTW, which suffix would you recommend? ".h" is commonly used, but
>>> doesn't
>>> make difference between C and C++ language.
>>> Then there are "hpp", "hxx" and some more.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

KIM Seungbeom wrote:
> "John H. Spicer" wrote:
>
>>Fergus Henderson wrote:
>>
>>>a9804814@unet.univie.ac.at (Thomas Mang) writes:
>>>
>>>
>>>>BTW, which suffix would you recommend? ".h" is commonly used, but doesn't
>>>>make difference between C and C++ language.
>>>>Then there are "hpp", "hxx" and some more.
>>>
>>>I recommend ".hpp".  The standard ought to have recommended that
>>>(or ".hxx" -- it doesn't really matter which, just so long as it picked one).
>>>
>>>[...]
>>>
>>>That's why the standard should just contain a recommendation, not a
>>>requirement.  That is, it should use the word "should" rather than the
>>>word "shall".
>>
>>IMO, the standard should have picked a suffix such as .hpp so that header names
>>would be specified using names like <vector.hpp>.  That in no way constrains an
>>implementor to actually use .hpp as the underlying file suffix, although most
>>would choose to do so.  Likewise, it is no way requires the underlying file
>>system to support file extensions.  On such systems the compiler would have to
>>map a .hpp name into one without an extension.  The advantage would be that the
>>"obvious" implementation would do what most people want -- to have header files
>>that can be found by saying "*.hpp".
>
>
> I take the opposite side. If the suffix used in the actual filename
> can be different from the one used inside < > in C++ source files,
> why should the language standard choose *the official* suffix (or
> extension, or filetype, whatever)? The mapping is up to the
> implementation and the standard remains neutral: a nice picture.

That isn't the opposite side, it is the same side.  The only difference between
our two views is what the user puts inside the angle brackets.  You want them to
put something like <vector> that the implementation maps on to an actual file
name while I want them to write <vector.hpp> that the implementation maps on to
an actual file name.  An implementation could map vector.hpp into just vector if
it wanted to (although that would be an odd thing to do).  My proposal would not
require an official suffix/extension for the actual file, just for what the user
writes in his/her program.

John Spicer
Edison Design Group



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> > AFAIK, the implementation may contain the information of the standard-headers anywhere (in a file,
> or somewhere else;
> > in a file with a readable name, or "fhlfhlehrhfhfgoioerna" and so on).
> > It's up to the implementation to map correctly a given standard header #inclusion to the
> corresponding information.
> > How this is done is not a matter of the programmer (well, at least if the implementation manages
> to do it correctly
> > :-( ).
>

>
> And when you need to name the headers *as files*, to look at them with
> an editor or to mention them in a makefile, for example, it makes life
> unnecessarily difficult.

Agree with this.

>
>
> > Indeed, from a technical point of view, I don't see any difference between writing
> > #include <iostream>
> >
> > and
> > #include <iostream.h>
> >
> > The only thing I do here is telling the implementation to include the information provided by what
> shall be in this
> > headers.
>
> One small difference -- the former is conforming C++ while the latter is
> archaic.

I know this. But when writing C++ source-code, it wouldn't make any different to me, if I had to write
<iostream> or <iostream.h>.
The standard chose the first, so I use this.

BTW, which suffix would you recommend? ".h" is commonly used, but doesn't make difference between C and
C++ language.
Then there are "hpp", "hxx" and some more.
Also, as Francis Glassborow pointed out in a post that some OS do not support file extension. The
standard is generally silent on such implementation issues as to where store the #include - information
and so on (Probably not to limit out some systems). Your proposal with file-suffixes and 1:1 mapping to
those files can work against this.
(BTW, I don't even think the standard does require the standard-headers to be in files. I don't know any
hardware that has the appropriate circuits on-board, but actually, why not?
And if the standard starts to define this more closely (file-requirement), than a hell lot other things
would have to change too.)

>
> >         Where this information is actually stored is out of my scope.
>
> Unless you happen to need to refer to the headers as real, live files,
> which is the point I've been making from the outset.

Okay, but isn't this out of scope for the C++ Standard?

>
>
> > The good point of the current syntax is to make it even more different from user-defined included
> files:
> > <name>
> > "name.extension"    (if extensions exist)
>
> Really? I now find that users are writing headers with no extension,
> just like the big boys.

very bad habit.

>
>
> > > It is also commonly the case that directory names have
> > > no extension, and thus it may be difficult to tell a subdirectory name
> > > from an extensionless header file name.
> >
> > It's commonly the case that you cannot use directory-names in preprocessor directives, because you
> may not use
> > certain tokens (including '\', and thus the escape sequences).
>
> It's commonly the case that you *can and do* use directory names
> in preprocessor directives. The Windows-based compilers I've used
> tolerate backslashes in header names with no trouble. Moreover,
> Windows tolerates forward slashes in place of backslashes in many
> contexts.
>
> > This causes undefined behavior by the standard.
>
> No, it's implementation defined.

No, undefined behavior, as the Standard says (let me emphasis I have no doubt it will cause
implementation defined behavior, as described in the paragraph below).

>
> > [My opinion is it will issue an error, or read it as a "normal" token sequence(either on OS-level,
> or C++ level,
> > which I can't say), and then issuing an error if this token sequence makes no sense, or accept it
> and produce the
> > correct behavior as intended by the programmer.
>
> That may be your opinion, but it's not what happens. Note, BTW,
> that in an include directive the double quotes do not delimit
> a string literal but a q-char-sequence, which can be anything
> ``that can be processed by the implementation'' to ``identify
> a header or source file''. It's a similar story for include
> names between angle brackets.
>
> > Truely don't believe it will do anything else; although it may do so, in which case I wouldn't use
> this
> > implementation any more].
>
> Looks like you've put yourself out of the business of compiling
> code.

No, haven't. I just don't use '\' or '\\' and so on in #inclusion. (I've tested it, didn't cause any
problems. And did NOT format my hard-drive, nor had I any fears it would do so. It is nevertheless
certainly more or less OS / compiler specific)


best regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
>
> They don't necessarily have to rename their files.  They may just set
> up links to their files.  I think such a practice is part of software
> installaton procedure.

On some platforms. Not on Windows.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 8 Dec 2002 23:30:05 +0000 (UTC), pjp@dinkumware.com ("P.J.
Plauger") wrote:

> Okay, how do you specify the set of all filenames that don't contain a
> dot with a rather smart command interpreter like bash?

 `ls | grep -v '\.'`

Maybe not what you want, but it seems to answer the stated question.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") writes:

> "Niklas Matthies" <comp.std.c++_2002-12-08@nmhq.net> wrote in message
> news:slrnav58ps.j8.comp.std.c++_2002-12-08@nmhq.net...
[...]
> > > As I've explained more than once, wildcard notation doesn't
> > > easily let you describe the set of all files that lack a .xx
> > > suffix. If you have to talk about groups of headers *as files*,
> > > and many of us do, it's a real pain not to be able to talk about
> > > a group of Standard C++ headers.
> >
> > Only if you restrict yourself to a rather dumb command interpreter
> > like Microsoft's.
>
> Okay, how do you specify the set of all filenames that don't contain a
> dot with a rather smart command interpreter like bash? I haven't figured
> it out yet. You might also spend a few minutes with the MKS shell --
> it has its own curious notions about wildcard matching.

In a Posix environment,

$(ls | grep '^[^.]*$')

is probably the most obvious way.  Shell globbing patterns are weaker
than regular expressions and are probably not powerfull enough for
that.  Now, I'd not be surprised if some shells had full regular
expressions available directly.

Crossposted (and follow-up set) to comp.unix.programmer.

A+

--
Jean-Marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) writes:

>BTW, which suffix would you recommend? ".h" is commonly used, but doesn't
>make difference between C and C++ language.
>Then there are "hpp", "hxx" and some more.

I recommend ".hpp".  The standard ought to have recommended that
(or ".hxx" -- it doesn't really matter which, just so long as it picked one).

>Also, as Francis Glassborow pointed out in a post that some OS do not support file extension. The
>standard is generally silent on such implementation issues as to where store the #include - information
>and so on (Probably not to limit out some systems). Your proposal with file-suffixes and 1:1 mapping to
>those files can work against this.
>(BTW, I don't even think the standard does require the standard-headers to be in files. I don't know any
>hardware that has the appropriate circuits on-board, but actually, why not?
>And if the standard starts to define this more closely (file-requirement), than a hell lot other things
>would have to change too.)

That's why the standard should just contain a recommendation, not a
requirement.  That is, it should use the word "should" rather than the
word "shall".

The Ada standard has a much better treatment of these kinds of
recommendations than the C++ standard.  The Ada standard puts them in
separate "implementation advice" sections.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker wrote:
>
> Gabriel Dos Reis wrote:
> >
> > They don't necessarily have to rename their files.  They may just set
> > up links to their files.  I think such a practice is part of software
> > installaton procedure.
>
> On some platforms. Not on Windows.

On Windows, you can use the pattern "*." - no problem.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) writes:

> Gabriel Dos Reis wrote:
> >
> > They don't necessarily have to rename their files.  They may just set
> > up links to their files.  I think such a practice is part of software
> > installaton procedure.
>
> On some platforms. Not on Windows.

You can use hard links on NTFS (and soft links, for directories, with NTFS
v5), so library vendors could do this if they thought it desirable (with a
fallback to renaming/copying if the installation partition doesn't support it)

Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
> Okay, how do you specify the set of all filenames that don't contain a
> dot with a rather smart command interpreter like bash? I haven't figured
> it out yet.

This is easy in bash once you activate extended globbing:

   shopt -s extglob
   ls +([^.])

Andreas Wickner

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <3dee7fff$0$8067$724ebb72@reader2.ash.ops.us.uu.net>, P.J.
> Plauger <pjp@dinkumware.com> writes
>
>> That's all very well, but the reality is that practically all
>> implementations of the Standard C++ library store the standard headers
>> in files of the same name as the headers. In fact, the only compilers
>> I know that try to use this latitude prove to be even more of a pain
>> than the ones that do the obvious.
>
>
> Well I know of one OS (RiscOS) where there is no such thing as a file
> extension, i.e. x.h is not a legal file name. A C++ compiler (and there
> is one) for this OS has no choice.
>
>
>

I'm not sure what point you are trying to make with that interesting piece of
information.  Surely we don't want to have such idiosyncratic systems dictate
language standards.

Certainly a compiler on that platform would need to map header names with
suffixes into actual file names without suffixes in order to provide any kind of
  program portability.

John Spicer
Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message news:3DEEEF9A.91684FED@bawi.org...

> > -- There's no good wildcard notation for selecting all files
> > without a suffix.
>
> If standard header files are stored as files on the disk,
> in almost all cases they are stored in a separate include directory
> that has only header files, aren't they? I see no problems then.

Perhaps you don't have to deal with groups of headers as much as we
do, but I *do* see problems almost every day. An include directory
typically has a mix of files that match the pattern *.h and those
that, uh, don't match that pattern. Writing a pattern to select the
latter group varies between hard and impossible across systems.

> > Practically speaking, the decision to omit suffixes was a real
> > step backwards.
>
> I support the decision of the Committee because I see it's better
> that we don't have the concept of extensions in the C++ standard.
> Would it be nice for the standard to specify that all C++ header
> files should have extension ".hpp"?

Better than the current choice, practically speaking, yes.

>                                   Probably not. It's the same.
> The choice of the extension should be left to the environment
> and the implementation.

I won't repeat my earlier comments.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote
> "Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote
> > There is no requirement that a header name is actually reflected at
> > the operating system level by a filename with no extension.  An
> > implementation can do a mapping.  In practice, some implementations
> > already do mapping to go behond the 8.3 restrictions of well-known
> > operating systems. There is no reason why a mapping cannot be done for
> > extensionless header name.
>
> That's all very well, but the reality is that practically all
> implementations of the Standard C++ library store the standard headers
> in files of the same name as the headers. In fact, the only compilers
> I know that try to use this latitude prove to be even more of a pain
> than the ones that do the obvious.

But nothing in the language mandates this -- especially for headers in
the standard library! It would have made perfect sense for Windows
compilers to process
    #include <vector>
by reading a file called "vector.hpp". It would have made perfect
sense for Windows compilers to define an environmental variable (or
other setting) "TYPES" with a syntax similar to the
current setting for "INCLUDE" and "LIB".
    INCLUDE=C:\Progra~1\BrandX\C++\INCLUDE;C:\Oracle\INCLUDE
    TYPES=H;HPP;HXX

    // File1.cpp
    #include "myheader"

Looks for C:\Progra~1\BrandX\C++\INCLUDE\myheader.
          C:\Progra~1\BrandX\C++\INCLUDE\myheader.H
          C:\Progra~1\BrandX\C++\INCLUDE\myheader.HPP
          C:\Progra~1\BrandX\C++\INCLUDE\myheader.HXX
          C:\Oracle\INCLUDE\myheader.
          C:\Oracle\INCLUDE\myheader.H
          C:\Oracle\INCLUDE\myheader.HPP
          C:\Oracle\INCLUDE\myheader.HXX
...in that order. The first match is the file processed.

None of the compilers did this. Why not? Was it a difficult piece
of code to write? I think the reason that they didn't do that, was
that having header files without a filetype(*) wasn't that big of
a burden. In Windows, that means you can't double-click on a header
file and have it bring up the editor -- instead, you have to
double-click on the editor and then choose "File/Open", or else you
can double-click on a project file and have it open all the files
in the project.

(*)Windows now calls it "Filetypes" instead of "Extensions." I
think this started with Windows For Workgroups 3.11, back in about
1994.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

>
> But nothing in the language mandates this -- especially for headers in
> the standard library! It would have made perfect sense for Windows
> compilers to process
>     #include <vector>
> by reading a file called "vector.hpp". It would have made perfect
> sense for Windows compilers to define an environmental variable (or
> other setting) "TYPES" with a syntax similar to the
> current setting for "INCLUDE" and "LIB".
>     INCLUDE=C:\Progra~1\BrandX\C++\INCLUDE;C:\Oracle\INCLUDE
>     TYPES=H;HPP;HXX
>
>     // File1.cpp
>     #include "myheader"
>
> Looks for C:\Progra~1\BrandX\C++\INCLUDE\myheader.
>           C:\Progra~1\BrandX\C++\INCLUDE\myheader.H
>           C:\Progra~1\BrandX\C++\INCLUDE\myheader.HPP
>           C:\Progra~1\BrandX\C++\INCLUDE\myheader.HXX
>           C:\Oracle\INCLUDE\myheader.
>           C:\Oracle\INCLUDE\myheader.H
>           C:\Oracle\INCLUDE\myheader.HPP
>           C:\Oracle\INCLUDE\myheader.HXX
> ...in that order. The first match is the file processed.
>
> None of the compilers did this. Why not? Was it a difficult piece
> of code to write? I think the reason that they didn't do that, was
> that having header files without a filetype(*) wasn't that big of
> a burden. In Windows, that means you can't double-click on a header
> file and have it bring up the editor -- instead, you have to
> double-click on the editor and then choose "File/Open", or else you
> can double-click on a project file and have it open all the files
> in the project.
>

As I've mentioned, the EDG front end does provide a facility like this.
Unfortunately, we're the exception and not the rule.  Even among the companies
that base products on our front end, few make use of this facility.

I suspect this is because libraries were implemented either before this facility
was added, or for compilers that don't provide this facility.

John Spicer
Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message news:<3def5777$0$6653$4c41069e@reader0.ash.ops.us.uu.net>...
> "KIM Seungbeom" <musiphil@bawi.org> wrote in message news:3DEEEF9A.91684FED@bawi.org...
>
> > > -- There's no good wildcard notation for selecting all files
> > > without a suffix.
> >
> > If standard header files are stored as files on the disk,
> > in almost all cases they are stored in a separate include directory
> > that has only header files, aren't they? I see no problems then.
>
> Perhaps you don't have to deal with groups of headers as much as we
> do, but I *do* see problems almost every day. An include directory
> typically has a mix of files that match the pattern *.h and those
> that, uh, don't match that pattern. Writing a pattern to select the
> latter group varies between hard and impossible across systems.
>
> > > Practically speaking, the decision to omit suffixes was a real
> > > step backwards.
> >
> > I support the decision of the Committee because I see it's better
> > that we don't have the concept of extensions in the C++ standard.
> > Would it be nice for the standard to specify that all C++ header
> > files should have extension ".hpp"?
>
> Better than the current choice, practically speaking, yes.
>
> >                                   Probably not. It's the same.
> > The choice of the extension should be left to the environment
> > and the implementation.
>
> I won't repeat my earlier comments.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
>

I find myself in complete agreement with P.J. Plauger on this one.
Directories containing header files also often contain template
implementation files and it is tedious and difficult to select just
the header files without a differentiating extension (or file type as
you may say).  It is also commonly the case that directory names have
no extension, and thus it may be difficult to tell a subdirectory name
from an extensionless header file name.

Mandating use of .hpp (or whatever) for header files is almost
certainly a non-starter at this late point in time, but it would,
IMHO, be better than the current situation.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
>
> I find myself in complete agreement with P.J. Plauger on this one.
> Directories containing header files also often contain template
> implementation files and it is tedious and difficult to select just
> the header files without a differentiating extension (or file type as
> you may say).

Why is it difficult?
AFAIK, the implementation may contain the information of the standard-headers anywhere (in a file, or somewhere else;
in a file with a readable name, or "fhlfhlehrhfhfgoioerna" and so on).
It's up to the implementation to map correctly a given standard header #inclusion to the corresponding information.
How this is done is not a matter of the programmer (well, at least if the implementation manages to do it correctly
:-( ).

Indeed, from a technical point of view, I don't see any difference between writing
#include <iostream>

and
#include <iostream.h>

The only thing I do here is telling the implementation to include the information provided by what shall be in this
headers. Where this information is actually stored is out of my scope.

The good point of the current syntax is to make it even more different from user-defined included files:
<name>
"name.extension"    (if extensions exist)


> It is also commonly the case that directory names have
> no extension, and thus it may be difficult to tell a subdirectory name
> from an extensionless header file name.

It's commonly the case that you cannot use directory-names in preprocessor directives, because you may not use
certain tokens (including '\', and thus the escape sequences).

This causes undefined behavior by the standard.

[My opinion is it will issue an error, or read it as a "normal" token sequence(either on OS-level, or C++ level,
which I can't say), and then issuing an error if this token sequence makes no sense, or accept it and produce the
correct behavior as intended by the programmer.
Truely don't believe it will do anything else; although it may do so, in which case I wouldn't use this
implementation any more].


best regards,

Thomas




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Thomas Mang" <a9804814@unet.univie.ac.at> wrote in message
news:3DF1D956.DA53F7CE@unet.univie.ac.at...

> > I find myself in complete agreement with P.J. Plauger on this one.
> > Directories containing header files also often contain template
> > implementation files and it is tedious and difficult to select just
> > the header files without a differentiating extension (or file type as
> > you may say).
>
> Why is it difficult?

As I've explained more than once, wildcard notation doesn't easily
let you describe the set of all files that lack a .xx suffix. If
you have to talk about groups of headers *as files*, and many of us
do, it's a real pain not to be able to talk about a group of Standard
C++ headers.

> AFAIK, the implementation may contain the information of the standard-headers anywhere (in a file,
or somewhere else;
> in a file with a readable name, or "fhlfhlehrhfhfgoioerna" and so on).
> It's up to the implementation to map correctly a given standard header #inclusion to the
corresponding information.
> How this is done is not a matter of the programmer (well, at least if the implementation manages
to do it correctly
> :-( ).

What you keep ignoring is that the vast majority of compilers map
header names directly to filenames. As a general rule, this is a
simple and sane thing to do. So the mere fact that a compiler
*could* help you out by adding suffixes doesn't mean that it *will*.
And when you need to name the headers *as files*, to look at them with
an editor or to mention them in a makefile, for example, it makes life
unnecessarily difficult.

> Indeed, from a technical point of view, I don't see any difference between writing
> #include <iostream>
>
> and
> #include <iostream.h>
>
> The only thing I do here is telling the implementation to include the information provided by what
shall be in this
> headers.

One small difference -- the former is conforming C++ while the latter is
archaic.

>         Where this information is actually stored is out of my scope.

Unless you happen to need to refer to the headers as real, live files,
which is the point I've been making from the outset.

> The good point of the current syntax is to make it even more different from user-defined included
files:
> <name>
> "name.extension"    (if extensions exist)

Really? I now find that users are writing headers with no extension,
just like the big boys.

> > It is also commonly the case that directory names have
> > no extension, and thus it may be difficult to tell a subdirectory name
> > from an extensionless header file name.
>
> It's commonly the case that you cannot use directory-names in preprocessor directives, because you
may not use
> certain tokens (including '\', and thus the escape sequences).

It's commonly the case that you *can and do* use directory names
in preprocessor directives. The Windows-based compilers I've used
tolerate backslashes in header names with no trouble. Moreover,
Windows tolerates forward slashes in place of backslashes in many
contexts.

> This causes undefined behavior by the standard.

No, it's implementation defined.

> [My opinion is it will issue an error, or read it as a "normal" token sequence(either on OS-level,
or C++ level,
> which I can't say), and then issuing an error if this token sequence makes no sense, or accept it
and produce the
> correct behavior as intended by the programmer.

That may be your opinion, but it's not what happens. Note, BTW,
that in an include directive the double quotes do not delimit
a string literal but a q-char-sequence, which can be anything
``that can be processed by the implementation'' to ``identify
a header or source file''. It's a similar story for include
names between angle brackets.

> Truely don't believe it will do anything else; although it may do so, in which case I wouldn't use
this
> implementation any more].

Looks like you've put yourself out of the business of compiling
code.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2002-12-08 01:01, "P.J. Plauger" <pjp@dinkumware.com> wrote:
> "Thomas Mang" <a9804814@unet.univie.ac.at> wrote in message
> news:3DF1D956.DA53F7CE@unet.univie.ac.at...
>
>> > I find myself in complete agreement with P.J. Plauger on this one.
>> > Directories containing header files also often contain template
>> > implementation files and it is tedious and difficult to select just
>> > the header files without a differentiating extension (or file type as
>> > you may say).
>>
>> Why is it difficult?
>
> As I've explained more than once, wildcard notation doesn't easily
> let you describe the set of all files that lack a .xx suffix. If you
> have to talk about groups of headers *as files*, and many of us do,
> it's a real pain not to be able to talk about a group of Standard C++
> headers.

Only if you restrict yourself to a rather dumb command interpreter like
Microsoft's. And even Microsoft commands do understand '*.' to mean
"directory entries without extensions", so 'dir /w /a-d' probably lists
exactly what you want. If everything fails, and for some reason you also
can't involve some free tool like Perl, or a really small C program that
does what you want, then just explicitly enumerate the files. After all,
the set of extension-less standard headers isn't very large, and well-
defined. You'll need to describe in more detail the situations you
experience as being a real pain.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Niklas Matthies" <comp.std.c++_2002-12-08@nmhq.net> wrote in message
news:slrnav58ps.j8.comp.std.c++_2002-12-08@nmhq.net...

> >> > I find myself in complete agreement with P.J. Plauger on this one.
> >> > Directories containing header files also often contain template
> >> > implementation files and it is tedious and difficult to select just
> >> > the header files without a differentiating extension (or file type as
> >> > you may say).
> >>
> >> Why is it difficult?
> >
> > As I've explained more than once, wildcard notation doesn't easily
> > let you describe the set of all files that lack a .xx suffix. If you
> > have to talk about groups of headers *as files*, and many of us do,
> > it's a real pain not to be able to talk about a group of Standard C++
> > headers.
>
> Only if you restrict yourself to a rather dumb command interpreter like
> Microsoft's.

Okay, how do you specify the set of all filenames that don't contain a
dot with a rather smart command interpreter like bash? I haven't figured
it out yet. You might also spend a few minutes with the MKS shell --
it has its own curious notions about wildcard matching.

>              And even Microsoft commands do understand '*.' to mean
> "directory entries without extensions", so 'dir /w /a-d' probably lists
> exactly what you want.

Yep, I know that. Now try the *same* wildcard pattern with an assortment
of utilities and compilers. Each has its own notion of what *. means.
Some have no way of saying the equivalent.

>                       If everything fails, and for some reason you also
> can't involve some free tool like Perl, or a really small C program that
> does what you want, then just explicitly enumerate the files. After all,
> the set of extension-less standard headers isn't very large, and well-
> defined.

Sure I can. I can even use such techniques to define sets of filenames
with an even number of characters, or a given hash code. The point,
once again, is that several decades of software-tools technology goes
out the window as soon as you start dealing with filenames of the
sort mandated by the C++ Standard. I objected at the time the names
were proposed; I got outvoted; and I continue to find nine years later
that my objections were justified.

>         You'll need to describe in more detail the situations you
> experience as being a real pain.

Do I? Why? I've stated my case repeatedly. At least one person has
expressed agreement. If this is not a problem for you, mazeltov.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jhs@edg.com ("John H. Spicer") writes:

[...]

| This doesn't make life easier for library providers though, because if
| they want to make use of this feature they need to rename their files
| depending on the compiler to be used.

They don't necessarily have to rename their files.  They may just set
up links to their files.  I think such a practice is part of software
installaton procedure.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Potter wrote:
> On Sun, 8 Dec 2002 23:30:05 +0000 (UTC), pjp@dinkumware.com ("P.J.
> Plauger") wrote:
>
>
>>Okay, how do you specify the set of all filenames that don't contain a
>>dot with a rather smart command interpreter like bash?
>
>
>  `ls | grep -v '\.'`

On my home Linux system, that needs to be changed to:

 ls -1 | grep -v '\.'

which quite surprised me; I thought that ls was supposed to
automatically produce single column output when not being sent directly
to the terminal? I may have to rewrite some scripts I wrote for an Irix
environment.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote in message news:at1tau$s4t$1@mulga.cs.mu.OZ.AU...
> a9804814@unet.univie.ac.at (Thomas Mang) writes:
>
> >BTW, which suffix would you recommend? ".h" is commonly used, but doesn't
> >make difference between C and C++ language.
> >Then there are "hpp", "hxx" and some more.
>
> I recommend ".hpp".  The standard ought to have recommended that
> (or ".hxx" -- it doesn't really matter which, just so long as it picked one).

WHat difference needs to be made between C and C++ for headers?



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

musiphil@bawi.org (KIM Seungbeom) writes:

| Pete Becker wrote:
| >
| > Gabriel Dos Reis wrote:
| > >
| > > They don't necessarily have to rename their files.  They may just set
| > > up links to their files.  I think such a practice is part of software
| > > installaton procedure.
| >
| > On some platforms. Not on Windows.
|
| On Windows, you can use the pattern "*." - no problem.

I think Pete was talking of the practice of "setting up links to files"
I was referring to in my original message.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Fergus Henderson wrote:
> a9804814@unet.univie.ac.at (Thomas Mang) writes:
>
>
>>BTW, which suffix would you recommend? ".h" is commonly used, but doesn't
>>make difference between C and C++ language.
>>Then there are "hpp", "hxx" and some more.
>
>
> I recommend ".hpp".  The standard ought to have recommended that
> (or ".hxx" -- it doesn't really matter which, just so long as it picked one).
>
>
>>Also, as Francis Glassborow pointed out in a post that some OS do not support file extension. The
>>standard is generally silent on such implementation issues as to where store the #include - information
>>and so on (Probably not to limit out some systems). Your proposal with file-suffixes and 1:1 mapping to
>>those files can work against this.
>>(BTW, I don't even think the standard does require the standard-headers to be in files. I don't know any
>>hardware that has the appropriate circuits on-board, but actually, why not?
>>And if the standard starts to define this more closely (file-requirement), than a hell lot other things
>>would have to change too.)
>
>
> That's why the standard should just contain a recommendation, not a
> requirement.  That is, it should use the word "should" rather than the
> word "shall".
>
> The Ada standard has a much better treatment of these kinds of
> recommendations than the C++ standard.  The Ada standard puts them in
> separate "implementation advice" sections.
>

IMO, the standard should have picked a suffix such as .hpp so that header names
would be specified using names like <vector.hpp>.  That in no way constrains an
implementor to actually use .hpp as the underlying file suffix, although most
would choose to do so.  Likewise, it is no way requires the underlying file
system to support file extensions.  On such systems the compiler would have to
map a .hpp name into one without an extension.  The advantage would be that the
"obvious" implementation would do what most people want -- to have header files
that can be found by saying "*.hpp".

John Spicer
Edison Design Group

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote
> What you keep ignoring is that the vast majority of compilers map
> header names directly to filenames. As a general rule, this is a
> simple and sane thing to do. So the mere fact that a compiler
> *could* help you out by adding suffixes doesn't mean that it *will*.

I'd yell "QOI" if any compilers actually did this. (Yes, EDG does it,
but nobody uses EDG directly -- that's an implementation detail of
compilers we do use.)

> And when you need to name the headers *as files*, to look at them with
> an editor or to mention them in a makefile, for example, it makes life
> unnecessarily difficult.

That makes sense for the standard library implementors such as yourself.
For most C++ programmers, the standard library is considered private;
we would never consider making changes to it (with perhaps the single
exception of patching a known error). Your own library seems to support
such a notation; clearly it is written for the compiler, rather than
for humans. This is reasonable and appropriate since the C++ standard
library is well-documented and that documentation is available for free
from a wide variety of sources, including your own web site.

The reason that this is relevant, is that nothing prevents us from using
a prefix (.h, .hxx, .hpp, or anything else) in our own headers. For
Windows programmers, it's not at all difficult to set things up so that
filename.hxx opens in our favorite C++ editor. Problem solved.

> ... I now find that users are writing headers with no extension,
> just like the big boys.

And users are also prefixing class names with a capital C, based only on
the fact that Microsoft does it. That doesn't make it a good idea.

Let's simplify this desire: "We want include-file name translation."
Perhaps if we say "we want include-file name translation" often enough
here, some of the compiler vendors will actually provide it for us?
If John Spicer's posts mean anything, it means that compilers based on
EDG can already get this feature easily (read: almost for free). Turn
the feature on, test it, document it, done. Once that happens, other
compilers will have an incentive to support it as well...

"We want include-file name translation!"

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) wrote
> BTW, which suffix would you recommend? ".h" is commonly used, but
> doesn't make difference between C and C++ language. Then there
> are "hpp", "hxx" and some more.

I usually use .h, specifically because I do NOT normally need to
differentiate. However, I suppose if you have a header that will
compile in C++ but not in C -- say, if it defined classes -- it
would make sense to use some other name.

> Also, as Francis Glassborow pointed out in a post that some OS
> do not support file extension. The standard is generally silent
> on such implementation issues as to where store the #include -
> information and so on (Probably not to limit out some systems).

> Your proposal with file-suffixes and 1:1 mapping to
> those files can work against this.

Not really -- it just goes the other way. <iostream.h> could simply map
to h-iostream or whatever, while <iostream> maps to iostream.

> (BTW, I don't even think the standard does require the
> standard-headers to be in files.

It doesn't.

> I don't know any hardware that has the appropriate circuits on-board,
> but actually, why not?

I doubt that there will EVER be hardware that has an "std::fopen" or
"std::vector<complex>" circuit on-board; nor do I think it is related
to whether the headers are in files or not.

A more meaningful case to not put standard headers in files, would be
a compiler that literally has the standard library hard-coded. This
hypothetical compiler could simply process
    #include <iostream>
by dumping the various symbols into the symbol table, which would
probably be a lot faster than reading a file. ("Probably" because I
haven't benchmarked it; conceivably, the incresed memory usage might
slow down the general case to the point where most projects lose more
than they gain.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote
> They don't necessarily have to rename their files.  They may just set
> up links to their files.  I think such a practice is part of software
> installaton procedure.

On behalf of programmers using MSWindows ME, MSWindows 98, MSWindows 95,
etc., I have to ask:
    "What the heck is a link?"
(I also use MSWindows NT, MSWindows 2k, MSWindows XP, and sometimes even
Unix -- and I really do understand what a link is. My point is, not all
OS's support them -- and they're certainly beyond the definition of C++!)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
>
> > I don't know any hardware that has the appropriate circuits on-board,
> > but actually, why not?
>
> I doubt that there will EVER be hardware that has an "std::fopen" or
> "std::vector<complex>" circuit on-board; nor do I think it is related
> to whether the headers are in files or not.
>
> A more meaningful case to not put standard headers in files, would be
> a compiler that literally has the standard library hard-coded. This
> hypothetical compiler could simply process
>     #include <iostream>
> by dumping the various symbols into the symbol table, which would
> probably be a lot faster than reading a file. ("Probably" because I
> haven't benchmarked it; conceivably, the incresed memory usage might
> slow down the general case to the point where most projects lose more
> than they gain.)

I absolutely agree that I don't believe too there'll be ever some sort of
"100% hardware-implemented" C++, but just let's see what the future offers
:-).

In practice, though, we can find a midway between your hard-coded example and
th plain text-files: precompiled headers.
It's not uncommon to place header information into a precompiled file with
fast symbol lookup/inline-functions to speed up compilation. So the headers
(note: plurarl) can boil down to *one precompiled file*.


cheers,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> I doubt that there will EVER be hardware that has an "std::fopen" or
> "std::vector<complex>" circuit on-board;

Hey, we used to have lisp machines.  Perhaps we'll have C++ machines.  After
all, at some level of micro/nano/picocode the hardware is just another layer
of software.   ;-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Reimar Grasbon wrote:
>
> BTW: Is there a deeper sense for skipping the ".h"
>      extensions for headers? I think there will be more
>      confusions than clearer codes!?

Before the Standard Era, various extensions had been in use for C++
header files: .h, .hpp, .hxx, .hh, .H, etc. There were no single
(de facto) standard one, so it was not easy for the Committee
to decide on one to favour over all the others. Furthermore, since
the standard headers didn't have to exist in the form of real files,
what was called "extensions" were not really necessary or appropriate.
So it was decided that the standard headers should not have any.
This is what I remember from D&E. Hope this helps.

I was also uncomfortable with the headers without extensions
when I encountered them first, but once I get used to them
they were no problem. I guess it will be the same to you.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"KIM Seungbeom" <musiphil@bawi.org> wrote in message news:3DE39EA9.9D8B7DD4@bawi.org...

> Reimar Grasbon wrote:
> >
> > BTW: Is there a deeper sense for skipping the ".h"
> >      extensions for headers? I think there will be more
> >      confusions than clearer codes!?
>
> Before the Standard Era, various extensions had been in use for C++
> header files: .h, .hpp, .hxx, .hh, .H, etc. There were no single
> (de facto) standard one, so it was not easy for the Committee
> to decide on one to favour over all the others. Furthermore, since
> the standard headers didn't have to exist in the form of real files,
> what was called "extensions" were not really necessary or appropriate.
> So it was decided that the standard headers should not have any.
> This is what I remember from D&E. Hope this helps.
>
> I was also uncomfortable with the headers without extensions
> when I encountered them first, but once I get used to them
> they were no problem. I guess it will be the same to you.

They're a big problem with me, every day and on all platforms:

-- Most versions of Windows won't let you associate a filename
without a suffix with an application.

-- There's no good wildcard notation for selecting all files
without a suffix.

Practically speaking, the decision to omit suffixes was a real
step backwards.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") writes:

[...]

| -- Most versions of Windows won't let you associate a filename
| without a suffix with an application.

There is no requirement that a header name is actually reflected at
the operating system level by a filename with no extension.  An
implementation can do a mapping.  In practice, some implementations
already do mapping to go behond the 8.3 restrictions of well-known
operating systems. There is no reason why a mapping cannot be done for
extensionless header name.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
news:m3wumplaas.fsf@uniton.integrable-solutions.net...

> | -- Most versions of Windows won't let you associate a filename
> | without a suffix with an application.
>
> There is no requirement that a header name is actually reflected at
> the operating system level by a filename with no extension.  An
> implementation can do a mapping.  In practice, some implementations
> already do mapping to go behond the 8.3 restrictions of well-known
> operating systems. There is no reason why a mapping cannot be done for
> extensionless header name.

That's all very well, but the reality is that practically all
implementations of the Standard C++ library store the standard headers
in files of the same name as the headers. In fact, the only compilers
I know that try to use this latitude prove to be even more of a pain
than the ones that do the obvious.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" wrote:
>
> -- There's no good wildcard notation for selecting all files
> without a suffix.

If standard header files are stored as files on the disk,
in almost all cases they are stored in a separate include directory
that has only header files, aren't they? I see no problems then.

>
> Practically speaking, the decision to omit suffixes was a real
> step backwards.

I support the decision of the Committee because I see it's better
that we don't have the concept of extensions in the C++ standard.
Would it be nice for the standard to specify that all C++ header
files should have extension ".hpp"? Probably not. It's the same.
The choice of the extension should be left to the environment
and the implementation.

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
> "Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
> news:m3wumplaas.fsf@uniton.integrable-solutions.net...
>
>
>>| -- Most versions of Windows won't let you associate a filename
>>| without a suffix with an application.
>>
>>There is no requirement that a header name is actually reflected at
>>the operating system level by a filename with no extension.  An
>>implementation can do a mapping.  In practice, some implementations
>>already do mapping to go behond the 8.3 restrictions of well-known
>>operating systems. There is no reason why a mapping cannot be done for
>>extensionless header name.
>
>
> That's all very well, but the reality is that practically all
> implementations of the Standard C++ library store the standard headers
> in files of the same name as the headers. In fact, the only compilers
> I know that try to use this latitude prove to be even more of a pain
> than the ones that do the obvious.
>

The EDG compiler provides a facility to map a header name without a suffix into
a name with one.  For example, the sample headers shipped with our product
include a typeinfo.stdh header that is included when you say "#include <typeinfo>".

This doesn't make life easier for library providers though, because if they want
to make use of this feature they need to rename their files depending on the
compiler to be used.

IMO the idea of having header names without suffixes was an interesting one, but
it oesn't work well in practice.

John Spicer
Edison Design Group


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dee7fff$0$8067$724ebb72@reader2.ash.ops.us.uu.net>, P.J.
Plauger <pjp@dinkumware.com> writes
>That's all very well, but the reality is that practically all
>implementations of the Standard C++ library store the standard headers
>in files of the same name as the headers. In fact, the only compilers
>I know that try to use this latitude prove to be even more of a pain
>than the ones that do the obvious.

Well I know of one OS (RiscOS) where there is no such thing as a file
extension, i.e. x.h is not a legal file name. A C++ compiler (and there
is one) for this OS has no choice.



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]