• Larry Brasfield <larry_brasfield snotmail.com> Aug 12 2002
• Jan Knepper <jan smartsoft.cc> Aug 12 2002

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)

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.)