NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/17851

Text File | 1992-12-12 | 3.5 KB | 64 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!erc
From: [e-mail] (Eric Smith)
Subject: Re: Criticisms Wanted:Callbacks&Runtime methods
Message-ID: <[e-mail]>
Keywords: callbacks C++ Runtime methods
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <[e-mail]>
Date: Sat, 12 Dec 1992 12:48:39 GMT
Lines: 52

In article <[e-mail]> [e-mail] (The Man Behind The Curtain) writes:
>A macro language would be incredibly useful, but that'd be dreaming.

I've got that on the back burner.  My parser, which contains its own
preprocessor, already has some extra macro features I'm using, and I'm
planning to release a very powerful extended C++ preprocessor in the
future, which will evolve from it.  I'm using it right now as a
preprocessor even with C++ compilers that don't have a separate
preprocessor, just adding mine as an extra initial stage in the
makefile.  But it doesn't take much extra time because doing the
preprocessing in advance reduces the workload on the C++ compiler,
thereby making it faster.

The extra feature I find most useful right now is being able to define
new macros from within a macro, using the outer macro's arguments to
change the definition of the inner macro, and its name, etc.  This in
fact gives me some of the most important advantages of templates when
using a C++ compiler that doesn't support templates.

I'm also experimenting with supporting macro scope.  I plan to support
both old style macros, for which you use #define, and my new style
macros, for which you would use a different word such as #macro,
although right now it's just #m.  (But it's trivial to change.)
Anyway, for scope, my new style macros have the scope of the block they
are defined in, and old style macros still have to-end-of-file scope.

Using block scope for macros requires more parsing than most C/C++
preprocessors do, and in fact mine completely parses and error checks
the whole program while preprocessing it.  But fortunately I use a
very fast parsing algorithm, so it doesn't really waste much time
duplicating the compiler's efforts.  It also makes it easier to
"pulverize" the code for compilers that can't handle complicated
code due to compiler bugs.

Old style macros are effectively one line of code each, with additional
lines being appended at the end of that line.  That prohibits defining
new macros from inside a macro, because a macro definition has to be at
the start of a line.  So my new style macros allow multiple lines
without the backslash at the end of each line, but require a
termination token for the whole macro.  So macro definitions inside
macros are trivial with my new style macros.  (Don't confuse macro
calls inside macros with macro definitions inside macros.  It's the
definitions, not the calls, that give template-like power.)  I also
allow new style macro call arguments to follow the macro name directly,
without parentheses.  That could be considered a 2nd new style,
although my parser considers it a minor variation of my first new
style.  In that 2nd new style, the macro arguments are delimited not
with commas and parentheses, but differently in several ways, with the
aim of making them fit neatly in tables, usually with one macro call
per line of the table.  A neatly tabulated table is often the best way
to code a set of rules and exceptions, so I use that format a lot in
the source code of my C++ parser.