Question about comment parsing between C and C++ compiler

[linq936]

Hi,
I am reading book <<Expert C Programming>>, it has the following
quiz,

a //*
//*/ b

In C and C++ compiler what does the above code trun out?

I think it is simple for C compiler, it is a/b.

But for C++ compiler, the book says it is a. The reason is "//"
makes the rest of line comment.

I am wondering on this.

Just couple page back, it mentions that compiler has a "maximal
munch strategy". For me when the C++ compiler reads the 1st line,
there is ambiguous intepretation, it could be "a// *" or "a / /*",
then if we apply the "maximal much strategy", it should use the second
one and parse the code to

a / /*
// */ b

which is a/b.

I think I am confused at somewhere, could you shed some light?

Thanks.

[pete]

li*****@hotmail .com wrote:

>
Hi,
I am reading book <<Expert C Programming>>, it has the following
quiz,

a //*
//*/ b

In C and C++ compiler what does the above code trun out?

I think it is simple for C compiler, it is a/b.

But for C++ compiler, the book says it is a. The reason is "//"
makes the rest of line comment.

I am wondering on this.

Just couple page back, it mentions that compiler has a "maximal
munch strategy". For me when the C++ compiler reads the 1st line,
there is ambiguous intepretation, it could be "a// *" or "a / /*",
then if we apply the "maximal much strategy", it should use the second
one and parse the code to

a / /*
// */ b

which is a/b.

I think I am confused at somewhere, could you shed some light?

What does "maximal munch strategy" mean?

--
pete

[Richard Heathfield]

li*****@hotmail .com said:

Hi,
I am reading book <<Expert C Programming>>, it has the following
quiz,

a //*
//*/ b

In C and C++ compiler what does the above code trun out?

I think it is simple for C compiler, it is a/b.

It's fairly simple, but nowadays it is not quite as simple as you make
out. What PvdL didn't realise was that //-comments would be introduced
into C in the 1999 language revision!

But for C++ compiler, the book says it is a. The reason is "//"
makes the rest of line comment.

Yeah.

I am wondering on this.

Just couple page back, it mentions that compiler has a "maximal
munch strategy".

Grab the biggest token you can, yes.

For me when the C++ compiler reads the 1st line,

there is ambiguous intepretation, it could be "a// *" or "a / /*",

No, it can't be either of those. It could be

a / /*

or

a // *

and maximal munch dictates the second.

Whether C++ actually has a maximal munch rule is a question that our
friends in comp.lang.c++ would undoubtedly be able to answer.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

pete <pf*****@mindsp ring.comwrites:
[...]

What does "maximal munch strategy" mean?

It means that, when determining the next token, the compiler grabs as
many characters as possible to get a valid token.

For example, this:

x+++++y

is tokenized as

x ++ ++ + y

which results in a syntax error, even though this:

x ++ + ++ y

would result in a valid parse. (Tokenization doesn't account for
later phases.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Rg]

On 7 maio, 03:14, Keith Thompson <[e-mail] ote:

>
[...]

It means that, when determining the next token, the compiler grabs as
many characters as possible to get a valid token.

[...]

It other words, it means the lexical analyzer is greedy.

Ain't that much simpler to say?

[Old Wolf]

On May 7, 4:05 pm, Richard Heathfield <[e-mail].i nvalidwrote:

Whether C++ actually has a maximal munch rule is a question that our
friends in comp.lang.c++ would undoubtedly be able to answer.

C++98 does (I'll save the OP the effort of making a new post there).

Off-topic but possibly interesting aside: C++ uses "<" and
">" like brackets in some contexts, but the maximal munch
rule has the effect that <a<b>gets parsed unexpectedly
because the closing chevrons get tokenised as the right-shift
operator.

There's been a DR accepted to change this so that >is not
maximally munched in this situation -- for better or worse.

[Richard Heathfield]

Old Wolf said:

On May 7, 4:05 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>Whether C++ actually has a maximal munch rule is a question that our
friends in comp.lang.c++ would undoubtedly be able to answer.

C++98 does (I'll save the OP the effort of making a new post there).

Off-topic but possibly interesting aside: C++ uses "<" and
">" like brackets in some contexts, but the maximal munch
rule has the effect that <a<b>gets parsed unexpectedly
because the closing chevrons get tokenised as the right-shift
operator.

I don't see why that's unexpected. Maximum munch is hardly a secret in
C, and I presume it's no secret in C++ either. I didn't know it applied
in C++, but in my C++ programming I have always conservatively assumed
that it does.

There's been a DR accepted to change this so that >is not
maximally munched in this situation -- for better or worse.

It's for worse. Hard cases make bad law.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <t9************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>There's been a DR accepted to change this so that >is not
maximally munched in this situation -- for better or worse.

>It's for worse. Hard cases make bad law.

Unless the exception proves the rule.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Richard Tobin said:

In article <t9************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>>There's been a DR accepted to change this so that >is not
maximally munched in this situation -- for better or worse.

>>It's for worse. Hard cases make bad law.

Unless the exception proves the rule.

No, not really. Exceptions are sometimes necessary, but never elegant.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Old Wolf]

On May 8, 10:12 am, Richard Heathfield <[e-mail].i nvalidwrote:

Old Wolf said:

There's been a DR accepted to change this so that >is not
maximally munched in this situation -- for better or worse.

It's for worse. Hard cases make bad law.

Funny situation really. I assume the DR came about because
many newbies were being tripped up by the situation; maximal
munch must be 'unintuitive' for most people. As it is for me,
I might add; my mind tends to parse a sentence in the way
that makes the most sense and I suspect others' minds work
that way too (as evinced by the fact that people can read
all sorts of mis-spelled garbage). In the <a<b>case, the
pairs of matching chevron brackets is clearly what was intended.

Of course it makes the compiler writers' job harder too, but
C++ parsing is already so convoluted and context sensitive
that the horse has long since bolted on the idea of having
an easily-parsable syntax.