While most people seem to want to eliminate the
preprocessor, I favor extending it. Here are a
few suggestions which I believe have merit...

------------------------------------------------------

Preprocessor functions may be overloaded based on the
number of parameters. Preprocessor functions which
take no parameters are legal. Thus, for example:

   #define abc
   #define abc()
   #define abc(x)
   #define abc(x,y)

are legal and distinct preprocessor functions.

------------------------------------------------------

Rescanning control. If #.( ... ) is encountered in a
macro expansion then the parentheses are deleted and
nothing inside of the parentheses is rescanned.
Conversely, if #*(...) is encountered in a macro
expansion then the parentheses are deleted and the
enclosed expression is then rescanned.

It is sometimes useful to explicitly control
preprocessor rescanning. Currently, it can be tricky
defining macros that only work with rescanning.

Also, the #* operator might be allowed in preprocessor
statements other than #define so that rescanning can
be applied. This can be very useful. Especially if the
result is then allowed to be a preprocessor statement.

------------------------------------------------------

Token chaining. Used to replace multiple tokens with
the value of the expression. The token chaining
operator #+ may not be used with macro functions. Thus

   #define int #+ long           __signed32
   #define int #+ long #+ signed __signed32
   #define int #+ signed         __signed32
   #define int #+ signed #+ long __signed32
   #define long                  __signed32
   #define long #+ int           __signed32
   #define long #+ int #+ signed __signed32
   #define long #+ signed        __signed32
   #define long #+ signed #+ int __signed32
   #define signed #+ int         __signed32
   #define signed #+ int #+ long __signed32
   #define signed #+ long        __signed32
   #define signed #+ long #+ int __signed32

could replace the "traditional" primitive type names
with the name of a class. The longest possible
definition is taken with no regard for the order in
which the definitions were seen by the preprocessor.
White space may separate the tokens being replaced.

This can allow the use of multiword user names in the
same manner as is used for the primitive type names.
In particular, it could be used with the existing
primitive type names where the compiler includes a
default header file <standard> automatically at the
start of each translation unit. Then the actual C++
grammar could be simplified by replacing the complex
primitive name grammar by a simple list of names.

Even though token chaining may not be used with macro
functions, the same effect can be obtained. E.g.

   #define function #+ name   functionName
   #define functionName(x) (x * x)

if the following is encountered...

   function name(abc)

it will be expanded to...

   functionName(abc)

and then rescanned...

   (abc * abc)

so that the same result is obtained as the
(illegal) definition...

   #define function #+ name(x)   (x * x)

Note: From an implementation point, there may be no
      point in restricting macro functions to be
      single tokens, so this restriction may be
      removed without cost, but if it is desirable
      this example shows that such a restriction
      isn't harmful.

------------------------------------------------------

The #comment preprocessor directive could be used to
tell the preprocessor about comment syntax. It has the
format:

   #comment <start string> <end string>

While there should be no need to define existing C++
comments, they could be defined by:

   #comment "/*"  "*/"
   #comment "//"  "\n"

but other formats could be supported. For example:

   #comment "(*"  "*)"

for PASCAL-like comments. Or a code generator could
define special comment markers to distinguish control
information for the code generator and still have the
compiler ignore the text. Or a code browser could
define special comment markers for hypertext comments
to allow a "flat" form of the comment. For example:

   #comment "<<*"    "*>>"

with a usage like...

   <<*23.8*25.10* This is a hypertext comment
   linked to a rectangle in the source code.*>>

Just as interesting would be something like:

   #comment "\n" "|"

which would result in all text at the start of the
line, up to | to be considered as comments. That
could be used for code annotation. The very first
line would either not allow a comment or it could be
considered as being preceded by an imaginary new line
for this purpose.

Note: Comment nesting is not allowed. Once a comment
      is recognized, then everything up to the
      matching comment delimiter is considered to be
      part of the comment. This means that any other
      comment delimiters inside the comment have no
      special significance. It does interact with line
      splicing when a physical source line ends with
\
      and the ending comment delimiter is "\n".

Note: If there were a <standard> header file as
      mentioned above, then it might be beneficial to
      not predefine ANY comment syntax and define even
      the standard comment syntax using the #comment
      directive.

------------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <MPG.156b7885c4b3d4dc98972f@news.lynchburg.net>, Michael Lee
Finney <michael.finney@acm.org> writes
>While most people seem to want to eliminate the
>preprocessor, I favor extending it. Here are a
>few suggestions which I believe have merit...

If you want such things you will need to do much more than just express
a wish. You will have to persuade quite a few people that, despite their
capacity for wrecking havoc, they have counter balancing advantages. The
best way to do this is to implement such a pre-processor yourself and
demonstrate that it is useful to you and your colleagues.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]