scotty@cinenet.net (J Scott Peter XXXIII i/iii) wrote:

>Exactly.  I guess I was unaware that the new standard changes the meaning of
>#include to no longer be "include this file".  In MSVC 4.2, the new C++
>headers have no file extension, which is really obnoxious.  I agree with
>Ken: Since #include has until now meant "include this file", the easiest way
>for vendors to implement the standard meaning of "#include <iostream>" is to
>create a file named "iostream".

With the 5.0 version of their compiler, Borland changed the rules for
#include so that "if the filename doesn't have an extension, the
filename will be shortened to 8 characters and a .h will be appended to
the end". This has worked out great, because it means that you can

#include <strstream>

and it will end up including the file "strstrea.h". This allows them to
put the full source and includes on the CDROM (which is limited to 8.3
filenames) for reference purposes without worrying about mapping the
filenames or doing anything weird.

---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <55njrf$2uk6$1@news-s01.ca.us.ibm.net>, icedancer@ibm.net
(Ken Walter) wrote:
> In message <WALD.96Nov3111616@peacock.lcs.mit.edu> - wald@theory.lcs.mit.edu
> (David Wald)4 Nov 1996 16:08:59 GMT writes:
> :>
> :>In article <55h4cn$e44@marina.cinenet.net> scotty@cinenet.net (J Scott
> :>Peter XXXIII i/iii) writes:
> :>>Making it a standard that C++ header files have no extension at all
> :>>is a really, really bad mistake. [...]
> :>
> :>Hasn't it been pointed out several times already that the standard
> :>makes no requirement at all about C++ header file extensions?  All it
> :>gives is the standard way to ask for one of the standard headers,
> :>without dictating in any way how that maps onto the file system.
>
> True, BUT from my experience there will be implementations that take
> the path of least effort and take it as the file name.

Exactly.  I guess I was unaware that the new standard changes the meaning of
#include to no longer be "include this file".  In MSVC 4.2, the new C++
headers have no file extension, which is really obnoxious.  I agree with
Ken: Since #include has until now meant "include this file", the easiest way
for vendors to implement the standard meaning of "#include <iostream>" is to
create a file named "iostream".

This seems to be overloading the function of the C preprocessor beyond that
of a brain-dead text processor that we should be trying to find ways to get
rid of.  Why didn't the committee create a proper "import" statement
instead?

---
John Scott Peter XXXIII i/iii  // Wrong thinking is punishable.
Software Engineer             // Right thinking will be as quickly rewarded.
Venice, CA                   // You will find it an effective combination.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <55h4cn$e44@marina.cinenet.net> scotty@cinenet.net (J Scott
Peter XXXIII i/iii) writes:
>Making it a standard that C++ header files have no extension at all
>is a really, really bad mistake. [...]

Hasn't it been pointed out several times already that the standard
makes no requirement at all about C++ header file extensions?  All it
gives is the standard way to ask for one of the standard headers,
without dictating in any way how that maps onto the file system.

-David


--
============================================================================
David Wald      http://theory.lcs.mit.edu/~wald/     wald@theory.lcs.mit.edu
============================================================================


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J Scott Peter XXXIII i/iii (scotty@cinenet.net) wrote:

> Making it a standard that C++ header files have no extension at all is a
> really, really bad mistake.  On many systems, it screws up the file system
> interface, and makes C++ header files, alone of all the zillions of file
> types you might have on your disk, look really weird.  The header files
> should have *some* extension, different from .h if need be. Why not .hpp, or
> hh, or .hs, or something?

The standard does not say anything about extensions of C++ header
files.  In particular, it does not say that C++ header files should
have no extension at all.  As a corollary, no "really, really bad
mistake" took place.

--
blue | Ken; Shan, Chung-chieh; Sian7, Tiong1-kiat8; ccshan@fas.harvard.edu.
 ()  | Your code today becomes the mind tomorrow:  Your plan its means,
 /\  | your dream its ends, your ideal its elegance.  Hack on.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

J Scott Peter XXXIII i/iii wrote:
> Making it a standard that C++ header files have no extension at all is a
> really, really bad mistake.  On many systems, it screws up the file system
> interface, and makes C++ header files, alone of all the zillions of file
> types you might have on your disk, look really weird.  The header files
> should have *some* extension, different from .h if need be. Why not .hpp, or
> hh, or .hs, or something?

The working paper DOES NOT SAY that C++ header files have no extension.
It says nothing whatsoever about the names of the header files. What is
says is that when you use iostreams your code should contain the
directive

#include <iostream>

What the compiler then does to get the names and types to use streams is
up to the compiler. BC++, for example, appends a .h to the name in the
brackets and looks for a file with that name.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pete Becker wrote:
> The working paper DOES NOT SAY that C++ header files have no extension.

I believe it doesn't even mention header _files_.
The September version says in [lib.headers]:

15) A header is not necessarily a source file, nor are  the  sequences
    delimited  by  <  and  > in header names necessarily valid source file
    names.

But [cpp.include] does require files, it seems:

5 There shall be an implementation-defined mapping between the delimited
  sequence and the external source file name.


It is often mentioned here that the declarations could be contained
in whatever form in whichever database, for example as precompiled
headers.  But in my experience (Borland & Watcom), these become very
large or are not reused, and require compiler specific code tailoring,
due to the reasons explained in Stroustrup's Design and Evolution of C++.

OTOH, imagine something as simple as storing headers inside the
compiled library file (lib*.a or *.lib or whatever).  That would
certainly simplify version management.  But it seems everyone has
a guy like me doing that for them.

By the way, will the following remain valid C++ source code?

+----- x.cpp ------+   +-- int.h --+   +-- end.h --+
| #include "int.h" |   | int       |   | ;         |
| variable         |   +-----------+   +-----------+
| #include "end.h" |
+------------------+

And is this required to define an ios::append flag?  (since app isn't
a keyword or alternative representation of operators or preceded
by double underscores)?

+---- y.cpp ----------+
| #define app append  |
| #include <iostream> |
+---------------------+

If so, I have no hope for any of that fancy precompiling stuff.

--
Stein Somers
Software engineer
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In message <WALD.96Nov3111616@peacock.lcs.mit.edu> - wald@theory.lcs.mit.edu
(David Wald)4 Nov 1996 16:08:59 GMT writes:
:>
:>In article <55h4cn$e44@marina.cinenet.net> scotty@cinenet.net (J Scott
:>Peter XXXIII i/iii) writes:
:>>Making it a standard that C++ header files have no extension at all
:>>is a really, really bad mistake. [...]
:>
:>Hasn't it been pointed out several times already that the standard
:>makes no requirement at all about C++ header file extensions?  All it
:>gives is the standard way to ask for one of the standard headers,
:>without dictating in any way how that maps onto the file system.
:>

True, BUT from my experience there will be implementations that take
the path of least effort and take it as the file name.

Any concept where the least effort is the undesirable outcome is
bound to occur and plague the users to no end.

Ken Walter

All the above is hearsay and the opinion of no one in particular.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mike Enright wrote:
>
> ark@research.att.com (Andrew Koenig) wrote:
>
> >In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe)
> >writes:
> >
> >> *WHY* does the new C++ standard get rid of ".h" extension for
> >> standard headers?
> >
> > Because the new standard headers do different things from any
> > existing headers (particularly in introducing names into namespace
> > std, rather than the global namespace), so they should have
> > different names.
> >
> >> There must be one heck of a good reason to do this, since
> >> it obviously will cause a great deal of grief.
> >
> >Obviously?  Why?

I'm am new to reading this group, but I think the biggest rational
(IMO) for having "extensions" is for classifying files.  I think that
the standard should "suggest" that IFF files are used to implement
the feature being discussed, that the filenames should be *.stdhpp
or *.shp (for implementations that like 3 chars) or something like this.

Since,
(1) the draft standard does not require #include "iostream" (and
    others) to be implemented as files, and
(2) since it is desirable for these files (IMO) to have some extension,

then the (next) standard could recommend that the extension *.stdhpp
(or *.shp) be used IFF this feature is implemented using files.

-- patrick --
steranka@steranka.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <clamage@taumet.Eng.Sun.COM> wrote:
: The C++ committee decided in 1991 to make this point more obvious by
: eliminating the ".h" from the C++ standard header names, thus
: discriminating equally against all implementations. :-)  Now you write,
: for example, <iostream>, and you might wind up getting a header file whose
: name is iostream.h, iostream.H, iostream.hpp, iostream.hxx, iostream.h++,
: or "zxcvbnm". (Or perhaps the implementation doesn't use actual files.)
not exactly - there's an equal probability that they caved in to vendors
with non-file header implementations (such as DEC and IBM).

--
Thomas E. Dickey
dickey@clark.net
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ark@research.att.com (Andrew Koenig) wrote:

>In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe) writes:
>
>> *WHY* does the new C++ standard get rid of ".h" extension for standard headers?
>
>Because the new standard headers do different things from any existing
>headers (particularly in introducing names into namespace std, rather than
>the global namespace), so they should have different names.
>
>> There must be one heck of a good reason to do this, since it obviously will
>> cause a great deal of grief.
>
>Obviously?  Why?
>
>
<snip>
>But standard headers are not required to be stored in source files,
>so ending the names with .h or not doesn't matter.
>
<snip>
>
>Not only does the C standard not mandate any particular header names,
>it also does not require the name of any header to match the name of
>the file that implements it.  That is, if you say   #include "foo.h"
>there is a requirement that the implementation tell you the name of the
>file that will be copied, but the file is not required to be named
>foo.h .  C++ follows C in that regard.

They supplied a iostream.h AND an iostream file with the compiler I
use, and they ARE different. I've read the public DWP enough to see
that headers were refered to as <headername> and I wasn't concerned; I
assumed that if I stuck with the same compiler vendor the names of the
real files would not go wacky on me. Perhaps part of the committee
needs to clarify to the other part of the committee just what was
intended by the notation in the DWP, seeing as how so many compiler
vendors supposedly belong to the committee.

I wouldn't have cared if "#include <map.h>" had worked.


--
Mike Enright
menright@cts.com
http://www.users.cts.com/sd/m/menright
Cardiff-by-the-Sea, California, USA
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 378530180@news3.cts.com, menright@cts.com (Mike Enright) writes:
>
>They supplied a iostream.h AND an iostream file with the compiler I
>use, and they ARE different. I've read the public DWP enough to see
>that headers were refered to as <headername> and I wasn't concerned; I
>assumed that if I stuck with the same compiler vendor the names of the
>real files would not go wacky on me.

In an earlier article I opined that <iostream> and <iostream.h> would
be likely to reference the same file. I mis-spoke, as someone else
pointed out.

The draft standard says that, for example,
 #include <iostream>
will cause various iostream declarations and definitions to appear in
the program, but in the "std" namespace. That namespace is new. The
draft standard does not mention <iostream.h>, nor does it mention
<iostream.hpp> nor <iostream.hxx> nor any other variation. Those older
headers would have placed the iostream names in the global namespace.
Similar considerations apply to the other C++ (but not the C) headers.

Let's suppose an existing implementation used ".h" as the suffix on
standard header names. The following program should work:
 #include <iostream.h>
 int main() { cout << "hello, world\n"; return 0; }

Now we upgrade the implementation to use namespaces, the new header
names, the new standard library, and so on. I could change my program
to look like this (among other possibilities):
 #include <iostream>  // no ".h" on header name
 using namespace std; // new
 int main() { cout << "hello, world\n"; return 0; } // unchanged
The modified code should work with the new C++ implementation.

But what happens if I try to compile the old version of the program?
The standard doesn't say. That means two things:
1. I can't depend on the code working on any arbitrary standard implementation.
2. An implementation is allowed to accept that code and let it do what
it used to do.

For #1, the old code wouldn't worked on all systems anyway, since some
would have required <iostream.hpp> or <iostream.hxx> instead.

But as a loyal customer of the vendor, I would expect my code not to
be broken unnecessarily, and it this case it isn't necessary.

If <iostream> and <iostream.h> had the same effect, then cout and
its operator<< would be in the std namespace, and my old code wouldn't
work without additional declarations or qualifications. So I would
expect <iostream> and <iostream.h> to have different effects. Namely,
I would expect <iostream.h> to put the declarations in the global
namespace so old code would continue to work, although <iostream> must
not do so.

A simple way for the vendor to satisfy the requirements of the standard
and also not break existing customer code is to define
 #include <iostream.h>
(or <iostream.hpp> or <iostream.hxx>) to have the effect of
 #include <iostream> // new header with decls in "std"
 using std::cout;    // bring all the decls into the global namespace
 using std::cin;
 using std::ostream;
 using std::istream;
 ... etc

Please notice that I still haven't said anything about files or file
names. Whether an implementation uses text files and what names they
might have and where they are located are independent of all the above
considerations.

The standard headers inherited from C are a different story. The effect of
 #include <stdio.h>
is defined by the C++ standard, since the standard C spelling of the
header name is "stdio.h". C++ adds a new option,
 #include <cstdio>
which places the stdio names in "std" instead of in the global namespace.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <52jgs2$o9k@clarknet.clark.net> dickey@clark.net (T.E.Dickey) writes:

> not exactly - there's an equal probability that they caved in to vendors
> with non-file header implementations (such as DEC and IBM).

As far as I know, the idea of eliminating the suffix was mine originally.
I made that suggestion because I knew that the standard headers would
differ in content from all C++ headers that presently exist, so I wanted
to choose a naming convention that would not conflict with any existing
vendor.  Vendors used so many suffixes that I figured the best way to
avoid hitting any of them would be to use no suffix at all.
--
    --Andrew Koenig
      ark@research.att.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <u9ybhz6zlt.fsf@yorick.cygnus.com> Jason Merrill
<jason@cygnus.com> writes:

|> >>>>> Pete Becker <pbecker@oec.com> writes:

|> > Then you will be pleasantly surprised with BC++ 5.0. All of the standard
|> > #include directives map to files with .h extensions.

|> So what do you do with <string>?

Something intelligent, maybe:-).  I have no idea what Borland actually
does, but since <string> and <string.h> are distinct strings, I see no
reason why they have to be mapped the same.  Under Unix, for example,
one might have:

 <string> ==> /some/prefix/include/CC/string.h
 <string.h> ==> /some/prefix/include/C/string.h

This is, of course, just an example.  Other solutions are possible.

(From a strictly standards point of view, there is no problem, because
there is no file <string.h> in the C++ standard, only <cstring>.  I
rather suspect, however, that taking this too literally would not be
particularly productive.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Jason Merrill wrote:
>
> >>>>> Pete Becker <pbecker@oec.com> writes:
>
> > Then you will be pleasantly surprised with BC++ 5.0. All of the standard
> > #include directives map to files with .h extensions.
>
> So what do you do with <string>?

Compiler magic. It works.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 96Sep26180330@slsvhkt.lts.sel.alcatel.de, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>does, but since <string> and <string.h> are distinct strings, I see no
>reason why they have to be mapped the same.  Under Unix, for example,
>one might have:
>
> <string> ==> /some/prefix/include/CC/string.h
> <string.h> ==> /some/prefix/include/C/string.h
>
>This is, of course, just an example.  Other solutions are possible.
>
>(From a strictly standards point of view, there is no problem, because
>there is no file <string.h> in the C++ standard, only <cstring>.  I
>rather suspect, however, that taking this too literally would not be
>particularly productive.)

That last part is not quite correct.

I don't wish to keep harping on this point, but no files at all are
required by the standard to implement the standard headers. Nevertheless,
the directive
 #include <string.h>
is well-defined in C++. It has the effect of the directive
 #include <cstring>
followed by a using-directive for every name in the header. The net
result is for most practical purposes the same as the result of the directive
 #include <string.h>
in a C program.

The example you show above would be a reasonable way to allow both <string>
and <string.h> to map to different files each called string.h. We still
need to handle <cstring>, so I would add another mapping, resulting in
something like this:
 <string> ==> /some/prefix/include/CC/string.h  // C++ string class
 <cstring> ==> /some/prefix/include/CC/cstring.h // C string.h
 <string.h> ==> /some/prefix/include/C/string.h   // C string.h

The implementation of the <string.h> file might look like this:
 #include "../CC/cstring.h" // all decls in "std" namespace
 using std::strlen;         // bring all decls into global namespace
 using std::strcmp;
 using std::strcpy;
 ... etc

Such an implementation would meet all the requirements of the standard,
would be unsurprising to users of the C++ implementation, would not
break many software tools, and would be reasonably easy for the C++
vendor to maintain.

---
Steve Clamage, stephen.clamage@eng.sun.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze US/ESC 60/3/141 #40763 wrote:
>
> In article <u9ybhz6zlt.fsf@yorick.cygnus.com> Jason Merrill
> <jason@cygnus.com> writes:
>
> |> >>>>> Pete Becker <pbecker@oec.com> writes:
>
> |> > Then you will be pleasantly surprised with BC++ 5.0. All of the standard
> |> > #include directives map to files with .h extensions.
>
> |> So what do you do with <string>?
>
> Something intelligent, maybe:-).  I have no idea what Borland actually
> does, but since <string> and <string.h> are distinct strings, I see no
> reason why they have to be mapped the same.  Under Unix, for example,
> one might have:
>
>         <string> ==>    /some/prefix/include/CC/string.h
>         <string.h> ==>  /some/prefix/include/C/string.h
>
> This is, of course, just an example.  Other solutions are possible.
>
> (From a strictly standards point of view, there is no problem, because
> there is no file <string.h> in the C++ standard, only <cstring>.  I
> rather suspect, however, that taking this too literally would not be
> particularly productive.)

 I suppose my other answer was a bit glib. What we do is define a
special symbol for the preprocessor. string.h actually contains both the
C header and the C++ header, and you get one or the other depending on
whether that symbol is defined.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Pete Becker <pbecker@oec.com> writes:
>
>> Then you will be pleasantly surprised with BC++ 5.0. All of the standard
>> #include directives map to files with .h extensions.
>
>So what do you do with <string>?

#ifdef __cplusplus
#include <string.cc>
#endif



---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> > Then you will be pleasantly surprised with BC++ 5.0. All of the
standard
> > #include directives map to files with .h extensions.

> So what do you do with <string>?

They merged <string.h> and <string> into the same file. Go figure.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Sean L. Palmer wrote:
>
> > > Then you will be pleasantly surprised with BC++ 5.0. All of the
> standard
> > > #include directives map to files with .h extensions.
>
> > So what do you do with <string>?
>
> They merged <string.h> and <string> into the same file. Go figure.

What's the point of this comment? Is there some way in which this
implementation does not conform to the working paper?


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>> There must be one heck of a good reason to do this, since it obviously will
>> cause a great deal of grief.

>Obviously?  Why?

OK, it doesn't cause any 1 programmer a great deal of trouble, but it does
cause a little trouble to a *lot* of people.

I don't really want to raise a big stink about this issue, but it really
irritates me how many things in the C++ language, if done ever so slightly
differently, would simplify things for programmers.

Header file names is a really god example.

As far as the language is concerned, it does not matter one wit how the text of
a program is stored, or what the filenames *really* are. (assuming they are
stored in files at all, of course).
On the other hand, as far as everyday progamming tasks are concerned, it *does*
matter. So why *not* specify that the names of all std C++ headers files have a
trailing ".h"?


By *not* specifing this, *most* compiler implementations will have files named
"vector" and "allocator", etc., with no filename extension.

There are many other problems created by this *deficiency* in the standard.
Ever had to create a portable program?
 At one point, we were developing a program for 2 different platforms.
 On Platform A, the compiler would accept ".CC" and ".cpp".
 On Platform B, the compiler would accept ".cxx" or ".C".
 We actually had to binary-edit one of the compilers to get them to agree on
 filenames.


>> This causes a lot of grief.
>>  o Suddenly, you can't do stuff like "grep foo *.h" anymore.

>Implementations are not required to implement the standard headers as
>text files at all, so in principle there's no difference.  Those that

Yes, but, 99.99% of all compilers *do* store them in text files of exactly
the same same as which appears in the #include statement. Its  not like
this is the unusual case.

Does it cause any trouble, for those compilers which store headers in some other
way, to have ".h" appended? (or .your-choice-of-extension)
>>  o Text editors have a harder time doing context highlighting.

>Beg pardon?

Many text editors do language sensitive context-highlighting based on
filename. Typically they have a table that says:
 *.h, *.c, *.cpp, *.cxx, (etc)    These are C/C++ source files
 *.asm, *.i                       These are assembly source files
 *.f                              These are fortran files.

So now are we supposed to add
 *                                This *might* be a std C++ header

Using this trivially simple match based on filename happens to be *really*
effective, and allows non-C++ compilers to determine that a given file is
either C or C++, and do something intelligent based on that fact.


>>  o Programmers have a harder time picking out source files from others

>Programmers can (still) name their source files anything they like.

Yes, but most programmers cannot pick how the std headers are named - their
compiler vendor does that.
And, in 99% (a guess, but I'm sure its pretty close to being accurate) of the
compilers *will* (or already do) named the headers exactly as they appear in
the #include statements.

>>  o Basically, anything which has been automated to work on C/C++ files
>>           (based on filename) will miss things such as "vector".

>But standard headers are not required to be stored in source files,
>so ending the names with .h or not doesn't matter.

Theoretically, it does not matter.
Practically it *DOES* matter.

Haven't you ever had to search thru the std headers for something with grep
or something similar?


>> If anything, I would have expected the standard to *mandate" usage of ".h" and
>> ".cpp". (Not that I care much about exactly which extension, just so that there
>> is a standard filename extension).

>Not only does the C standard not mandate any particular header names,
>it also does not require the name of any header to match the name of

Yes, I know it doesn't.
It sure would simplify things a lot if it *did* though.
What would it hurt, anyway?



Isn't it amazing the little things, which should not matter, but *DO* matter??


If the standard said that it must be <vector.header> (rather than just
<vector>), any particular implementation *could* just as easily change
that name into whathever happens to be handy for it.





[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article mil@handupme.avid.com, joe@vixa.voyager.net (joe) writes:
>
>OK, it doesn't cause any 1 programmer a great deal of trouble, but it does
>cause a little trouble to a *lot* of people.

I wonder how many people, in light of the differences among systems.

>As far as the language is concerned, it does not matter one wit how the text of
>a program is stored, or what the filenames *really* are. (assuming they are
>stored in files at all, of course).
>On the other hand, as far as everyday progamming tasks are concerned, it *does*
>matter. So why *not* specify that the names of all std C++ headers files have a
>trailing ".h"?

As I explained in an earlier article, there was no standard among
existing implementations. Many used ".h", but many used other suffixes.
I have seen ".H", ".hh", ".hpp", ".h++", and ".hxx", for example.
If we had enshrined ".h", that would have discriminated against other
conventions.

In addition, we on the C++ Committee knew we would have a string class,
and the spelling <string.h> was already taken. If we added a time class,
the spelling <time.h> was already taken. And so on. We finessed ALL those
issues by eliminating the suffix from the spelling of the header name.
No implementation was favored over any other, and no conflict between
C and C++ header names would occur.

>By *not* specifing this, *most* compiler implementations will have files named
>"vector" and "allocator", etc., with no filename extension.

Why do you say that? Do you think an implementor is going to abandon
the local convention for file names? That would be exceptionally foolish.
If on a particular system the convention is to use ".hh" for C++ header
*files*, I would expect the new header *files* to have that same suffix.
In addition, if the implementatation previously used <iostream.hh>, I would
expect <iostream.hh> to continue to be supported, and to mean the same thing
as <iostream>. A vendor who did otherwise would antagonize the majority
of users. Most vendors prefer to please their customers, and not make
life unnecessarily difficult for them. Nothing in the draft standard's
requirements on header names makes portability any harder than it
already was, and the draft creates portability where none existed before.

>There are many other problems created by this *deficiency* in the standard.
>Ever had to create a portable program?
> At one point, we were developing a program for 2 different platforms.
> On Platform A, the compiler would accept ".CC" and ".cpp".
> On Platform B, the compiler would accept ".cxx" or ".C".
> We actually had to binary-edit one of the compilers to get them to agree on
> filenames.

That is not a standards issue. The standard makes absolutely no statement
about source file name spellings. Compilers I have used on different
platforms were very forgiving about extensions. Certain default file name
extensions were recognized, but a flag allowed the use of any reasonable
extension. If you have a less flexible implementation, complain to the
vendor. The standard will never address that subject. (more below)

>Haven't you ever had to search thru the std headers for something with grep
>or something similar?

Yes. I do something like
 cd /wherever/the/standard/headers/live
 grep whatever *
There is nothing in that directory but system headers, so I don't
really care how the file names are spelled. There may be some, but
I have never seen an implementation that mixed system headers in
with other, unrelated files.

>>Not only does the C standard not mandate any particular header names,
>>it also does not require the name of any header to match the name of
>
>Yes, I know it doesn't.
>It sure would simplify things a lot if it *did* though.
>What would it hurt, anyway?

It would hurt every vendor and every user which customarily used
other extensions. There is no one existing practice to standardize.

There is not even a requirement that files be used. Some implementations
have integrated development systems that don't use text files for
source code. (The editor stores parsed versions of the code as binary
files, and reconstructs source on the fly for display.) How would you go
about testing compliance with the standard for file names?

>If the standard said that it must be <vector.header> (rather than just
><vector>), any particular implementation *could* just as easily change
>that name into whathever happens to be handy for it.

Yes indeed. In fact, that is exactly what the C++ Committee decided on --
except that we elected to spell ".header" as "". You could submit a
proposal to change the spellings from <name> to <name.header>.

To repeat, the only place header names can standardly appear are in
preprocessor statement of the form
 # include < header >
In addition, you can't put anything else in the brackets but a standard
header name. Any other use of the spellings of the standard header names
is inherently unportable. If the standard forced certain conventions on
file names, it would effectively prohibit advances in program development
technology.

---
Steve Clamage, stephen.clamage@eng.sun.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>By *not* specifing this, *most* compiler implementations will have files named
>>"vector" and "allocator", etc., with no filename extension.

>Why do you say that? Do you think an implementor is going to abandon
>the local convention for file names? That would be exceptionally foolish.
>If on a particular system the convention is to use ".hh" for C++ header

Microsoft VisualC++ 4.2 does exactly this.
Previously *all* compiler supplied headers were <foo.h>
In its header directory, there is a mix of files named *.h and * (no extension)
User created headers have no naming restrictions, beyond the filesystem
requirements.

Anybody from the MS VC++ development team listening in?


I would be suprised to find a compiler which uses a (UNIX-similar) filesystem
to store its headers to do otherwise. (Pleasently suprised)


>>There are many other problems created by this *deficiency* in the standard.
>>Ever had to create a portable program?
>> At one point, we were developing a program for 2 different platforms.
>> On Platform A, the compiler would accept ".CC" and ".cpp".
>> On Platform B, the compiler would accept ".cxx" or ".C".
>> We actually had to binary-edit one of the compilers to get them to agree on
>> filenames.

>That is not a standards issue. The standard makes absolutely no statement
>about source file name spellings. Compilers I have used on different
>platforms were very forgiving about extensions. Certain default file name

You have been lucky.
Not all compilers are so forgiving, and not all vendors listen very well,
especially to "small" customers.
(Finally all the compilers I use have fixed that problem)

The point is, that by including naming conventions in the standard you would:
 o Piss off a lot of people for about 1 year
 o Generally improve the portability of the language forever.


Does the standard have any portions which are recommended but not required?
If so, this would be the place for filename conventions.

>Yes. I do something like
> cd /wherever/the/standard/headers/live
> grep whatever *
>There is nothing in that directory but system headers, so I don't

Yes but.
If you use the same tool in the standard headers, and your own headers,
"*" matchs object files, pictures, executables, etc....



>To repeat, the only place header names can standardly appear are in
>preprocessor statement of the form
> # include < header >
>In addition, you can't put anything else in the brackets but a standard
>header name. Any other use of the spellings of the standard header names

Really? How strongly is that specified?

The current compilers I use, the only difference between
 #include "foo.h" and #include <foo.h>
is where the compiler looks for headers.
Usually, #include "stdio.h" works.
Often, #include <myheader.h> works too.

So is it guaranteed that
 #include "vector"  and
 #include <myheader.h>
will both fail? This would be a good thing.




[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 4po@handupme.avid.com, joe@vixa.voyager.net (joe) writes:

>>To repeat, the only place header names can standardly appear are in
>>preprocessor statement of the form
>> # include < header >
>>In addition, you can't put anything else in the brackets but a standard
>>header name. Any other use of the spellings of the standard header names
>
>Really? How strongly is that specified?
>
>...
>
>So is it guaranteed that
> #include "vector"  and
> #include <myheader.h>
>will both fail? This would be a good thing.

Where I said "standardly" above I meant to say "portably". The entire
area is implemenatation-defined, except that
 #include <header>
has well-defined results if "header" is the name of a standard header.
Note: "results", not "process". The implementation is allowed
considerable latitude in exactly what it does in response to that
directive, but the result must be that specified things become declared
and defined after the processing happens.

If you write either of
 #include "vector"
 #include <myheader.h>
the implementation has to tell you what will happen, but you don't
know what the result will be without consulting the compiler documentation.

If you write
 #include "vector"
the implementation attempts to find something in some places -- it has to
tell you what it looks for and where. If it doesn't find what it was
looking for, it repeats the search as if you had written <vector> instead
of "vector". So you might get the standard vector header, but you might
get something else. I don't think the directive can fail in the usual
sense, but the search might find something you didn't expect, and which
might be invalid in your program.

If you write
 #include <myheader.h>
the implementation again attempts to find something in some places -- it has
to tell you what it looks for and where. Depending on what the implementation
does, it might find the file you want, it might find something else, or
it might find nothing. The directive could fail.

The standard specifies almost nothing about the mechanics, because of the
wide variety of system conventions and architectures. I would expect any
one implementation to behave in a resonably consistent way, but I would
not expect different implementations to behave identically. If the standard
tried to require that an implementation behave contrary to the conventions
of the platform, the standard would be unsuccessful to that degree.
---
Steve Clamage, stephen.clamage@eng.sun.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <526dso$mil@handupme.avid.com> joe@vixa.voyager.net (joe)
writes:

|> >> There must be one heck of a good reason to do this, since it obviously will
|> >> cause a great deal of grief.

|> >Obviously?  Why?

|> As far as the language is concerned, it does not matter one wit how the text of
|> a program is stored, or what the filenames *really* are. (assuming they are
|> stored in files at all, of course).
|> On the other hand, as far as everyday progamming tasks are concerned, it *does*
|> matter. So why *not* specify that the names of all std C++ headers files have a
|> trailing ".h"?

Because then they would be C language headers, and not C++.  At least on
my system.

|> By *not* specifing this, *most* compiler implementations will have files named
|> "vector" and "allocator", etc., with no filename extension.

I'd be *VERY* surprised if this were true.  "Most" compiler
implementations run in environments where "allocator" is not even a
legal filename.

|> There are many other problems created by this *deficiency* in the standard.
|> Ever had to create a portable program?
|>  At one point, we were developing a program for 2 different platforms.
|>  On Platform A, the compiler would accept ".CC" and ".cpp".
|>  On Platform B, the compiler would accept ".cxx" or ".C".
|>  We actually had to binary-edit one of the compilers to get them to agree on
|>  filenames.

Then you had really clunky compilers.  All of the compilers I've used
have been very tolerant in this regard.

|> >> This causes a lot of grief.
|> >>  o Suddenly, you can't do stuff like "grep foo *.h" anymore.

|> >Implementations are not required to implement the standard headers as
|> >text files at all, so in principle there's no difference.  Those that

|> Yes, but, 99.99% of all compilers *do* store them in text files of exactly
|> the same same as which appears in the #include statement. Its  not like
|> this is the unusual case.

Again, most compilers *do* map the filenames in some way.  Thus, for
example, the name of the file read when you use #include <allocator> is
likely "ALLOCATO.HPP" for one of the most widespread systems.

The mapping can be relatively complicated, and depend on options in the
compiler invocation.  Thus, most Unix systems will map <allocator> to
something like "/usr/include/CC/allocator".

With regards to grep'ing, it has already been pointed out that most
systems that use real include files will keep them in a separate
directory, so you can always do "grep /.../*".  Personally, if I ever
found myself wanting to grep the system includes, I would complain
loudly to the vendor about a lack of documentation.

|> Does it cause any trouble, for those compilers which store headers in some other
|> way, to have ".h" appended? (or .your-choice-of-extension)
|> >>  o Text editors have a harder time doing context highlighting.

|> >Beg pardon?

|> Many text editors do language sensitive context-highlighting based on
|> filename. Typically they have a table that says:
|>  *.h, *.c, *.cpp, *.cxx, (etc)    These are C/C++ source files
|>  *.asm, *.i                       These are assembly source files
|>  *.f                              These are fortran files.

|> So now are we supposed to add
|>  *                                This *might* be a std C++ header

I'm sort of curious as to why you want to edit a standard header.  At
all of the places I've worked, this has been strictly forbidden.

Anyway, my editor uses regular expressions on the filename to determine
context-highlighting, so I could use "/usr/include/CC/*" to specify C++.
(I think that this is fairly common in the Unix world.)  And of course,
if I'm actually going to edit the files, I could always add comment
lines at the end with the necessary information.

Where there's a will, there's a way.  But I don't think "ease of
editing" should affect the way the standard headers look and/or are
named.

|> Using this trivially simple match based on filename happens to be *really*
|> effective, and allows non-C++ compilers to determine that a given file is
|> either C or C++, and do something intelligent based on that fact.

That would only affect the source files, though, and not the standard
headers.

|> >>  o Programmers have a harder time picking out source files from others

|> >Programmers can (still) name their source files anything they like.

|> Yes, but most programmers cannot pick how the std headers are named - their
|> compiler vendor does that.
|> And, in 99% (a guess, but I'm sure its pretty close to being accurate) of the
|> compilers *will* (or already do) named the headers exactly as they appear in
|> the #include statements.

As I said before, some of the standard names are not even legal
filenames on some widespread systems, so I would expect some mapping to
take place.

|> >>  o Basically, anything which has been automated to work on C/C++ files
|> >>           (based on filename) will miss things such as "vector".

|> >But standard headers are not required to be stored in source files,
|> >so ending the names with .h or not doesn't matter.

|> Theoretically, it does not matter.
|> Practically it *DOES* matter.

|> Haven't you ever had to search thru the std headers for something with grep
|> or something similar?

No.  I don't even know where the C++ standard headers are located on my
machine.

If I want information concerning the standard libraries, I use the
on-line help (man pages under Unix; this is one place where I believe
that other systems are in advance).  I might also consult a copy of the
standard itself.  (This is my usual procedure in C.  In C++, the world
is not yet stable enough for this to be very productive.)

|> >> If anything, I would have expected the standard to *mandate" usage of ".h" and
|> >> ".cpp". (Not that I care much about exactly which extension, just so that there
|> >> is a standard filename extension).

|> >Not only does the C standard not mandate any particular header names,
|> >it also does not require the name of any header to match the name of

|> Yes, I know it doesn't.
|> It sure would simplify things a lot if it *did* though.
|> What would it hurt, anyway?

It would certainly restrict the possible implementations.  In
particular, if the standard forbid mapping the names, then a C++
implementation would be impossible under MS-DOS (and I suppose, Windows
as well).

|> Isn't it amazing the little things, which should not matter, but *DO* matter??


|> If the standard said that it must be <vector.header> (rather than just
|> <vector>), any particular implementation *could* just as easily change
|> that name into whathever happens to be handy for it.

One final point, which you seem to be ignoring: the headers, as defined
by the standard, are *NOT* compatible with existing practice.  At
present, I include <iostream.h> (under Unix) and I get access to the
entire iostream library.  According to the standard, including
<iostream> will *NOT* give me such access; I still need to add some
using statements.  I fully expect my compiler vendor to provide a file
<iostream.h> which includes <iostream> and then adds the using
statements, so that my existing programs will still compile.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <R.199609192305.QAA21714@taumet.eng.sun.com>
clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:

|> It is the rule in Standard C that the names of the standard headers used
|> in angle brackets need not correspond to the name of any file. That is,
|> when you write <stdio.h>, there need not be any file in the system with
|> the name "stdio.h". The implementation is free to map the reserved
|> header name (in angle brackets) to anything -- it need not be a file
|> at all, for example, but instead the reserved header names could simply
|> enable declarations predefined inside the compiler. Or the implementation
|> could map <stdio.h> to a file called "asdfghjkl" if it wished.

|> The C++ committee decided in 1991 to make this point more obvious by
|> eliminating the ".h" from the C++ standard header names, thus
|> discriminating equally against all implementations. :-)  Now you write,
|> for example, <iostream>, and you might wind up getting a header file whose
|> name is iostream.h, iostream.H, iostream.hpp, iostream.hxx, iostream.h++,
|> or "zxcvbnm". (Or perhaps the implementation doesn't use actual files.)

|> For compatibility, I would expect implementations to continue to accept
|> the same spelling of standard headers that they always accepted. Thus,
|> if a compiler previously used <iostream.hxx>, I would expect it to continue
|> to accept <iostream.hxx>, and pick up the same header file as <iostream>.

I don't.  As I mentioned in another posting, I would prefer that
<iostream.hxx> pick up a file that included <iostream> *AND* added the
necessary using declarations to make it visible.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

joe <joe@vixa.voyager.net> wrote in article
<526dso$mil@handupme.avid.com>...
> Many text editors do language sensitive context-highlighting based on
> filename. Typically they have a table that says:
>  *.h, *.c, *.cpp, *.cxx, (etc)    These are C/C++ source files
>  *.asm, *.i                       These are assembly source files
>  *.f                              These are fortran files.
>
> So now are we supposed to add
>  *                                This *might* be a std C++ header

A related problem is, that it is not possible to make a fileextension
association which automatically launches the editor when clicking in
the file in a GUI environment.

On the subject of headers, I have another complain. The C++ draft
standard does not try to solve any problems you encounter when
installing two sets of third party libraries with identically named
header files. I had exactly that problem when using a library that
included a "list.h" header file which is a name that is also used by
the STL.

Therefore, in our company we recently follow the rule that all our
headers are placed in a sub-directory and all include directives state
this sub-directory as follows:

#include <de/wellcom/header.h>

As you see, we are using the reversed domain name of our company, just
as it is suggested for Java packages. If the C++ standard would mandate
a similar practice, name-clashes with header file names would no longer
be a problem.

One could even go further and suggest that the include path somehow
matches the namespace that the symbols of the header are defined in,
e.g. namespace de_wellcom {}. Thus any chance of name-clashes in
namespace declarations is prevented.

On this theme, a C++ implementation could place the standard headers in
<std/...> and simply resolve the unqualified names (e.g. <vector>) to
this directory.

--
Andreas Selle
wellcom GmbH
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

joe wrote:
>
> >>By *not* specifing this, *most* compiler implementations will have files named
> >>"vector" and "allocator", etc., with no filename extension.
>
> >Why do you say that? Do you think an implementor is going to abandon
> >the local convention for file names? That would be exceptionally foolish.
> >If on a particular system the convention is to use ".hh" for C++ header
>
> Microsoft VisualC++ 4.2 does exactly this.
> Previously *all* compiler supplied headers were <foo.h>
> In its header directory, there is a mix of files named *.h and * (no extension)
> User created headers have no naming restrictions, beyond the filesystem
> requirements.
>
> Anybody from the MS VC++ development team listening in?
>
> I would be suprised to find a compiler which uses a (UNIX-similar) filesystem
> to store its headers to do otherwise. (Pleasently suprised)
>

Then you will be pleasantly surprised with BC++ 5.0. All of the standard
#include directives map to files with .h extensions. You're absolutely
right: Windows 95 and NT do not do well when you have filenames without
extensions.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

This whole argument seems to be rather steeped in a particular method of
conveying "type" or "context" information about files in their extensions.
Standardizing this method is pretty much completely hopeless anyway. Two
examples:

The Macintosh has a filesystem with true filetypes. Filetypes are used to
convey the format of the data in a file, not the purpose for which it is
used. So C++ header files have type TEXT and are typically called
"header.h" or "header.hpp". With standard C++ extensionless files are
becoming more common ("header"). Most editors assume that all files loaded
are C++ unless there is some indication otherwise. (A resource in the
resource fork of the file for example. This is much like the explicit
annotations put in coments at the bottom of a source file for emacs.) Note
that the typical "grep all .h files" still works, though many people I know
tend to use "grep all files of type TEXT in a certain part of the tree"
instead.

Windows uses the extension for type purposes. This introduces a number of
anomolies. First, you can't easily open a .h or .cpp file with standard
text editors because they are looking for .txt files. (You can
change the extension filter, but its a pain.) Under Windows95 and WinNT
4.0, the standard file selection dialogs do not show the extension of
files. This means one can see many files with exactly the same name, they
just have different "types." (I have very harsh words for this UI design,
but I'll spare you all.) Note that within the development environment, the
extensions are still very important. For example, I don't think the filter
pop up setting for "include files" handles extensionless files. (A
Developer Studio bug perhaps...)

Ultimately, one would have typed files with an inheritance hierarchy on
types. So We'd have file types like "Text::C++::Header" and
"Test::C++::Source" or some such.

I don't think mandating extensions belongs in the standard, but I wouldn't
mind seeing a document outlining prefered ways for compilers to do things
given a certain platform infrastructure. That way we would avoid needless
incompatibility between compilers and platforms. Some sort of development
environment standard (likely informal as opposed to official) would be a
useful thing.

-Z-


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 2EK@netcom.com, zalman@netcom.com (Zalman Stern) writes:
>
>I don't think mandating extensions belongs in the standard, but I wouldn't
>mind seeing a document outlining prefered ways for compilers to do things
>given a certain platform infrastructure. That way we would avoid needless
>incompatibility between compilers and platforms.

That is the purpose of APIs and ABIs. The platform vendor specifies the
standard locations, formats, names, and so on. The C++ standard cannot
possibly do that. New systems are released far more frequently than any
ANSI or ISO standard could track.

Besides, suppose the C++ standard said one thing, the Fortran standard
said something different, and both of them conflicted with POSIX? Who
could coordinate such a mess?

Instead, implementations can follow the conventions of the platform
(or not), with no interference from the C++ standard.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> Pete Becker <pbecker@oec.com> writes:

> Then you will be pleasantly surprised with BC++ 5.0. All of the standard
> #include directives map to files with .h extensions.

So what do you do with <string>?

Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I'm, sure this has been argued about in the past, but I missed it, so
I will bring it up again...



*WHY* does the new C++ standard get rid of ".h" extension for standard headers?
There must be one heck of a good reason to do this, since it obviously will
cause a great deal of grief.


This causes a lot of grief.
 o Suddenly, you can't do stuff like "grep foo *.h" anymore.
 o Text editors have a harder time doing context highlighting.
 o Programmers have a harder time picking out source files from others
 o Basically, anything which has been automated to work on C/C++ files
          (based on filename) will miss things such as "vector".


If anything, I would have expected the standard to *mandate" usage of ".h" and
".cpp". (Not that I care much about exactly which extension, just so that there
is a standard filename extension).



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe)
writes:

|> *WHY* does the new C++ standard get rid of ".h" extension for standard headers?

Because it was never standard.  Depending on the compiler, I've seen
both iostream.h and iostream.hpp, for example.

The different parties couldn't agree on a standard extension, so they
agreed to use no extension.  I expect, however, that compiler vendors
will continue to make the header files available both without the
extension, and with their old extension, what ever it was.

|> There must be one heck of a good reason to do this, since it obviously will
|> cause a great deal of grief.

The grief would be there anyway.  With the introduction of namespaces,
it is no longer sufficient to simply include the header file.  You need
a "using" declaration as well.

This is, in a way, also an argument for changing the existing practice
in the header file names.  An implementation could provide an iostream.h
which includes all of the iostream files, AND all of the relevant using
declarations.  In this way, old code still works.

|> This causes a lot of grief.
|>  o Suddenly, you can't do stuff like "grep foo *.h" anymore.

IMHO, this IS a real problem.  I don't like having any files without
some sort of indication as to their type.  (In this regard, .xxx is a
hack, but it is a very effective hack if used systematically.  One of
the most frustrating things in Unix is trying to clean up, by deleting
all objects (.o), libraries (.a) and executables.)

The mapping h-char-sequence to filename is implementation dependant
however, so there is nothing to prevent the implementation from saying
that names not ending in a .something will map to the same name with a
.xyz appended.  (Let's face it.  A lot of implementations will have to
map names anyway, since the h-char-sequence is often longer than 8
characters, e.g.: <algorithm>, <exception>, <functional>, <stdexcept>,
and <streambuf>.

|>  o Text editors have a harder time doing context highlighting.

I've not noticed this problem, although I use a number of special
endings in my own code.  Of course, my editor allows putting the mode in
comments at the end, which I always do, so I have in fact told it
explicitly.

|>  o Programmers have a harder time picking out source files from others
|>  o Basically, anything which has been automated to work on C/C++ files
|>           (based on filename) will miss things such as "vector".

I agree with the general problem.  Other programs cannot figure out what
the type of the file is.  This is also a problem with .h, however.
Unless I add the mode lines to the file, my editor supposes that it is
C, and doesn't e.g. recognize the // comments.


|> If anything, I would have expected the standard to *mandate" usage of ".h" and
|> ".cpp". (Not that I care much about exactly which extension, just so that there
|> is a standard filename extension).

Well, mandating .h just adds to the confusion: is the file C or C++.

I don't think that the problem is all that great.  It only affects the
header files for the standard library; typically, these will be in a
standard place, and be the only files there.  And of course, I will
continue to use .hh for my own header files, just as I always have.
(With regards to .c/.C/.cpp: this has never been mandated by the
standard.  Many implementations do require the source to have the
extension in a certain set, however.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

joe <joe@vixa.voyager.net> wrote in article
<51rs4h$24c@handupme.avid.com>...
> *WHY* does the new C++ standard get rid of ".h" extension for standard
headers?
> There must be one heck of a good reason to do this, since it obviously
will
> cause a great deal of grief.
>
> This causes a lot of grief.
>  o Suddenly, you can't do stuff like "grep foo *.h" anymore.
>  o Text editors have a harder time doing context highlighting.
>  o Programmers have a harder time picking out source files from others
>  o Basically, anything which has been automated to work on C/C++ files
>           (based on filename) will miss things such as "vector".

The trouble here is that "existing practice" is FUBARed. Some compilers
like .h, some .hh, some .hpp, some .hxx, and some don't care. Note that
only the *standard* headers have no extension. The standard does not
prevent you from naming your own headers any way you want, and you know the
names of the standard headers in advance.

1. You can still "grep foo *.h" if you name your own headers *.h.
2. Text editors can key on #{spaces}include{spaces}[<"][filechars][>"] for
syntax highlighting.
3. Programmers can find their source files just fine if you go on naming
your headers *.h like you always did. In fact, you can spot the standard
headers easier because they don't have an extension; many companies mandate
a policy that "all headers will be included with angle brackets" which
makes it hard to tell your own headers from library headers. If you still
have trouble finding your headers, try putting them in their own
directory/folder/whatever.
4. You shouldn't be doing too much automated stuff on standard headers,
because they aren't even guaranteed to physically exist. Besides, you
should already know what's in there.

If you *really* need to name your own headers without extensions (those
company policies again) or you *really* need to locate standard headers,
find a string that appears in all of them and do a 'find-in-file' operation
to locate that key string. One typical way would be to key on the header's
multiple inclusion guard:

find-files-containing /#ifndef ([0-9A-Za-z_]*)\n#define$1/

The pseudo-regular expression uses perl regexp syntax to say "find #ifndef
{identifier} on one line and #define {identifier} on the next line, where
the identifiers are the same." This will find header files with a good
success rate, possibly better than searching for *.h or *.hxx. (Well, it
won't find <assert.h> or <cassert>).
--
Bradd W. Szonye
bradds@ix.netcom.com
http://www.geocities.com/SouthBeach/2447
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe) writes:

> *WHY* does the new C++ standard get rid of ".h" extension for standard headers?

Because the new standard headers do different things from any existing
headers (particularly in introducing names into namespace std, rather than
the global namespace), so they should have different names.

> There must be one heck of a good reason to do this, since it obviously will
> cause a great deal of grief.

Obviously?  Why?

> This causes a lot of grief.
>  o Suddenly, you can't do stuff like "grep foo *.h" anymore.

Implementations are not required to implement the standard headers as
text files at all, so in principle there's no difference.  Those that
do implement the standard headers as files will probably put them all
in some particular directory anyway, so you can say grep foo headers/* instead.

>  o Text editors have a harder time doing context highlighting.

Beg pardon?

>  o Programmers have a harder time picking out source files from others

Programmers can (still) name their source files anything they like.

>  o Basically, anything which has been automated to work on C/C++ files
>           (based on filename) will miss things such as "vector".

But standard headers are not required to be stored in source files,
so ending the names with .h or not doesn't matter.

> If anything, I would have expected the standard to *mandate" usage of ".h" and
> ".cpp". (Not that I care much about exactly which extension, just so that there
> is a standard filename extension).

Not only does the C standard not mandate any particular header names,
it also does not require the name of any header to match the name of
the file that implements it.  That is, if you say   #include "foo.h"
there is a requirement that the implementation tell you the name of the
file that will be copied, but the file is not required to be named
foo.h .  C++ follows C in that regard.
--
    --Andrew Koenig
      ark@research.att.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 24c@handupme.avid.com, joe@vixa.voyager.net (joe) writes:
>
>*WHY* does the new C++ standard get rid of ".h" extension for standard headers?
>There must be one heck of a good reason to do this, since it obviously will
>cause a great deal of grief.

Many early C++ implementations used a file extension other than ".h" for
header files. Choices included ".H", ".hpp", ".hxx", ".h++", and perhaps
others. Looking at this problem in 1991, the C++ committee concluded that
enshrining ".h" in the standard would be seen as discriminating against
many implementations.

It is the rule in Standard C that the names of the standard headers used
in angle brackets need not correspond to the name of any file. That is,
when you write <stdio.h>, there need not be any file in the system with
the name "stdio.h". The implementation is free to map the reserved
header name (in angle brackets) to anything -- it need not be a file
at all, for example, but instead the reserved header names could simply
enable declarations predefined inside the compiler. Or the implementation
could map <stdio.h> to a file called "asdfghjkl" if it wished.

The C++ committee decided in 1991 to make this point more obvious by
eliminating the ".h" from the C++ standard header names, thus
discriminating equally against all implementations. :-)  Now you write,
for example, <iostream>, and you might wind up getting a header file whose
name is iostream.h, iostream.H, iostream.hpp, iostream.hxx, iostream.h++,
or "zxcvbnm". (Or perhaps the implementation doesn't use actual files.)

For compatibility, I would expect implementations to continue to accept
the same spelling of standard headers that they always accepted. Thus,
if a compiler previously used <iostream.hxx>, I would expect it to continue
to accept <iostream.hxx>, and pick up the same header file as <iostream>.

>This causes a lot of grief.
> o Suddenly, you can't do stuff like "grep foo *.h" anymore.
> o Text editors have a harder time doing context highlighting.
> o Programmers have a harder time picking out source files from others
> o Basically, anything which has been automated to work on C/C++ files
>          (based on filename) will miss things such as "vector".

I'm afraid I don't understand what grief is caused. Instead of grepping
for *.h, you can grep for "#include", no matter what the header suffix.
Text editor highlighting would be based on #include, not on specific
strings ocurring in <> or "" delimiters, no? And surely you don't
have an automated tool that is hardcoded to look for exactly and only
specific C++ header name spellings. That is already unportable, no matter
what the C++ committee did. In the absence of a standard, different
C++ implementations use different spellings for some headers, and
have different sets of headers besides. Even the "same" implementations
have changed conventions over time.

In any case, supposing you care only about using one implementation,
the vendor will undoubtedly continue to support the old header
spellings as I mentioned above, so you should not have to change
existing code. It won't be portable, but then it never was.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Andrew Koenig <ark@research.att.com> wrote:
>In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe) writes:
>> There must be one heck of a good reason to do this, since it obviously will
>> cause a great deal of grief.
>
>Obviously?  Why?

It will cause some grief if:
 Compilers implement the new headers as files with no extension
 Programmers take this as a suggestion that their own headers
    should be extension-less
 Systems use the extension to determine file types

The lack of an extension is more annoying that changing it.  Very few
programs generate files with a .h (.hh, .hpp, whatever) extension;
many generate temporary files with no extension.

The problem here is that the standard way of thinking has been that if
a program has #include <fn.h> somewhere, then the compiler will look
for fn.h somewhere in the filesystem.  Obviously, this way of thinking
is wrong (there's nothing in the standard that requires it), but
because that's the way it has always been done in the past, we assume
that will be the way it will be done.  Thus, changing to <fn> will
cause the compiler to look for fn -- incorrect, but we're used to
thinking that way.

After thinking everything through, I actually like the new
convention (as long any header files still carry the .h extension).
It suggests that such support can be built into the compiler, or at
least into pre-compiled headers.  I hope that vendors will continue to
provide the .h files, though, even if they're not used by the
compiler; examining them can be instructive, whether you're learning
the language or trying to deduce whether a bug is your own or a
compiler fault.

To summarize, the new non-.h notation will cause some grief because
habits -- bad, good, or formerly necessary -- will have to be
unlearned.  In the long run, however, it has the potential for
improving implementation-specific parameters.
--
David A. Cuthbert
dacut@ugcs.caltech.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Reposting article removed by rogue canceller.

Andrew Koenig <ark@research.att.com> wrote:
>In article <51rs4h$24c@handupme.avid.com> joe@vixa.voyager.net (joe) writes:
>> There must be one heck of a good reason to do this, since it obviously will
>> cause a great deal of grief.
>
>Obviously?  Why?

It will cause some grief if:
 Compilers implement the new headers as files with no extension
 Programmers take this as a suggestion that their own headers
    should be extension-less
 Systems use the extension to determine file types

The lack of an extension is more annoying that changing it.  Very few
programs generate files with a .h (.hh, .hpp, whatever) extension;
many generate temporary files with no extension.

The problem here is that the standard way of thinking has been that if
a program has #include <fn.h> somewhere, then the compiler will look
for fn.h somewhere in the filesystem.  Obviously, this way of thinking
is wrong (there's nothing in the standard that requires it), but
because that's the way it has always been done in the past, we assume
that will be the way it will be done.  Thus, changing to <fn> will
cause the compiler to look for fn -- incorrect, but we're used to
thinking that way.

After thinking everything through, I actually like the new
convention (as long any header files still carry the .h extension).
It suggests that such support can be built into the compiler, or at
least into pre-compiled headers.  I hope that vendors will continue to
provide the .h files, though, even if they're not used by the
compiler; examining them can be instructive, whether you're learning
the language or trying to deduce whether a bug is your own or a
compiler fault.

To summarize, the new non-.h notation will cause some grief because
habits -- bad, good, or formerly necessary -- will have to be
unlearned.  In the long run, however, it has the potential for
improving implementation-specific parameters.
--
David A. Cuthbert
dacut@ugcs.caltech.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Reposting article removed by rogue canceller.

In article 24c@handupme.avid.com, joe@vixa.voyager.net (joe) writes:
>
>*WHY* does the new C++ standard get rid of ".h" extension for standard headers?
>There must be one heck of a good reason to do this, since it obviously will
>cause a great deal of grief.

Many early C++ implementations used a file extension other than ".h" for
header files. Choices included ".H", ".hpp", ".hxx", ".h++", and perhaps
others. Looking at this problem in 1991, the C++ committee concluded that
enshrining ".h" in the standard would be seen as discriminating against
many implementations.

It is the rule in Standard C that the names of the standard headers used
in angle brackets need not correspond to the name of any file. That is,
when you write <stdio.h>, there need not be any file in the system with
the name "stdio.h". The implementation is free to map the reserved
header name (in angle brackets) to anything -- it need not be a file
at all, for example, but instead the reserved header names could simply
enable declarations predefined inside the compiler. Or the implementation
could map <stdio.h> to a file called "asdfghjkl" if it wished.

The C++ committee decided in 1991 to make this point more obvious by
eliminating the ".h" from the C++ standard header names, thus
discriminating equally against all implementations. :-)  Now you write,
for example, <iostream>, and you might wind up getting a header file whose
name is iostream.h, iostream.H, iostream.hpp, iostream.hxx, iostream.h++,
or "zxcvbnm". (Or perhaps the implementation doesn't use actual files.)

For compatibility, I would expect implementations to continue to accept
the same spelling of standard headers that they always accepted. Thus,
if a compiler previously used <iostream.hxx>, I would expect it to continue
to accept <iostream.hxx>, and pick up the same header file as <iostream>.

>This causes a lot of grief.
> o Suddenly, you can't do stuff like "grep foo *.h" anymore.
> o Text editors have a harder time doing context highlighting.
> o Programmers have a harder time picking out source files from others
> o Basically, anything which has been automated to work on C/C++ files
>          (based on filename) will miss things such as "vector".

I'm afraid I don't understand what grief is caused. Instead of grepping
for *.h, you can grep for "#include", no matter what the header suffix.
Text editor highlighting would be based on #include, not on specific
strings ocurring in <> or "" delimiters, no? And surely you don't
have an automated tool that is hardcoded to look for exactly and only
specific C++ header name spellings. That is already unportable, no matter
what the C++ committee did. In the absence of a standard, different
C++ implementations use different spellings for some headers, and
have different sets of headers besides. Even the "same" implementations
have changed conventions over time.

In any case, supposing you care only about using one implementation,
the vendor will undoubtedly continue to support the old header
spellings as I mentioned above, so you should not have to change
existing code. It won't be portable, but then it never was.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]