Hello,

I've got a question with regard to #include directives: Are tokens
following the included tokens available for preprocessing in the
context of the inclusion itself?

Following sample will hopefully explain what I mean:

file "y":
  #define TEST(z) z
  TEST(

file "x":
  #include "y"
  1)

Processing file "x", is it valid? Does it produce the pp-token "1"?

2.1/1/4 says:
  [...] A #include preprocessing directive causes the named header or
  source file to be processed from phase 1 through phase 4, recursively.

which, in my opinion, sounds as if the header or source file is
processed
"on its own", i.e. no further preprocessing tokens are available. That
would
cause the above mentioned example to fail.

However, 16.2/2 says (16.2/3 is similar):
  A preprocessing directive of the form # include <h-char-sequence>
new-line
  [...] causes the replacement of that directive by the entire contents
of
  the header.

which I understand as stating that processing header files is always
done
in the context of the file containing the #include directive, thereby
rendering the above example valid.

Can anyone clarify this issue?

Regards,
  Christoph


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

On Sat, 28 Jun 2003 00:52:05 +0000 (UTC), kristov@arcor.de ("Christoph
Schulz") wrote:

>Hello,
>
>I've got a question with regard to #include directives: Are tokens
>following the included tokens available for preprocessing in the
>context of the inclusion itself?
>
>Following sample will hopefully explain what I mean:
>
>file "y":
>  #define TEST(z) z
>  TEST(
>
>file "x":
>  #include "y"
>  1)
>
>Processing file "x", is it valid? Does it produce the pp-token "1"?
>
>2.1/1/4 says:
>  [...] A #include preprocessing directive causes the named header or
>  source file to be processed from phase 1 through phase 4, recursively.
>
>which, in my opinion, sounds as if the header or source file is
>processed
>"on its own", i.e. no further preprocessing tokens are available. That
>would
>cause the above mentioned example to fail.
>
>However, 16.2/2 says (16.2/3 is similar):
>  A preprocessing directive of the form # include <h-char-sequence>
>new-line
>  [...] causes the replacement of that directive by the entire contents
>of
>  the header.
>
>which I understand as stating that processing header files is always
>done
>in the context of the file containing the #include directive, thereby
>rendering the above example valid.
>
>Can anyone clarify this issue?
>

It won't work because there is no way to continue a line across
different files, AFAIK. Within the same file you would need a line
continuation character; there is no such character to continue a line
across different files, though.


--
Bob Hairgrove
rhairgroveNoSpam@Pleasebigfoot.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<rhairgrove@bigfoot.com> schrieb im Newsbeitrag
news:3efd55b5.2334556@news.webshuttle.ch...
> On Sat, 28 Jun 2003 00:52:05 +0000 (UTC), kristov@arcor.de ("Christoph
> Schulz") wrote:
>
> >Hello,
> >
> >I've got a question with regard to #include directives: Are tokens
> >following the included tokens available for preprocessing in the
> >context of the inclusion itself?
> >
> >Following sample will hopefully explain what I mean:
> >
> >file "y":
> >  #define TEST(z) z
> >  TEST(
> >
> >file "x":
> >  #include "y"
> >  1)
> >
> >Processing file "x", is it valid? Does it produce the pp-token "1"?
> >
> >[...]
>
> It won't work because there is no way to continue a line across
> different files, AFAIK. Within the same file you would need a line
> continuation character; there is no such character to continue a line
> across different files, though.
>

A line continuation isn't needed in the provided sample, because it's
an invocation of a function-like macro. For instance, the source file

  #define F(x) x  F
  (
  1
  )

would be a perfectly valid source file, without requiring the invocation
of macro F to exist on a single line.

The question is rather whether the invocation of a function-like macro
invocation can be splitted across different files. The answer boils
down to the interpretation of the sematics of the #include directive:
Is the included file scanned for itself, or are the tokens that
follow the #include directive available for macro expansion?

Regards,
  Christoph


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

"Christoph Schulz" wrote:

> The question is rather whether the invocation of a function-like macro
> invocation can be splitted across different files. The answer boils
> down to the interpretation of the sematics of the #include directive:
> Is the included file scanned for itself, or are the tokens that
> follow the #include directive available for macro expansion?

This is undefined behavior (see 6.10.3/11):

MACRO(
#include "file.h"
)

Regards,
Paul Mensonides

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

Sorry, bad reference in my other post.

6.10.3/11 is the location in the C99 standard.
16.3/10 is the location in the C++ standard.

Regards,
Paul Mensonides

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

Paul Mensonides wrote:
> "Christoph Schulz" wrote:
>
> > The question is rather whether the invocation of a function-like
macro
> > invocation can be splitted across different files. The answer boils
> > down to the interpretation of the sematics of the #include
directive:
> > Is the included file scanned for itself, or are the tokens that
> > follow the #include directive available for macro expansion?
>
> This is undefined behavior (see 6.10.3/11):
>
> MACRO(
> #include "file.h"
> )
>

This is not the problem I tried to describe. In your case, an #include
directive is positioned *within* an argument list for a macro invocation
of
a function-like macro. I agree with you completely that this is
undefined
behaviour.

In my case, I include a file which *starts* a function-like macro
invocation.
It is not completed in the included file, however, but in the including
file.
The question is: is such a construction allowed?

  file "y":
    #define TEST(z) z
    TEST(

  file "x":
    #include "y"
    1)


I think the relevant information is "hidden" in 2.1/1/4, 16.2/2, and
16.2/3.
But I'm not able to conclude whether the above mentioned sample is
allowed by
the standard.

Regards,
  Christoph


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

"Christoph Schulz" wrote:

> This is not the problem I tried to describe. In your case, an #include
> directive is positioned *within* an argument list for a macro
> invocation of
> a function-like macro. I agree with you completely that this is
> undefined
> behaviour.

Okay, sorry for the misunderstanding.

> In my case, I include a file which *starts* a function-like macro
> invocation.
> It is not completed in the included file, however, but in the
> including file.
> The question is: is such a construction allowed?
>
>   file "y":
>     #define TEST(z) z
>     TEST(
>
>   file "x":
>     #include "y"
>     1)
>
>
> I think the relevant information is "hidden" in 2.1/1/4, 16.2/2, and
> 16.2/3.
> But I'm not able to conclude whether the above mentioned sample is
> allowed by
> the standard.

Well, 2.1/1/4 says that #include directives causes recursive processing of
phases 1 *through* 4.  I think the wording causes it to mean that it must
recursively perform all four steps completely before "returning."  I agree that
it isn't as clear as it could be, but I think this is the intent.

Regards,
Paul Mensonides

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