Quote-Dot-Quote Operator

[kvnsmnsn]

I'm taking a look at some existing C++ code and trying to figure out
what it's doing. It says:

static char const *abc[] = {
"DEF", DEF,
"GHI", PQR_PQR_STRING "."
PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2),
"JKL", JKL,
"MNO", "M_N_O",
0
};

where <DEFand <JKLare defined in <#include>ed header files in the
local directory, and I assume all the <PQR_*entities are included in
header files somewhere. (I've changed all the variable names from
what the existing code says so that I can post this here.)

Now, apparently this is saying that the type of expression
<PQR_PQR_STRING "." PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2)is <char *>, be-
cause it's included as an element of the <abcarray. But is
<PQR_PQR_STRING "." PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2)even _valid syn-
tax_? It seems to be implying that quote-dot-quote is a valid opera-
tor, and if it is, that's news to me.

If someone can tell me why this compiles and what it means, I'd be
really, really grateful.

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

[Ian Collins]

kv******@hotmail.com wrote:

I'm taking a look at some existing C++ code and trying to figure out
what it's doing. It says:

static char const *abc[] = {
"DEF", DEF,
"GHI", PQR_PQR_STRING "."
PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2),
"JKL", JKL,
"MNO", "M_N_O",
0
};

where <DEFand <JKLare defined in <#include>ed header files in the
local directory, and I assume all the <PQR_*entities are included in
header files somewhere. (I've changed all the variable names from
what the existing code says so that I can post this here.)

Now, apparently this is saying that the type of expression
<PQR_PQR_STRING "." PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2)is <char *>, be-
cause it's included as an element of the <abcarray. But is
<PQR_PQR_STRING "." PQR_PQR_FUNC(PQR_VAR1, PQR_VAR2)even _valid syn-
tax_? It seems to be implying that quote-dot-quote is a valid opera-
tor, and if it is, that's news to me.

Hard to say without seeing the macros. They probably produce quoted
strings. The pre-processor will concatenate string literals into one
token, so

"1" "." "2" will be concatenated to "1.2".

--
Ian Collins.

[Frank Birbacher]

Hi!

Stefan Ram schrieb:

Preprocessing directives are executed and macro invocations
are expanded in translation phase 4, while adjacent ordinary
string literal tokens are concatenated in translation phase 6
(ISO/IEC ISO/IEC 14882:2003(E), 2.1).

Should that me the compiler concatenates them instead of the preprocessor?

Frank

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-06-14 15:25, Frank Birbacher wrote:

Hi!

Stefan Ram schrieb:

> Preprocessing directives are executed and macro invocations
are expanded in translation phase 4, while adjacent ordinary
string literal tokens are concatenated in translation phase 6
(ISO/IEC ISO/IEC 14882:2003(E), 2.1).

Should that me the compiler concatenates them instead of the preprocessor?

Not necessarily, the standard does not define who does what.

--
Erik Wikström

[James Kanze]

On Jun 14, 9:07 pm, Erik Wikström <[e-mail]:

On 2008-06-14 15:25, Frank Birbacher wrote:

Stefan Ram schrieb:

Preprocessing directives are executed and macro invocations
are expanded in translation phase 4, while adjacent ordinary
string literal tokens are concatenated in translation phase 6
(ISO/IEC ISO/IEC 14882:2003(E), 2.1).

Should that me the compiler concatenates them instead of the
preprocessor?

Not necessarily, the standard does not define who does what.

More exactly, it defines it differently in different places.
Section 16 is "Preprocessing directives", treats the
preprocessor, and there's certainly no concatentation of string
literals there. On the other hand, "Each preprocessing token is
converted into a token" in phase 7, which certainly sounds to me
like everything earlier (including the concatenation of string
literals in phase 6) is preprocessor.

I don't think it really matters. The important thing is that it
happens. Before "The resulting tokens are syntactically and
semantically analyzed and translated as a translation unit."
(Which is interesting in itself. Why didn't they just define a
production for concatenating string literals?)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]