Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
#include "..."
46 views
Skip to first unread message
Cholo Lennon
Aug 24, 2016, 2:46:16 PM8/24/16
to
Can I assume (in a portable sense) that /#include "some_header"/ will
always start its search from the same directory that the file that is
including it? (at least in g++ and VC++ this behavior is present)
The standard seems not guarantee that ("file is searched for in an
implementation-defined manner"):
/16.2 Source file inclusion
...
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 " delimiters.
*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./
TIA
--
Cholo Lennon
Bs.As.
ARG
always start its search from the same directory that the file that is
including it? (at least in g++ and VC++ this behavior is present)
The standard seems not guarantee that ("file is searched for in an
implementation-defined manner"):
/16.2 Source file inclusion
...
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 " delimiters.
*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./
TIA
--
Cholo Lennon
Bs.As.
ARG
Richard
Aug 24, 2016, 2:57:09 PM8/24/16
to
[Please do not mail me a copy of your followup]
Cholo Lennon <cholo...@hotmail.com> spake the secret code
<npkq19$ibo$1...@gioia.aioe.org> thusly:
>Can I assume (in a portable sense) that /#include "some_header"/ will
>always start its search from the same directory that the file that is
>including it? (at least in g++ and VC++ this behavior is present)
Not really. It depends on the search order specified by the
implementation. So to answer your question you have to look at the
documentation for the implementation you're using.
For gcc, the documentation says that it searches the directory
containing the header, then -iquote directories, then normal POSIX
system directories.
<https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html>
For MSVC, the documentation says that it searches the directory
containing the header, then directories containing currently open
headers, then /I directories, then directories specified by the
INCLUDE environment variable.
<https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx>
So for these two implementations, the behavior is as you describe.
I didn't look up the docs on clang as it generally adopts the
behavior of gcc for compatibility, but it could also use the MSVC
algorithm when invoked with MS compatibility flags.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Cholo Lennon <cholo...@hotmail.com> spake the secret code
<npkq19$ibo$1...@gioia.aioe.org> thusly:
>Can I assume (in a portable sense) that /#include "some_header"/ will
>always start its search from the same directory that the file that is
>including it? (at least in g++ and VC++ this behavior is present)
implementation. So to answer your question you have to look at the
documentation for the implementation you're using.
For gcc, the documentation says that it searches the directory
containing the header, then -iquote directories, then normal POSIX
system directories.
<https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html>
For MSVC, the documentation says that it searches the directory
containing the header, then directories containing currently open
headers, then /I directories, then directories specified by the
INCLUDE environment variable.
<https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx>
So for these two implementations, the behavior is as you describe.
I didn't look up the docs on clang as it generally adopts the
behavior of gcc for compatibility, but it could also use the MSVC
algorithm when invoked with MS compatibility flags.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Cholo Lennon
Aug 24, 2016, 2:59:55 PM8/24/16
to
On 08/24/2016 03:53 PM, Stefan Ram wrote:
Well, yeah, you're right, but I see a lot of C/C++ "multi-platform" code
assuming that #include "..." will work as I described. That's why my
question... lot of non-portable code.
>
>> /16.2 Source file inclusion
>
> Why do you continue? You already
> have answered your question!
> Cholo Lennon <cholo...@hotmail.com> writes:
>> Can I assume (in a portable sense) that /#include "some_header"/ will
>> always start its search from the same directory that the file that is
>> including it? (at least in g++ and VC++ this behavior is present)
>> The standard seems not guarantee that ("file is searched for in an
>> implementation-defined manner"):
>
> So you answered you own question!
>> Can I assume (in a portable sense) that /#include "some_header"/ will
>> always start its search from the same directory that the file that is
>> including it? (at least in g++ and VC++ this behavior is present)
>> The standard seems not guarantee that ("file is searched for in an
>> implementation-defined manner"):
>
Well, yeah, you're right, but I see a lot of C/C++ "multi-platform" code
assuming that #include "..." will work as I described. That's why my
question... lot of non-portable code.
>
>> /16.2 Source file inclusion
>
> Why do you continue? You already
> have answered your question!
Cholo Lennon
Aug 24, 2016, 3:13:50 PM8/24/16
to
On 08/24/2016 03:57 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Cholo Lennon <cholo...@hotmail.com> spake the secret code
> <npkq19$ibo$1...@gioia.aioe.org> thusly:
>
>> Can I assume (in a portable sense) that /#include "some_header"/ will
>> always start its search from the same directory that the file that is
>> including it? (at least in g++ and VC++ this behavior is present)
>
> Not really. It depends on the search order specified by the
> implementation. So to answer your question you have to look at the
> documentation for the implementation you're using.
>
> For gcc, the documentation says that it searches the directory
> containing the header, then -iquote directories, then normal POSIX
> system directories.
> <https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html>
>
> For MSVC, the documentation says that it searches the directory
> containing the header, then directories containing currently open
> headers, then /I directories, then directories specified by the
> INCLUDE environment variable.
> <https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx>
>
> So for these two implementations, the behavior is as you describe.
>
> I didn't look up the docs on clang as it generally adopts the
> behavior of gcc for compatibility, but it could also use the MSVC
> algorithm when invoked with MS compatibility flags.
>
Ahh OK, useful answer, thanks!
> [Please do not mail me a copy of your followup]
>
> Cholo Lennon <cholo...@hotmail.com> spake the secret code
> <npkq19$ibo$1...@gioia.aioe.org> thusly:
>
>> Can I assume (in a portable sense) that /#include "some_header"/ will
>> always start its search from the same directory that the file that is
>> including it? (at least in g++ and VC++ this behavior is present)
>
> Not really. It depends on the search order specified by the
> implementation. So to answer your question you have to look at the
> documentation for the implementation you're using.
>
> For gcc, the documentation says that it searches the directory
> containing the header, then -iquote directories, then normal POSIX
> system directories.
> <https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html>
>
> For MSVC, the documentation says that it searches the directory
> containing the header, then directories containing currently open
> headers, then /I directories, then directories specified by the
> INCLUDE environment variable.
> <https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx>
>
> So for these two implementations, the behavior is as you describe.
>
> I didn't look up the docs on clang as it generally adopts the
> behavior of gcc for compatibility, but it could also use the MSVC
> algorithm when invoked with MS compatibility flags.
>
Bo Persson
Aug 25, 2016, 7:10:46 AM8/25/16
to
On 2016-08-24 20:46, Cholo Lennon wrote:
> Can I assume (in a portable sense) that /#include "some_header"/ will
> always start its search from the same directory that the file that is
> including it? (at least in g++ and VC++ this behavior is present)
>
> The standard seems not guarantee that ("file is searched for in an
> implementation-defined manner"):
>
>
The language standard does not limit itself to file systems with a
> Can I assume (in a portable sense) that /#include "some_header"/ will
> always start its search from the same directory that the file that is
> including it? (at least in g++ and VC++ this behavior is present)
>
> The standard seems not guarantee that ("file is searched for in an
> implementation-defined manner"):
>
>
directory structure. z/OS used on IBM mainframes is an important example.
So it might depend on exactly HOW portable you want to be.
Bo Persson
Cholo Lennon
Aug 25, 2016, 4:37:16 PM8/25/16
to
Linux and Solaris, so I suppose my code is "portable" across those
platforms.
Regards
Marcel Mueller
Aug 26, 2016, 4:33:36 AM8/26/16
to
On 25.08.16 22.36, Cholo Lennon wrote:
> Well, in my particular case I just need the same behavior on Windows,
> Linux and Solaris, so I suppose my code is "portable" across those
> platforms.
All of them have a directory structure and will look at the current
> Well, in my particular case I just need the same behavior on Windows,
> Linux and Solaris, so I suppose my code is "portable" across those
> platforms.
folder first.
I am in doubt that a platform exists, which has a concept of a directory
structure and which does not fulfill your requirement.
Marcel
Öö Tiib
Aug 26, 2016, 4:43:16 AM8/26/16
to
is to have every code file in whole product with name that starts with
latin character, contains only latin characters, arabic numbers, minuses,
underlines and dots *AND* is case-insensitively unique (regardless of
directory or library or module it is part of).
That sounds simple to follow so it may be surprise how hard it is in
practice in some situations and with bigger projects. However ... it will
reward you with no need to know all those details about every compiler
and file system targeted.
0 new messages