Will C++ include the ANSI C preprocessing feature of the "#"
(stringize) operator, e.g.

 #define a(x,y)  x = y; cout << #x << " = " << #y;

I ask because my compiler vendor (Lucid) notes that this
feature is supported in ansi-c mode only.
--
Mark Harrison, mharriso@dsccc.com

mharriso@digi.lonestar.org (Mark Harrison) writes:

>Will C++ include the ANSI C preprocessing feature of the "#"
>(stringize) operator, e.g.

> #define a(x,y)  x = y; cout << #x << " = " << #y;

>I ask because my compiler vendor (Lucid) notes that this
>feature is supported in ansi-c mode only.

Preprocessing in C++ is supposed to be the same as in Standard C
(except for // comments).  The ARM tries to say that, and the
C++ Standard will make it so.

Are you sure the Lucid compiler does not provide full Standard C
preprocessing in C++ mode?  Perhaps the manual is a bit misleading.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:

   Preprocessing in C++ is supposed to be the same as in Standard C
   (except for // comments).  The ARM tries to say that, and the
   C++ Standard will make it so.

By the way, does anybody ever thought of the problems that occurs between
preprocessors macros and templates.

If I define a macro that use *a type* as an argument, whenever I use
templates with multiple arguments in this macro, I have a problem :
the problem is coma. It's the *only* valid argument separator for
macros !
Isn't it time to betterize the standard C++ preprocessor.
Usefull features would be :
 1 - changing separator for a macro
 2 - enable macro overloading, you can do it with functions,
 why not with macros ? I don't ask for typed arguments,
 (it would be stupid), but for the number of arguments.
 3 - compile time vars, in order to save and restore contexts in macro
 it could be something like #define inside macros.
 this last one would be *very* usefull, but I think it's a dream.

However, the other 2 enhancement, seems sensible.
Yet, there is another way to bypass my problem : taking care of templates
*before* macros. If this were the case, my problem wouldn't occurs
any more.

In <KRISS.93Jan21114643@trot.ibp.fr> kriss@trot.ibp.fr (Christophe GROSJEAN) writes:

|"In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:
|"
|"   Preprocessing in C++ is supposed to be the same as in Standard C
|"   (except for // comments).  The ARM tries to say that, and the
|"   C++ Standard will make it so.
|"
|"By the way, does anybody ever thought of the problems that occurs between
|"preprocessors macros and templates.
|"
|"If I define a macro that use *a type* as an argument, whenever I use
|"templates with multiple arguments in this macro, I have a problem :
|"the problem is coma. It's the *only* valid argument separator for
|"macros !
|"Isn't it time to betterize the standard C++ preprocessor.
|"Usefull features would be :
|" 1 - changing separator for a macro
|" 2 - enable macro overloading, you can do it with functions,
|" why not with macros ? I don't ask for typed arguments,
|" (it would be stupid), but for the number of arguments.
|" 3 - compile time vars, in order to save and restore contexts in macro
|" it could be something like #define inside macros.
|" this last one would be *very* usefull, but I think it's a dream.
|"
|"However, the other 2 enhancement, seems sensible.
|"Yet, there is another way to bypass my problem : taking care of templates
|"*before* macros. If this were the case, my problem wouldn't occurs
|"any more.

I have successfully used the following trick:

#define COMMA ,

#define f(a,b) template a harry(List ## b);

f(<class some_class COMMA class some_class2>,
  < some_class COMMA some_class2 >);

(the macro isn't realistic, but it assumes a List class somewhere that can be
 instantiated through this macro)

This works, because the comma is expanded AFTER 'f' is expanded. It doesn't
work, however, if 'f' calls other macros that use arguments passed to your
first macro.
--
Ronald van Loon     | Consider this: In the United States, an automobile is
(rvloon@cv.ruu.nl)  | stolen EVERY 14.7 SECONDS.
3DCV Group, Utrecht |   If that statistic scares you, think how we felt when we
The Netherlands     | made it up. - Dave Barry, "CHRISTMAS BUYERS GUIDE"

In article <1993Jan19.181741.4779@taumet.com> steve@taumet.com (Steve Clamage) writes:
>
>Preprocessing in C++ is supposed to be the same as in Standard C
>(except for // comments).  The ARM tries to say that, and the
>C++ Standard will make it so.
>
>Are you sure the Lucid compiler does not provide full Standard C
>preprocessing in C++ mode?  Perhaps the manual is a bit misleading.

It turns out there are two C++ modes, -XF (ARM compatible) and -Xf
(cfront 2.1 compatible).  -XF uses ansi style preprocessing, while -Xf
uses K&R style.  The preprocessing style can be specified by using -XAp
for ansi preprocessing and -XKp for K&R style.

Jerry Schwartz (jss@lucid.com) was kind enough to point this out to me.
--
Mark Harrison, mharriso@dsccc.com