On Mar 19, 1:35 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> whit wrote:
> > Is anyone aware of language in the standard that guarantees
> > header files with any extension will be allowed in an
> > #include statement?
> There is nothing in the Standard governing the "allowed" or
> "prohibited" file name extension AFA textual inclusion is
> concerned.
That's not quite true. A conformant implementation is required
to recognize the standard headers in an <...> include (but not
in a "..." include). Also, the standard requires that" The
implementation provides unique mappings for sequences consisting
of one or more nondigits or digits (2.10) followed by a period
(.) and a single nondigit. The first character shall not be a
digit. The implementation may ignore the distinctions of
alphabetical case." (The C standard restricts this to 8
characters before the period. In practice, I don't know of any
C++ implementation which is conform, but all conform to the C
standard.)
> The standard headers are all known, and they aren't
> necessarily files. It is up to the implementation in what
> form it chooses to have those headers. As to your own, you
> probably can have anything there, given that the character
> sequence between '<' and '>' (or in double quotes) does not
> violate the requirements for the preprocessor directive.
The characters between the <...> and the "..." in a return
follow special rules (and the rules aren't necessarily the same
in both cases). What is legal depends on the implementation.
All the standard reuires is that alphanumeric characters are
accepted. In practice, there are probably a few more that are
safe. (I regularly use '/' as a directory separator. But
admittedly, I'm not concerned with portability beyond Unix and
Windows.)
> > The issue is that I'm writing a few "add-on" packages for
> > the R language. However, the R project rejects any header
> > files that do not have a .h extension on the basis of
> > compiler portability. i.e. we know that gcc accepts the .hpp
> > files, but we don't know if other compilers accept those
> > file extensions.
> That's up to the compiler. The standard headers, if they are
> files, do not have any extensions. The old C headers do, it's
> ".h", and it's still supported by the C++ Standard, but that's
> an *inclusive* requirement, not an *exclusive* one.
In practice, any sequence of alphanumeric characters will work,
at least up to three. What's uncertain is whether case is
distinctive---historically, a lot of C++ headers used .H, which
is confonded with .h on some systems.
> > However, if the standard guarantees that any extensions for
> > header files can be allowed that is a strong argument for R
> > to change its policy.
> There is no such explicit guarantee. It's up to the
> implementation.
See above. But in practice, up to three alphanumeric characters
after the . will not cause problems.
--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
|
Similar Threads
