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)

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