ghickman@acm.org wrote:

>
> This looks suspect to say the least, but I'm wondering how much the
> #include mechanism varies in practice and how much latitude the
> standard can be interpreted to permit?
>
The standard pretty much says the implementation can do what it
like to include not using "files" at all.

---
[ 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                       ]

ghickman@acm.org wrote:
.
> The implementation-defined differences (or lack thereof) between the
> two forms of #include directives don't concern me as much as how a
> given compiler might translate an h-char-sequence to a filename.

Well, that's completely up to the implementation, just like the the
path to be searched.

> For example, a compiler is allowed to map <set> to the file
> '/usr/include/set.h'.  A simplistic algorithm for this might be:
> "Append '.h' to the h-char-sequence and search for a file with that
> name in the include path".  If compiler A maps the user header
> <libname/set> to the file 'libname/set.h', but compiler B uses
> 'libname/set.hpp' and compiler C 'libname/set.xyz', etc., user-defined
> "extension-less" h-char-sequences would be problematic.
>
> I imagine most implementations would handle this in practice by simply
> doing no translation of the h-char-sequence at all (i.e., map header
> <libname/set> to the filename 'libname/set'), but I was hoping for a
> little reassuring feedback nonetheless.

The correct answer to this question isn't reassuring; sorry!

---
[ 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                       ]

ghickman@acm.org wrote:
.
> Many of the standard headers are off limits for that project, so the
> developers resorted in some cases to writing their own versions of the
> standard headers (e.g., "libname/vector.h", etc.).  Then someone
> suggested, "Why not drop the '.h' suffix on these headers to make
> references to them more like the standard headers they're designed to
> replace?"  An include directive like
>
> #include <libname/vector.h>
>
>     would become
>
> #include <libname/vector>
>
> Since I've never seen anyone use a header without a suffix (except for
> the standard headers, of course), I began to wonder whether most (if
> not all) implementations will be able to find the file <libname/vector>
> correctly?  For example, are implementations permitted to assume that
> an h-char-sequence without a suffix is a reference to a standard
> header, and to then map that to some implementation-defined name?  If
> so, it might try to map their "suffix-less" names in the same way:

The mapping is entirely implementation-defined, and that is a possible
way to handle it.

However, since you asked about "most" implementations, I'm permitted to
answer by pointing out that the typical implementation will not do so.
Every implementation I've ever used has a default list of directories
to be searched, which can be extended by compiler command line options.
The search is performed by looking in each of those directories, in
order, and interpreting the h-char-sequence as a path name releative to
that directory. Therefore, it would find those files. Just keep in mind
that nothing I've said in this paragraph is mandatory.

---
[ 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                       ]

ghickman@acm.org wrote:
> Carl Barron wrote:
>
> > What is a compiler to do when / is a valid filename character [example
> > classic macos,   In fact using mac osX 3.9 / is a valid character] I
> > know my compiler lets me 'interpret dos/unix filenames' but the
> > question in general is what does compiler Z do on OS W where W allows
> > '/'s in filenames?  Questions like this are why the search process is
> > implimentation specific.
> >    Since the standard [16.2] states that files included like #include
> > "filename" are searched first in an implimentation search mechanism and
> > if this fails then the include is treated as #include <filename>. I
> > really don't think its a good rule. If the implimentation search
> > locations for #include " " are the same as #include <> then nothing is
> > gained but if they are or can be different then #include " " will
> > search for your file vector before it looks for the standard include
> > file vector.
> >    I think that #include "vector" will find your file vector before the
> > standard one provided you tell your compiler[implimentation specific
> > method] what the search path is.  If there is no file vector on the ""
> > search path it will find the standard one on the <> path.
>
> The implementation-defined differences (or lack thereof) between the
> two forms of #include directives don't concern me as much as how a
> given compiler might translate an h-char-sequence to a filename.

Well, basically, if the char sequence is in <>, the compiler can do
anything it likes. Sorry.

> For example, a compiler is allowed to map <set> to the file
> '/usr/include/set.h'.  A simplistic algorithm for this might be:
> "Append '.h' to the h-char-sequence and search for a file with that
> name in the include path".  If compiler A maps the user header
> <libname/set> to the file 'libname/set.h', but compiler B uses
> 'libname/set.hpp' and compiler C 'libname/set.xyz', etc., user-defined
> "extension-less" h-char-sequences would be problematic.
>
> I imagine most implementations would handle this in practice by simply
> doing no translation of the h-char-sequence at all (i.e., map header
> <libname/set> to the filename 'libname/set'), but I was hoping for a
> little reassuring feedback nonetheless.

I should think that is true, though it is by no means guaranteed. A
number of  early C++ compilers did stick a .h on the end.

It's a case of suck it and see, and hope that the compiler doesn't
change its behaviour between versions.

---
[ 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                       ]

===================================== MODERATOR'S COMMENT:

Please focus in replies on the topical piece of this question,
specifically
the issue of the implementation-defined nature of header file search
rules.


===================================== END OF MODERATOR'S COMMENT
One of our projects adopted a coding guideline that requires using the
"#include <h-char-sequence>" form of include directive for all headers,
including user-specific header files not included with the
implementation.

Many of the standard headers are off limits for that project, so the
developers resorted in some cases to writing their own versions of the
standard headers (e.g., "libname/vector.h", etc.).  Then someone
suggested, "Why not drop the '.h' suffix on these headers to make
references to them more like the standard headers they're designed to
replace?"  An include directive like

#include <libname/vector.h>

    would become

#include <libname/vector>

Since I've never seen anyone use a header without a suffix (except for
the standard headers, of course), I began to wonder whether most (if
not all) implementations will be able to find the file <libname/vector>
correctly?  For example, are implementations permitted to assume that
an h-char-sequence without a suffix is a reference to a standard
header, and to then map that to some implementation-defined name?  If
so, it might try to map their "suffix-less" names in the same way:

#include <libname/vector> ---> /usr/include/vector.xyz

This looks suspect to say the least, but I'm wondering how much the
#include mechanism varies in practice and how much latitude the
standard can be interpreted to permit?

Thanks,
Greg

---
[ 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 <1117056257.134004.111640@o13g2000cwo.googlegroups.com>,
<"ghickman@acm.org"> wrote:

> One of our projects adopted a coding guideline that requires using the
> "#include <h-char-sequence>" form of include directive for all headers,
> including user-specific header files not included with the
> implementation.
>
> Many of the standard headers are off limits for that project, so the
> developers resorted in some cases to writing their own versions of the
> standard headers (e.g., "libname/vector.h", etc.).  Then someone
> suggested, "Why not drop the '.h' suffix on these headers to make
> references to them more like the standard headers they're designed to
> replace?"  An include directive like
>
> #include <libname/vector.h>

What is a compiler to do when / is a valid filename character [example
classic macos,   In fact using mac osX 3.9 / is a valid character] I
know my compiler lets me 'interpret dos/unix filenames' but the
question in general is what does compiler Z do on OS W where W allows
'/'s in filenames?  Questions like this are why the search process is
implimentation specific.
   Since the standard [16.2] states that files included like #include
"filename" are searched first in an implimentation search mechanism and
if this fails then the include is treated as #include <filename>. I
really don't think its a good rule. If the implimentation search
locations for #include " " are the same as #include <> then nothing is
gained but if they are or can be different then #include " " will
search for your file vector before it looks for the standard include
file vector.
   I think that #include "vector" will find your file vector before the
standard one provided you tell your compiler[implimentation specific
method] what the search path is.  If there is no file vector on the ""
search path it will find the standard one on the <> path.

---
[ 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                       ]

ghickman@acm.org wrote:
> One of our projects adopted a coding guideline that requires using the
> "#include <h-char-sequence>" form of include directive for all headers,
> including user-specific header files not included with the
> implementation.
>
> Many of the standard headers are off limits for that project, so the
> developers resorted in some cases to writing their own versions of the
> standard headers (e.g., "libname/vector.h", etc.).  Then someone
> suggested, "Why not drop the '.h' suffix on these headers to make
> references to them more like the standard headers they're designed to
> replace?"  An include directive like
>
> #include <libname/vector.h>
>
>     would become
>
> #include <libname/vector>
>
> Since I've never seen anyone use a header without a suffix (except for
> the standard headers, of course), I began to wonder whether most (if
> not all) implementations will be able to find the file <libname/vector>
> correctly?  For example, are implementations permitted to assume that
> an h-char-sequence without a suffix is a reference to a standard
> header, and to then map that to some implementation-defined name?  If
> so, it might try to map their "suffix-less" names in the same way:
>
> #include <libname/vector> ---> /usr/include/vector.xyz
>
> This looks suspect to say the least, but I'm wondering how much the
> #include mechanism varies in practice and how much latitude the
> standard can be interpreted to permit?
The compiler is allowed to do more or less anything with things between
<>.

Stroustroup 3rd edition s 9.2.2
"The absence of a .h suffix does not imply anything about how the
header is stored. A header such as <map> may be stored in a text file
called map.h in a standard directory." and "standard headers are not
required to be stored in a conventional manner... treat #include
<cmath> as a switch that makes the standard math functions available
without reading any file".

Which does indeed mean that #include <libname/vector> could silently
have a .h added to it.

The rules are:
<> => Look somewhere implementation defined.
"" => Look somewhere implementation defined. If you can't find it, try
as though the text had had <> round it.

I've seen at least the following variations among compilers:
1) Files in <> don't exist, they are built with the compiler. You can
control where files in "" may be found by using a command line switch
2) Files in "" imply "look in the current directory".  You can control
where files in <> may be found by using a command line switch
3) Files in "" imply "look in the directory containing the file
currently being read".  You can control where files in <> may be found
by using a command line switch
4) You can control where files in "" may be found using a command line
switch. You can control where files in <> may be found by using a
different command line switch

There are definitely other variations.

The only safe rule I've ever found is:
1) Use <> for, and only for, system header files
2) Use "" for, and only for, user header files
3) Always specify the path for user header files relative to some
standard directory.

And I'm not sure how safe that rule is, it depends on all compilers
treating '/' as a directory separator, even if the O/S doesn't. So far,
I haven't been disappointed.

---
[ 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                       ]

Carl Barron wrote:

> What is a compiler to do when / is a valid filename character [example
> classic macos,   In fact using mac osX 3.9 / is a valid character] I
> know my compiler lets me 'interpret dos/unix filenames' but the
> question in general is what does compiler Z do on OS W where W allows
> '/'s in filenames?  Questions like this are why the search process is
> implimentation specific.
>    Since the standard [16.2] states that files included like #include
> "filename" are searched first in an implimentation search mechanism and
> if this fails then the include is treated as #include <filename>. I
> really don't think its a good rule. If the implimentation search
> locations for #include " " are the same as #include <> then nothing is
> gained but if they are or can be different then #include " " will
> search for your file vector before it looks for the standard include
> file vector.
>    I think that #include "vector" will find your file vector before the
> standard one provided you tell your compiler[implimentation specific
> method] what the search path is.  If there is no file vector on the ""
> search path it will find the standard one on the <> path.

The implementation-defined differences (or lack thereof) between the
two forms of #include directives don't concern me as much as how a
given compiler might translate an h-char-sequence to a filename.

For example, a compiler is allowed to map <set> to the file
'/usr/include/set.h'.  A simplistic algorithm for this might be:
"Append '.h' to the h-char-sequence and search for a file with that
name in the include path".  If compiler A maps the user header
<libname/set> to the file 'libname/set.h', but compiler B uses
'libname/set.hpp' and compiler C 'libname/set.xyz', etc., user-defined
"extension-less" h-char-sequences would be problematic.

I imagine most implementations would handle this in practice by simply
doing no translation of the h-char-sequence at all (i.e., map header
<libname/set> to the filename 'libname/set'), but I was hoping for a
little reassuring feedback nonetheless.

-Greg

---
[ 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                       ]

ghickman@acm.org wrote:

[snip]

This issue has presented me with several problems lately.  I am working with
a toolkit that does not have extensions on the header file names.  The
development tools I use do not know how to deal with these files in many
cases.  The CPP implementation does find the files, and uses them
correctly, but the IDEs do not.  This means that most of the functionality
provided by the IDEs, such a code completion, and file browsing do not
work.  The lack of c++ standardization in this regard, is IMO, a serious
problem in the language.  The lead developer of the toolkit claims my tools
are broken.  The IDE developers don't seem very interested in supporting
what they see as an anomalous design decision.  I've looked at some of the
steps they would have to take in oder to support the extensionless headers,
and it is non-trivial.

I believe there really should be a standard way of identifying C++ source,
and header files.  I know the C++ standard doesn't even provide a
definition of a header file, much less a specification.  There may be good
reasons for that.  OTOH, the lack of standardization and lack of agreement
on what should be used is causing me a great deal of problem.  I can think
of at least four programming languages that have file name extensions
specified in their defining documentation.  Two of these are direct
competitors for C++ market share.  There is a clear advantage to having
this aspect of the implementation specified. It prevents the problems I
have encountered.

--
STH

---
[ 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                       ]