I was under the impression that an implementation was allowed to bring
in (or use) knowledge about entities defined in standard include files
without actually resorting to textually inserting a file at the place
where the #include is.

The Dec 1996 draft says:

3 A preprocessing directive of the form
          # include "q-char-sequence" new-line
  causes the replacement of that directive by the entire contents of the
  source  file identified by the specified sequence between the " delim-
  iters.  The named source file is searched for  in  an  implementation-
  defined  manner.   If  this  search is not supported, or if the search
  fails, the directive is reprocessed as if it read
          # include <h-char-sequence> new-line
  with the identical contained sequence (including > characters, if any)
  from the original directive.

5 The mapping between the delimited sequence  and  the  external  source
  file  name  is  implementation-defined.   The  implementation provides
  unique mappings for sequences consisting  of  one  or  more  nondigits
  (_lex.name_)  followed  by  a  period  .)  and a single nondigit.  The
  implementation may ignore the distinctions of alphabetical case.

which seems kind of assuming that a textual replacement is indeed
requested. I still think that the standard allows for not reading,
say, iostream but to use knowledge about it obtained in some other way
because of the following:

 1) the content of iostream is completely specified by the
           standard.
 2) the ubiquitous 'as if' rule.

Is that correct?

Are names of standard header files reserved (e.g. is the user
forbidden from having a iostream file somewhere in the include search
path)?

Thanks,

 Maurizio


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Maurizio Vitale <vitale@esat.kuleuven.ac.be> writes:


>I was under the impression that an implementation was allowed to bring
>in (or use) knowledge about entities defined in standard include files
>without actually resorting to textually inserting a file at the place
>where the #include is.

>The Dec 1996 draft says: ...

>which seems kind of assuming that a textual replacement is indeed
>requested.

The standard defines the effects of header inclusion in
terms of phases of translation and text replacement, but:

>I still think that the standard allows for not reading,
>say, iostream but to use knowledge about it obtained in some other way
>because of the following:

> 1) the content of iostream is completely specified by the
>           standard.
> 2) the ubiquitous 'as if' rule.

>Is that correct?

Yes. As long as the result is what the standard requires, it
doesn't matter (for conformance purposes) how the result is
acheived.

>Are names of standard header files reserved (e.g. is the user
>forbidden from having a iostream file somewhere in the include search
>path)?

The names are not reserved.

The standard header files are intended to be accessed using the
syntax
 #include <headername>

User-defined headers are intended to be accessed using the syntax
 #include "headername"

The implementation is supposed to use some magic (like different
directory search paths) to help avoid potential conflicts, but the
implementation is not required to guarantee no conflicts.

It may be possible, depending on the implemenation and the
compiler options, to find a user-defined header when you
expected to find a system header or vice-versa. For that
reason, creating project header names that match standard
header names (or common OS header names) is a bad idea.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]