Rules for #define

[JKop]

#define LRESULT long
Here's what I have so far:
1) The # must be the first non-white-space character on the line.
2) There may be any number of white-space characters between # and "define".
3) Any number of white space characters may reside between LRESULT and long,
but the minimum amount is 1.
4) White-space characters before and after "long" are not substituted in the
file.
5) If it's multiline, as in:

# define LRESULT \
long

then the backward slash must *immediately* preceed the '\n'.

That's all I've got so far. So what I'm looking to find out is:
A) Many any amount of white-space characters seperate "define" and
"LRESULT"?
B) Is the following legal?:

#\
def\
ine \
LRESULT \
long

C) What signals the end of the directive, is it '\n'? If you have a
directive at the very end of the file, and there's no '\n' at the end, then
is the directive valid?
D) What's a white-space character? Can anyone list them. Here's the ones I
know:

' ' (space)
' ' (horizontal tab... does it have a "universal" code, as does
'\n'?)

-JKop

[Ivan Vecerina]

"JKop" <NU**@NULL.NULL> wrote in message
news:yQ*******************@news.indigo.ie...

#define LRESULT long
Here's what I have so far:
1) The # must be the first non-white-space character on the line.
2) There may be any number of white-space characters between # and
"define".
3) Any number of white space characters may reside between LRESULT and
long,
but the minimum amount is 1.
4) White-space characters before and after "long" are not substituted in
the
file.
5) If it's multiline, as in:

# define LRESULT \
long

then the backward slash must *immediately* preceed the '\n'.

That's all I've got so far. So what I'm looking to find out is:
One key thing: comments may be included! and they count as whitespace:
/* */ or // \n
A) Many any amount of white-space characters seperate "define" and
"LRESULT"? yes
B) Is the following legal?:

#\
def\
ine \ no: \\ + \n counts as whitespace LRESULT \
long

C) What signals the end of the directive, is it '\n'? If you have a
directive at the very end of the file, and there's no '\n' at the end,
then
is the directive valid? An ISO C++ conformant source file is *required* to end with a \n.
D) What's a white-space character? Can anyone list them. Here's the ones I
know: This is platform-dependent, and specified by 'isspace()' in <cctype>
' ' (space)
' ' (horizontal tab... does it have a "universal" code, as does Yes: \t '\n'?)

I typically also include: \r
This said, if you are working on parsing a C++ file, I would
recommend using a dedicated tool, such as GNU flex, boost::spirit.
It will save you a lot of time and effort...
Cheers,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Jeff Flinn]

> B) Is the following legal?:

Why does it matter. I thought you were only concerned with the laws of
physics?

AASP ( Avoid Admitted Software Pirates )

Jeff F

[JKop]

Jeff Flinn posted:

B) Is the following legal?:

Why does it matter. I thought you were only concerned with the laws of
physics?

AASP ( Avoid Admitted Software Pirates )

Jeff F

Looks like some-one's never encountered homonyms.
-JKop

[Chris Theis]

"JKop" <NU**@NULL.NULL> schrieb im Newsbeitrag
news:yQ*******************@news.indigo.ie...

#define LRESULT long
Here's what I have so far:
1) The # must be the first non-white-space character on the line.
2) There may be any number of white-space characters between # and "define".

3) Any number of white space characters may reside between LRESULT and long, but the minimum amount is 1.
4) White-space characters before and after "long" are not substituted in the file.
5) If it's multiline, as in:

# define LRESULT \
long

then the backward slash must *immediately* preceed the '\n'.

That's all I've got so far. So what I'm looking to find out is:
A) Many any amount of white-space characters seperate "define" and
"LRESULT"?
Yes.


B) Is the following legal?:

#\
def\
ine \
LRESULT \
long
Yes it is. Each new-line character with an immediately preceeding backslash
is deleted in the second translation phase.
C) What signals the end of the directive, is it '\n'? If you have a
directive at the very end of the file, and there's no '\n' at the end, then is the directive valid?

For any non-empty source file that does not end in a new-line character the
behavior is undefined. This is also valid for non-empty files that end in a
new-line character with a preceeding backslash.

D) What's a white-space character? Can anyone list them. Here's the ones I
know:

' ' (space)
' ' (horizontal tab... does it have a "universal" code, as does
'\n'?)

The standard specifies space, horizontal-tab, new-line, vertical-tab, and
form-feed as white-space characters.

HTH
Chris

[Chris Theis]

"Chris Theis" <Ch*************@nospam.cern.ch> schrieb im Newsbeitrag
news:ck**********@sunnews.cern.ch...

[SNIP]

If you're really going for it you should also pay attention to tri-graph
sequences.

Cheers
Chris

[JKop]

Chris Theis posted:

"Chris Theis" <Ch*************@nospam.cern.ch> schrieb im Newsbeitrag
news:ck**********@sunnews.cern.ch...

[SNIP]

If you're really going for it you should also pay attention to tri-graph
sequences.

Cheers
Chris

Well so far I've got approx. 539 lines of code written...
Anyway, once I've "processed" a #define statement, I'm going to have it all
nicely cleaned up, all white-space characters removed, and it'll be passed
to:

void AnalyzeDefineDirective(std::string const &first, std::string const
&second);
From there, that particular function won't have to worry about white spaces
(including comments). It'll compute "is parameter 2 an intrinsic type?", "is
parameter 2 a literal", "is parameter 1 a macro function"... and so on.
-JKop

[David Lindauer]

JKop wrote:

#define LRESULT long

Here's what I have so far:

1) The # must be the first non-white-space character on the line.
2) There may be any number of white-space characters between # and "define".

3) Any number of white space characters may reside between LRESULT and long,
but the minimum amount is 1.

4) White-space characters before and after "long" are not substituted in the
file.

5) If it's multiline, as in:

# define LRESULT \
long

then the backward slash must *immediately* preceed the '\n'.

That's all I've got so far. So what I'm looking to find out is:

A) Many any amount of white-space characters seperate "define" and
"LRESULT"?

yes that should be fine.

B) Is the following legal?:

#\
def\
ine \
LRESULT \
long

I think that *may* not be legal, because the newlines are treated as
whitespace. Borland won't compile it at any rate...

C) What signals the end of the directive, is it '\n'? If you have a
directive at the very end of the file, and there's no '\n' at the end, then
is the directive valid?

yes newline terminates the directive. technically, the directive isn't valid at
the end of the file if there is no newline.. The standards say that input files
MUST be terminated by a newline; deviating from this causes undefined behavior.
Practically speaking, some compilers will let you get by with it. And some
won't. I used to have all sorts of troubles because I had an editor that
constantly stripped the newline from the end of the file... windows compilers
were forgiving but an embedded compiler I used just discarded the last line in
that case, if that line was a directive.

D) What's a white-space character? Can anyone list them. Here's the ones I
know:

' ' (space)
' ' (horizontal tab... does it have a "universal" code, as does
'\n'?)

I'm not sure what the standards say. the C language iswhitespace() seems to
consider the following things as space characters '\t' (universal code for tab)
'\n' \x0b' (???) '\x0c' (form feed) '\r' (universal code for CR). I have a
group of files I use that have embedded form feeds (I think the author set it up
to pretty-print the files one function per page) and I know the compilers I've
run them through do treat them as white space.

David

[Chris Theis]

"JKop" <NU**@NULL.NULL> schrieb im Newsbeitrag
news:Ga*******************@news.indigo.ie...

Chris Theis posted:

"Chris Theis" <Ch*************@nospam.cern.ch> schrieb im Newsbeitrag
news:ck**********@sunnews.cern.ch...

[SNIP]

If you're really going for it you should also pay attention to tri-graph
sequences.

Cheers
Chris

Well so far I've got approx. 539 lines of code written...
Anyway, once I've "processed" a #define statement, I'm going to have it

all nicely cleaned up, all white-space characters removed, and it'll be passed
to:

void AnalyzeDefineDirective(std::string const &first, std::string const
&second);
From there, that particular function won't have to worry about white spaces (including comments). It'll compute "is parameter 2 an intrinsic type?", "is parameter 2 a literal", "is parameter 1 a macro function"... and so on.

It would be interesting to see that code if you have a running version.

Chris

[Chris Theis]

"David Lindauer" <ca*****@bluegrass.net> schrieb im Newsbeitrag
news:41***************@bluegrass.net...
[SNIP]

B) Is the following legal?:

#\
def\
ine \
LRESULT \
long

I think that *may* not be legal, because the newlines are treated as
whitespace. Borland won't compile it at any rate...

Actually the example given above is compliant with the standard, which says
that new-lines with preceeding backslashes are treated in a special way. The
whole statement is concatenated before the preprocessor & the syntax
checking kicks in.

[SNIP]

D) What's a white-space character? Can anyone list them. Here's the ones I know:

' ' (space)
' ' (horizontal tab... does it have a "universal" code, as does
'\n'?)
I'm not sure what the standards say. the C language iswhitespace() seems

to consider the following things as space characters '\t' (universal code for tab) '\n' \x0b' (???) '\x0c' (form feed) '\r' (universal code for CR). I have a group of files I use that have embedded form feeds (I think the author set it up to pretty-print the files one function per page) and I know the compilers I've run them through do treat them as white space.

The standard specifies space, horizontal-tab, new-line, vertical-tab, and
form-feed as white-space characters.

Cheers
Chris