www.digitalmars.com         C & C++   DMDScript  

c++ - preprocessor bug and woes

reply Larry Brasfield <larry_brasfield snotmail.com> writes:
This report documents 2 bugs and laments a problem I 
have been unable to solve using the DMC compiler.

Bug #1. Given this program:
========================================================
  #define PASS_THRU(x) x
  #define NN() PASS_THRU(name_) ## PASS_THRU(__LI ## NE__)
  int NN();
  int NN();
========================================================
the DMC compiler chokes thusly:
  > sc -c pp.cpp
  int NN();
        ^
  pp.cpp(4) : Error: 'name_PASS_THRU' is already defined
  --- errorlevel 1

I believe that both operands of the ## paste operator
are supposed to be evaluated prior to the paste.  The
DMC compiler appears to evaluate the two sides in a
dissymmetric manner.

For example, Microsoft's preprocessor converts it properly:
  > cl /E pp.cpp
  Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
  Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

  #line 1 "pp.cpp"


  int name_3;
  int name_4;

Bug #2.  I have been been unable to get SC.exe to show 
me the preprocessed form of any code.  Its help claims 
that invoking it with a -e option will "show results of 
preprocessor", but that option does not cause anything
more to show up on stdout or in any likely directory.

Lament:
I am trying to create some kind of build time assert
facility for DMC.  I used to use something like
  #define BuildAssert(condition) \
   extern char _dummyAssert[ (condition)? 1 : -1 ]
but DMC happily compiles this with a negative integer
as the array size.  I can define a template and its
specialization that will fail when instantiated upon
a false argument, but I have completely struck out
trying to define a macro to instantiate objects that
have different names depending on the source line
in which the macro is expanded.  (Hence my failed
effort leading to the above bug report.)


-- 
-Larry Brasfield
(address munged, s/sn/h/ to reply)
Aug 12 2002
parent Jan Knepper <jan smartsoft.cc> writes:
Larry Brasfield wrote:

 This report documents 2 bugs and laments a problem I
 have been unable to solve using the DMC compiler.

 Bug #1. Given this program:
 ========================================================
   #define PASS_THRU(x) x
   #define NN() PASS_THRU(name_) ## PASS_THRU(__LI ## NE__)
   int NN();
   int NN();
 ========================================================
 the DMC compiler chokes thusly:
   > sc -c pp.cpp
   int NN();
         ^
   pp.cpp(4) : Error: 'name_PASS_THRU' is already defined
   --- errorlevel 1

 I believe that both operands of the ## paste operator
 are supposed to be evaluated prior to the paste.  The
 DMC compiler appears to evaluate the two sides in a
 dissymmetric manner.

 For example, Microsoft's preprocessor converts it properly:
   > cl /E pp.cpp
   Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
   Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

   #line 1 "pp.cpp"

   int name_3;
   int name_4;

That one is for Walter.
 Bug #2.  I have been been unable to get SC.exe to show
 me the preprocessed form of any code.  Its help claims
 that invoking it with a -e option will "show results of
 preprocessor", but that option does not cause anything
 more to show up on stdout or in any likely directory.

I think you will have to use -l -e The results of the preprocessing will appear in the .lst file. I think that is how it works.
 Lament:
 I am trying to create some kind of build time assert
 facility for DMC.  I used to use something like
   #define BuildAssert(condition) \
    extern char _dummyAssert[ (condition)? 1 : -1 ]
 but DMC happily compiles this with a negative integer
 as the array size.

Well, I guess that is because -1 is -1 in 'signed integer' notation. I think DMC treats the -1 as unsigned 0xFFFFFFFF...
 I can define a template and its
 specialization that will fail when instantiated upon
 a false argument, but I have completely struck out
 trying to define a macro to instantiate objects that
 have different names depending on the source line
 in which the macro is expanded.  (Hence my failed
 effort leading to the above bug report.)

Aug 12 2002