www.digitalmars.com         C & C++   DMDScript  

D - Macros

reply "Richard Krehbiel" <rich kastle.com> writes:
Okay, why is it that everybody thinks the C preprocessor is terrible and

don't have one.  I just don't get this one.

I personally have wished for *more* macro processing power.

Not for typedefs.  Not for constant definitions.  Not for #include files or
guards.  For *macros*.

By "macros" I mean something that lets a programmer add power to the
language translator.  Something with access to the type system of the
compiler.  So I could write a generic macro that iterates through the
members of any given structure and generate code to print them in context.
So that I can write a package of macros that simplify binding SQL
parameters, because it can detect data types.  So that I can write generics
and templates using macros.

Cut from the language document:

"But [macros] have a downside:
Macros have no concept of scope; they are valid from the point of definition
to the end of the source. They cut a swath across .h files, nested code,
etc. When #include'ing tens of thousands of lines of macro definitions, it
becomes problematicalto avoid inadvertent macro expansions."

So, invent reasonable scoping and naming rules.  I don't need cpp
specifically; I just want macros.

"Macros are unknown to the debugger. Trying to debug a program with symbolic
data is undermined by the debugger only knowing about macro expansions, not
themacros themselves."

This need not be true, even in C.

"Macros make it impossible to tokenize source code, as an earlier macro
change can arbitrarilly redo tokens."

Um - I don't understand this at all.

"The purely textual basis of macros leads to arbitrary and inconsistent
usage, making code using macros error prone. (Some attempt to resolve this
was introduced with templates in C++.)"

Take the "purely textual basis" away, and give the macro language access to
the type system.

"Macros are still used to make up for deficits in the language's expressive
capabiltiy, such as for "wrappers" around header files."

But since you're fixing those language deficits, macros won't be used for
that anymore.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 16 2001
next sibling parent Richard Burk <sfentress home.com> writes:
As far as providing some sort of macro language to the system I would
recommend that generics be used modelled after generics in Ada.  I programmed in

Ada83 for three years solid.  Generics did full type checking and allowed for
rapid
development of lists, stacks, etc of various types.  I highly recommend the
generics
model from Ada.  I have little experience with Ada95, but it extended the power
of generics and what little experience I had with it was quite impressive.
Unfortunately the project I was on was killed.  I have been doing C, C++, and
Java mostly since.  I agree that the template implementation in C++ is horribly
implemented.  In fact I used macros to do the same as templates in C++, but it
was
really more like using generics in Ada except without the strong type checking
of
Ada.  I believe that Java suffers from the lack of generics/templates.
Hopefully
when they add it, it will be modelled from Ada.  For D I believe that it would
be
wise to add generics.  When they are done well as in Ada they are most
powerful.

Richard Burk


Richard Krehbiel wrote:


 Okay, why is it that everybody thinks the C preprocessor is terrible and

 don't have one.  I just don't get this one.

 I personally have wished for *more* macro processing power.

 Not for typedefs.  Not for constant definitions.  Not for #include files or
 guards.  For *macros*.

 By "macros" I mean something that lets a programmer add power to the
 language translator.  Something with access to the type system of the
 compiler.  So I could write a generic macro that iterates through the
 members of any given structure and generate code to print them in context.
 So that I can write a package of macros that simplify binding SQL
 parameters, because it can detect data types.  So that I can write generics
 and templates using macros.

 Cut from the language document:

 "But [macros] have a downside:
 Macros have no concept of scope; they are valid from the point of definition
 to the end of the source. They cut a swath across .h files, nested code,
 etc. When #include'ing tens of thousands of lines of macro definitions, it
 becomes problematicalto avoid inadvertent macro expansions."

 So, invent reasonable scoping and naming rules.  I don't need cpp
 specifically; I just want macros.

 "Macros are unknown to the debugger. Trying to debug a program with symbolic
 data is undermined by the debugger only knowing about macro expansions, not
 themacros themselves."

 This need not be true, even in C.

 "Macros make it impossible to tokenize source code, as an earlier macro
 change can arbitrarilly redo tokens."

 Um - I don't understand this at all.

 "The purely textual basis of macros leads to arbitrary and inconsistent
 usage, making code using macros error prone. (Some attempt to resolve this
 was introduced with templates in C++.)"

 Take the "purely textual basis" away, and give the macro language access to
 the type system.

 "Macros are still used to make up for deficits in the language's expressive
 capabiltiy, such as for "wrappers" around header files."

 But since you're fixing those language deficits, macros won't be used for
 that anymore.

 --
 Richard Krehbiel, Arlington, VA, USA
 rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 16 2001
prev sibling next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
I don't really like macros.  Perhaps that should be "I really don't like 
macros".
However ..., perhaps instead:
1) OTOH, generics are quite useful.  They have been shown to work well 
when designed into a language.
2) And "some sort" of preprocessing would be useful.  However, since the 
language is designed to be embedded in HTML, perhaps it could also be 
embedded in XML.  This would allow any XML aware tool to act as a 
pre-processor.  It wouldn't need to be a basic part of the language 
definition, but could just be a ... reccomended practice?  Annex? 
Optional extra?  It would really be more a part of the "IDE" than of the 
language, but it could do type-aware substitutions creating "temporary 
files" that were fed to the compiler as needed.
Aug 16 2001
prev sibling next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Richard Krehbiel wrote:

 
 Okay, why is it that everybody thinks the C preprocessor is terrible and

 don't have one.  I just don't get this one.


As you rightly note, the C preprocessor isn't powerful enough for 
general macro work. I think the usual position is that if you want
macros, you should be using a dedicated macro processor that's 
better than C's, and that typedefs, constants, and inclusion 
should be part of the language instead of a bag on the side.
 

 I personally have wished for *more* macro processing power.
 
 Not for typedefs.  Not for constant definitions.  Not for #include files or
 guards.  For *macros*.


Have you looked into m4?

-Russell B
Aug 16 2001
parent "Richard Krehbiel" <rich kastle.com> writes:
"Russell Bornschlegel" <kaleja estarcion.com> wrote in message
news:3B7C44FB.CC45479D estarcion.com...

 Richard Krehbiel wrote:

 Okay, why is it that everybody thinks the C preprocessor is terrible and





D

 don't have one.  I just don't get this one.


 As you rightly note, the C preprocessor isn't powerful enough for
 general macro work. I think the usual position is that if you want
 macros, you should be using a dedicated macro processor that's
 better than C's, and that typedefs, constants, and inclusion
 should be part of the language instead of a bag on the side.


I want a macro language that is *more* tightly integrated, with access to
the type system, and a macro language that looks more like the subject
language than an add-on.

So I can write a macro something like this:

macro trace_var(indent, var)
{
    printf("%*s%s %s=", indent, "", typename(var), name(var));
    if(promoted(typeof(var)) == typeof(int))
        printf("%d", var);
    else if(promoted(typeof(var)) == typeof(double))
        printf("%g", var);
    else if(typeof(var) == typeof(struct))
    {
        foreach(void m in membersof(arg))
        {
            trace_var(indent+2, m);
        }
    }
}


 I personally have wished for *more* macro processing power.

 Not for typedefs.  Not for constant definitions.  Not for #include files




or

 guards.  For *macros*.


 Have you looked into m4?


Actually, I've done a bit of work using m4.  I think it's really powerful
:-) and really difficult to use.  :-(  The quoting rules always confuse me.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 17 2001
prev sibling next sibling parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:9lgk0b$243j$1 digitaldaemon.com...

 By "macros" I mean something that lets a programmer add power to the
 language translator.  Something with access to the type system of the
 compiler.  So I could write a generic macro that iterates through the
 members of any given structure and generate code to print them in context.
 So that I can write a package of macros that simplify binding SQL
 parameters, because it can detect data types.  So that I can write


generics

 and templates using macros.


I agree, there's something good about having the power to override certain
restrictions put in place in the language. Yes it's like a dangerous knife,
but sometimes a sharp knife is needed, as well. So I do miss the option of
having some macro-processing, LISP has this power, and it's been used for
very interesting solutions. This is more concerning the power to re-define
statements and meta data, and not about the classical use of macros, i.e.
smart inlining in order to try to produce tight code... --Kent
Aug 16 2001
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Kent Sandvik" <sandvik excitehome.net> wrote in message
news:9lhobc$at8$1 digitaldaemon.com...

 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:9lgk0b$243j$1 digitaldaemon.com...

 By "macros" I mean something that lets a programmer add power to the
 language translator.  Something with access to the type system of the
 compiler.  So I could write a generic macro that iterates through the
 members of any given structure and generate code to print them in




context.

 So that I can write a package of macros that simplify binding SQL
 parameters, because it can detect data types.  So that I can write


 generics

 and templates using macros.


 I agree, there's something good about having the power to override certain
 restrictions put in place in the language. Yes it's like a dangerous


knife,

 but sometimes a sharp knife is needed, as well. So I do miss the option of
 having some macro-processing, LISP has this power, and it's been used for
 very interesting solutions. This is more concerning the power to re-define
 statements and meta data, and not about the classical use of macros, i.e.
 smart inlining in order to try to produce tight code... --Kent


Well, frankly, LISP is not the language for me.  :-/  The greatest exposure
I've had to LISP is some programming in Emacs-LISP.

But what I do appreciate is that LISP's macros are very powerful, and that
they look like LISP.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 17 2001
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Richard Krehbiel wrote:

 ...I've had to LISP is some programming in Emacs-LISP.
 
 But what I do appreciate is that LISP's macros are very powerful, and that
 they look like LISP.
 
 --
 Richard Krehbiel, Arlington, VA, USA
 rich kastle.com (work) or krehbiel3 home.com (personal)
 


"...and they look like LISP." is a tricky one.  They sure do look the 
same.  But they don't act the same.  Their rules for parameter passing, 
e.g., are different.  And their run-time behavior is different.

Now of course, if it weren't different, there wouldn't be any reason to 
need it.  But it damages the internal unity of the language at the same 
time that it makes it more powerful.

If you're going to have macros as a distinct part of the language, then 
you need to enable them to be recognized at a glance, without being so 
obtrusive that it's hard to see anything else.  Syntax markers can be a 
good choice, but references as well as definitions need to be easily 
recognizable (and I find all upper case names QUITE UGLY), also, the 
marker needs to be linguistic rather than conventional.  Perhaps having 
macro names start with . followed by a letter (or an underscore?).  The 
hash mark for definitions is good.

But it would be better to design a language that didn't need macros.
Aug 17 2001
parent "Richard Krehbiel" <rich kastle.com> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:3B7D31A6.6020008 earthlink.net...

 But it would be better to design a language that didn't need macros.


IMHO that language is necessarily an interpreted one, because I ask
specifically for full access to the type system.

Java comes pretty close; you can query class definitions, but the primitive
types are troublesome.  You can make "generic" collections of Object, but
the primitive types aren't objects.  And you can't do type checking at
compile time either.

Java executables (.class files) carry their symbol tables, so that in the
unlikely event that they're needed, they can be queried.  A purely
compiled-to-native-code language shouldn't have that property.  So if the
programmer's going to write code to inspect the type system, it'll need to
execute during the compile phase - and that's what I call a macro language.
Aug 17 2001
prev sibling next sibling parent reply "Tim Sweeney" <tim epicgames.com> writes:
 Okay, why is it that everybody thinks the C preprocessor is terrible and
 needs to be avoided?


Because it's terrible and needs to be avoided, of course!



 don't have one.  I just don't get this one.


Historically (beginning with C), macro preprocessors have served as a kludge
to compensate for a lack of language power and optimizer ability.  Macros
were good an necessary in the C days, because you could often come pretty
close to C++ style template programming if you were clever enough, using
macros for casts and other tricks.  You could also use them to construct
optimized code (i.e. by defining the body of a loop in a macro, and
unrolling the loop 100 times with the macro).

With a modern language, these kludges should not be necessary.  If there is
any particular case where you feel you could express a program more cleanly
by using macros, then I recommend looking at that as a language or optimizer
flaw to be fixed, and not a need for macros.

Unreal (the game) is probably a good production-code example.  It's around
250,000 lines of code and uses macros for the following:

1. To expose metaclass information (i.e. class names, default constructors
that a serializer can call) -- like MFC's techniques.  All of this code
would be unnecessary if the language supported classes as first-class
objects (i.e. you can pass around a classref* which "represent" the class
and exposes its static functions), static virtual functions, and static
constructors.

2. To comment out large blocks of code.  Would be unnecessary if /*...*/
comments could be nested.

3. To implement debug-specific code.  This is actually unnecessary, a bad
old habbit.  We would be just as well off having a global constant debug=0
or 1, and having if(debug) {...} instead of #if debug.

4. To implement platform-specific headers.  Only necessary because headers
are necessary.

5. To perform template-style tricks.  If the language has a great facility
for type dependency (whether like C++ templates, or more general like
Haskell), all of these things would be unnecessary.  Even C++ templates
aren't complete enough, i.e. there are no template typedefs (true type
synonyms), and most production compilers have bizarre template bugs limiting
what you can do.

I'm 100% sure the Unreal code would be simpler and cleaner if the language
supported the above and all preprocessor support were eliminated.

-Tim
Aug 17 2001
next sibling parent "Brent Schartung" <bschartung home.com> writes:
All this talk reminds me (no offense to the Unreal developers!) of the Win32
API.  Basically, you have some struct xyz, and XYZ is a pointer to an xyz
struct.  Sometimes.  Or maybe it's just a UINT32.  Or a PASCAL FAR.  Who
knows?

I don't know about you guys, but I've certainly wasted a lot of time digging
through MSVC documentation trying to figure out what in the world the API's
macros map to!  Win32 in and of itself stands out--in my mind at least--as a
terrible misuse of the preprocessor, and makes me really want a language
that completely lacks macros and makes abuses like these at least
inconvenient, compared to the Right Way. <wink>

You guys who want to lecture us about how _good_ the Win32 API is, or how
great it was for its time or whatever, flame away, I guess I've baited the
hook...

 - Brent
Aug 17 2001
prev sibling next sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Here is one more use: Hide the complexities which you can't change..

int main(ARGS){
    if( ! ARG_PRESENT(1) )fatal("Usage: crlfd infile [outfile]");
    SepFileName in_name = ARG(1), out_name;
    if(!ARG_PRESENT(2) ){
        out_name = in_name;
        in_name.prepareBackup();    // Delete old .bak, rename this to .bak
        in_name.ChangeExt("bak");
        }
    else out_name = ARG(2);

I guess similarly the preprocessor can be used to build an efficient
'facade' for a readymade library. (Deriving a class just to redefine a few
inline functions is too much work, plus this might require casting to base
class...)

Again, consider the following use to hide ugly initilisers: (I have even
forgotton the underlaying structures:)

#define CFNAME "cards.dat"
#define LOGFILE "c:\\cust.log"
#define PRODUCT "Unknown Product"

#define DTLANG  "dtlang.h"
#define DTCUST  "dtcust.c"

char *CustLog;
char *custdbase, *makecmd, *makeparam1, *makeparam2, *makeparam3=0;
char *orgname, *newname, *product, *hdrout, *dataout;

INITABLE it[] = {
    INISTR( "Files",    "log",      CustLog,    LOGFILE , 0),
    INISTR( 0,          "custdbase",custdbase,  CUSTDBASE , 0),
    INISTR( 0,          "orgname",  orgname,    0 , 0),
    INISTR( 0,          "newname",  newname,    0 , 0),
    INISTR( 0,          "makecmd",  makecmd,    MAKECMD , 0),
    INISTR( 0,          "make1",    makeparam1, MAKEPARAM1 , 0),
    INISTR( 0,          "make2",    makeparam2, MAKEPARAM2 , 0),
    INISTR( 0,          "product",  product,    PRODUCT, 0),
    INISTR( 0,          "header",   hdrout,     DTLANG, 0),
    INISTR( 0,          "datafile", dataout,    DTCUST, 0),
    INIEND(),
    };

int main(ARGS){
    if( ! processini( CFNAME, it)){
        printf("Ini processing failed..");
        return 0;
        }
    ....


Tim Sweeney <tim epicgames.com> wrote in message
news:9lkf0r$2nh0$1 digitaldaemon.com...

 Okay, why is it that everybody thinks the C preprocessor is terrible and
 needs to be avoided?


 Because it's terrible and needs to be avoided, of course!



 don't have one.  I just don't get this one.


 Historically (beginning with C), macro preprocessors have served as a


kludge

 to compensate for a lack of language power and optimizer ability.  Macros
 were good an necessary in the C days, because you could often come pretty
 close to C++ style template programming if you were clever enough, using
 macros for casts and other tricks.  You could also use them to construct
 optimized code (i.e. by defining the body of a loop in a macro, and
 unrolling the loop 100 times with the macro).

 With a modern language, these kludges should not be necessary.  If there


is

 any particular case where you feel you could express a program more


cleanly

 by using macros, then I recommend looking at that as a language or


optimizer

 flaw to be fixed, and not a need for macros.

 Unreal (the game) is probably a good production-code example.  It's around
 250,000 lines of code and uses macros for the following:

 1. To expose metaclass information (i.e. class names, default constructors
 that a serializer can call) -- like MFC's techniques.  All of this code
 would be unnecessary if the language supported classes as first-class
 objects (i.e. you can pass around a classref* which "represent" the class
 and exposes its static functions), static virtual functions, and static
 constructors.

 2. To comment out large blocks of code.  Would be unnecessary if /*...*/
 comments could be nested.

 3. To implement debug-specific code.  This is actually unnecessary, a bad
 old habbit.  We would be just as well off having a global constant debug=0
 or 1, and having if(debug) {...} instead of #if debug.

 4. To implement platform-specific headers.  Only necessary because headers
 are necessary.

 5. To perform template-style tricks.  If the language has a great facility
 for type dependency (whether like C++ templates, or more general like
 Haskell), all of these things would be unnecessary.  Even C++ templates
 aren't complete enough, i.e. there are no template typedefs (true type
 synonyms), and most production compilers have bizarre template bugs


limiting

 what you can do.

 I'm 100% sure the Unreal code would be simpler and cleaner if the language
 supported the above and all preprocessor support were eliminated.

 -Tim
Aug 20 2001
parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <9lqfvs$8pm$1 digitaldaemon.com>, Rajiv Bhagwat wrote:

 Here is one more use: Hide the complexities which you can't change..
 
 int main(ARGS){
     if( ! ARG_PRESENT(1) )fatal("Usage: crlfd infile [outfile]");
     SepFileName in_name = ARG(1), out_name;
     if(!ARG_PRESENT(2) ){
         out_name = in_name;
         in_name.prepareBackup();    // Delete old .bak, rename this to .bak
         in_name.ChangeExt("bak");
         }
     else out_name = ARG(2);


This is ugly.  *PLEASE* don't teach this to anybody.  This *hides*
necessary things, things which should be seen and understood.


As an aside.  I've worked at a certain company (who shall remain
nameless), where macros were used in C, to provide certain OO things.
Among them were macros for almost anything imaginable.  The record
number of characters per line (after macro expansion) was in excess
of 4K worth of characters.  Needless to say, these expressions were
neither free of side-effects, nor particularly fast (the original
intention), nor bug-free.  I've had compilers silently truncate such
long lines.  And by pure luck, have them compile, and the program
largely work (1 failure case in 10000's of test cases).


That being said, macros can be good, and they can be evil.  The above
is the beginning of evil.  If you need macros to hide that sort of
inline complexity, write a new function to abstract the behaviour.
Give it a reasonable name, and use it.  In that way someone coming
along in 5 years will be able to understand what you did, and will
not have to worry about side-effects, etc.

--Toby.
Aug 20 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Tobias Weingartner wrote:

 
 In article <9lqfvs$8pm$1 digitaldaemon.com>, Rajiv Bhagwat wrote:

 Here is one more use: Hide the complexities which you can't change..

 int main(ARGS){
     if( ! ARG_PRESENT(1) )fatal("Usage: crlfd infile [outfile]");
     SepFileName in_name = ARG(1), out_name;
     if(!ARG_PRESENT(2) ){
         out_name = in_name;
         in_name.prepareBackup();    // Delete old .bak, rename this to .bak
         in_name.ChangeExt("bak");
         }
     else out_name = ARG(2);


 
 This is ugly.  *PLEASE* don't teach this to anybody.  This *hides*
 necessary things, things which should be seen and understood.


Funny, I was just about to make a case for command-line parameter 
access to be built into the language, to hide even the need for 
these macros. 

I don't see the above example as being any uglier than the 
traditional argc/argv mess. 

-Russell B
Aug 20 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B814102.B41B493E estarcion.com>...

I don't see the above example as being any uglier than the
traditional argc/argv mess.



The D way of doing command lines:

    import stdio;

    int main(char[][] args)
    {
        for (int i = 0; i < args.length; i++)
        {
            printf("Argument %d = '%.*s'\n", i, args[i]);
        }
    }

The .*s is a hack to get C printf to print D strings that don't have a
terminating 0. The char[][] is an array of strings.
Aug 21 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:

 
 Russell Bornschlegel wrote in message <3B814102.B41B493E estarcion.com>...

I don't see the above example as being any uglier than the
traditional argc/argv mess.


 
 The D way of doing command lines:
 
     import stdio;
 
     int main(char[][] args)
     {
         for (int i = 0; i < args.length; i++)
         {
             printf("Argument %d = '%.*s'\n", i, args[i]);
         }
     }
 
 The .*s is a hack to get C printf to print D strings that don't have a
 terminating 0. The char[][] is an array of strings.


Hm, I don't know what you have in mind for the internal representation
of a string, but I'd recommend allocating one more character than the
length of the string and keeping it zero-terminated, even if you're 
tracking the length separately -- it could save a lot of trouble in 
compatibility. Is it out of the question to support an automatic 
conversion from D strings to zero-terminated (w)char* in parameter 
lists of functions declared with C calling conventions? 

-RB
Aug 21 2001
parent "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B828FB7.9821FE49 estarcion.com>...

Walter wrote:

 Russell Bornschlegel wrote in message




<3B814102.B41B493E estarcion.com>...

I don't see the above example as being any uglier than the
traditional argc/argv mess.


 The D way of doing command lines:

     import stdio;

     int main(char[][] args)
     {
         for (int i = 0; i < args.length; i++)
         {
             printf("Argument %d = '%.*s'\n", i, args[i]);
         }
     }

 The .*s is a hack to get C printf to print D strings that don't have a
 terminating 0. The char[][] is an array of strings.


Hm, I don't know what you have in mind for the internal representation
of a string, but I'd recommend allocating one more character than the
length of the string and keeping it zero-terminated, even if you're
tracking the length separately -- it could save a lot of trouble in
compatibility. Is it out of the question to support an automatic
conversion from D strings to zero-terminated (w)char* in parameter
lists of functions declared with C calling conventions?



Arrays are implemented as:

    int length;
    void *data;

There is a (char*) cast supported. I toyed with the idea of always making
them 0 terminated anyway, but it would up requiring lots of array copying.
Aug 21 2001
prev sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Russell Bornschlegel <kaleja estarcion.com> wrote in message
news:3B814102.B41B493E estarcion.com...

 Tobias Weingartner wrote:

 In article <9lqfvs$8pm$1 digitaldaemon.com>, Rajiv Bhagwat wrote:

 Here is one more use: Hide the complexities which you can't change..

 int main(ARGS){
     if( ! ARG_PRESENT(1) )fatal("Usage: crlfd infile [outfile]");
     SepFileName in_name = ARG(1), out_name;
     if(!ARG_PRESENT(2) ){
         out_name = in_name;
         in_name.prepareBackup();    // Delete old .bak, rename this to






.bak

         in_name.ChangeExt("bak");
         }
     else out_name = ARG(2);


 This is ugly.  *PLEASE* don't teach this to anybody.  This *hides*
 necessary things, things which should be seen and understood.




It certainly simplifies the use. The capitalisation clearly marks the use of
macros. I have used getarg(), even classes to parse the command lines and
ultimately found that for simple cases, the use of these macros is best.
(BTW, I don't recollect from where I have picked them).

What is wrong about hiding the complexities? The whole of OO paradigm is
based on it. It is not necessary to fret about every implementation detail -
I just need to know if the user has supplied the 2nd argument or not. Using
a class or a function for a simple filter would be overkill.


 Funny, I was just about to make a case for command-line parameter
 access to be built into the language, to hide even the need for
 these macros.

 I don't see the above example as being any uglier than the
 traditional argc/argv mess.

 -Russell B


Also, no one has commented about the use of macros to init data structures
as presented in the second part. Maybe the use is not common enough. Oh, I
think MFC does something similar all the time to declare the message map
data structures.
-- Rajiv
Aug 21 2001
parent "Walter" <walter digitalmars.com> writes:
Rajiv Bhagwat wrote in message <9lte82$2297$1 digitaldaemon.com>...

Also, no one has commented about the use of macros to init data structures
as presented in the second part. Maybe the use is not common enough. Oh, I
think MFC does something similar all the time to declare the message map
data structures.



I use macros to initialize data structures in C all the time. That's why D
has specifiable defaults for member initializers, and named initializers for
structs.
Aug 21 2001
prev sibling next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
(Interesting to see you in here, Tim!)

"Tim Sweeney" <tim epicgames.com> wrote in message
news:9lkf0r$2nh0$1 digitaldaemon.com...

 Okay, why is it that everybody thinks the C preprocessor is terrible and
 needs to be avoided?


 Because it's terrible and needs to be avoided, of course!


:-)



 don't have one.  I just don't get this one.


 Historically (beginning with C), macro preprocessors have served as a


kludge

 to compensate for a lack of language power and optimizer ability.  Macros
 were good an necessary in the C days, because you could often come pretty
 close to C++ style template programming if you were clever enough, using
 macros for casts and other tricks.  You could also use them to construct
 optimized code (i.e. by defining the body of a loop in a macro, and
 unrolling the loop 100 times with the macro).

 With a modern language, these kludges should not be necessary.  If there


is

 any particular case where you feel you could express a program more


cleanly

 by using macros, then I recommend looking at that as a language or


optimizer

 flaw to be fixed, and not a need for macros.


Here's one: compile time macros as a substitute for carrying a
freight-train-load of object type information into the executable.


everything is an object carrying it's type information around at run time.
It doesn't need format specifiers.

If this trend continues, I see C remaining as dominant an implementation
language as it is today, because it's the only popular language that
concentrates on run-tim efficiency.


 Unreal (the game) is probably a good production-code example.  It's around
 250,000 lines of code and uses macros for the following:

 1. To expose metaclass information (i.e. class names, default constructors
 that a serializer can call) -- like MFC's techniques.  All of this code
 would be unnecessary if the language supported classes as first-class
 objects (i.e. you can pass around a classref* which "represent" the class
 and exposes its static functions), static virtual functions, and static
 constructors.


Java.


 2. To comment out large blocks of code.  Would be unnecessary if /*...*/
 comments could be nested.


..or if your editor had a function that would insert or remove // comment
markers over a selected range of text (emacs can do this).  Still more ways
to alleviate language issues...


 3. To implement debug-specific code.  This is actually unnecessary, a bad
 old habbit.  We would be just as well off having a global constant debug=0
 or 1, and having if(debug) {...} instead of #if debug.


What about:

class NastyClass
{
#if DEBUG
    int tracehistory[512];
#endif


 4. To implement platform-specific headers.  Only necessary because headers
 are necessary.


Yeah, well, I agree some things shouldn't be preprocessor jobs; #include'd
common definitions, #define'd types and constants are among them.


 5. To perform template-style tricks.  If the language has a great facility
 for type dependency (whether like C++ templates, or more general like
 Haskell),


I'll have to go read up on Haskell.


 all of these things would be unnecessary.  Even C++ templates
 aren't complete enough, i.e. there are no template typedefs (true type
 synonyms), and most production compilers have bizarre template bugs


limiting

 what you can do.

 I'm 100% sure the Unreal code would be simpler and cleaner if the language
 supported the above and all preprocessor support were eliminated.


My main issue is that the macro language should give compile-time power to
the programmer, with access to the type system and symbol tables.  So code
can be generated depending on variable types, on aggregate membership, etc.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 20 2001
parent Russell Bornschlegel <kaleja estarcion.com> writes:
Richard Krehbiel wrote:

 What about:
 
 class NastyClass
 {
 #if DEBUG
     int tracehistory[512];
 #endif


FWIW, already addressed in the existing D spec:

  class NastyClass
  {
      debug
      {
         int tracehistory[512];
      }
      ...


-Russell B
Aug 20 2001
prev sibling next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Tim Sweeney wrote:

...
 
 2. To comment out large blocks of code.  Would be unnecessary if /*...*/
 comments could be nested.
 
...
 
 -Tim
 


Nested comments are very dangerous, unless the comments are labelled. 
Then it might be a good idea.  Otherwise the tag deletions could become 
quite confusing if any mistakes were made.

consider the possibility of:
/*!*  ... /*&*   ... *&*/ ... *!*/

etc. however.  Practically any character should be useable in the "flag" 
position.  And one letter is probably sufficient, though if it weren't 
excessive I suppose one could extend it to be any run of non-whitespace 
not including an asterisk.  That would let one say, e.g.:

/*NoFileFound* ... /*FileOpenFailed* ... /*IOError* ... *IOError*/ ... 
*FileOpenFailed*/ ... *NoFileFound*/

But use of this would require specialized tools.

IDEA!!
Since the program text can already contain embedded html (XML ??) code 
anyway, what about using html/XML comment tags to comment out code?

Or, if XML is used, and it is desired that commented out code be 
visible, then one could specify a labelled XML tag for the comment 
boundaries.  It's a bit more complex than the simple scheme of above, 
but it would allow more or less standard tools to do the processing.
Aug 20 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Charles Hixson wrote:

 
 Tim Sweeney wrote:

...

 2. To comment out large blocks of code.  Would be unnecessary if /*...*/
 comments could be nested.

...

 -Tim


 Nested comments are very dangerous, unless the comments are labelled.
 Then it might be a good idea.  Otherwise the tag deletions could become
 quite confusing if any mistakes were made.
 
 consider the possibility of:
 /*!*  ... /*&*   ... *&*/ ... *!*/


Eeek!

I'm gonna say it one more time: the One True Way to comment out large 
blocks of code is with // at the beginning of the line. You can even 
tag and nest these:

//none of this works//   codecode();
//none of this works//   morecodecode();
//none of this works////this doesn't work yet//   stillmorecodecode();
//none of this works////this doesn't work yet//   blah();
//none of this works////this doesn't work yet////was://  
otherkindofblah();
//none of this works////this doesn't work yet//   finish();

In practice, I use shorter tags than this; typically things like:

//ref//    code or declarations from some other part of the program, 
//ref//    kept around for quick reference

//obs//    obsolete code kept for reference or rollback

//RAB//    my initials; "I have a truly marvelous reason for commenting  
//RAB//    this out, which this margin is too narrow to contain."

//no//     any other random comment-out reason

//         very temporary comment-outs

A good configurable editor should let you make this sort of comment-
out easy to do; a syntax-highlighting editor will make it clear that
this is all commented out, which most don't do with an #if 0 block.

If your editor (or hard copy) isn't syntax-highlighted, this is also 
clearer than commenting out a large block with /* ... */.

-Russell B
Aug 20 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"Russell Bornschlegel" <kaleja estarcion.com> wrote in message
news:3B81647C.25270C5A estarcion.com...

 Eeek!

 I'm gonna say it one more time: the One True Way to comment out large
 blocks of code is with // at the beginning of the line. You can even
 tag and nest these:
...
 If your editor (or hard copy) isn't syntax-highlighted, this is also
 clearer than commenting out a large block with /* ... */.

 -Russell B


If your editor supports syntax highlighting, there isn't a problem with /*
*/ style comments.

Sean
Oct 26 2001
parent Axel Kittenberger <axel dtone.org> writes:
 If your editor supports syntax highlighting, there isn't a problem with /*
 */ style comments.


first /* */ comments are not nestable in normal C, are very bad attribute. 
If you make them nestable it's still not easy to see where a comment really 
ends. 

second I've no idea why the original C authors thought that /* is an 
available token sequence, whats with devided by content of?
a = b/*c;   // that should be a valid operation.

- Axel
-- 
|D) http://www.dtone.org
Oct 28 2001
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
"Tim Sweeney" <tim epicgames.com> wrote in message
news:9lkf0r$2nh0$1 digitaldaemon.com...


 2. To comment out large blocks of code.  Would be unnecessary if /*...*/
 comments could be nested.


Yeah... why on earth did they ever decide that /* */ comments shouldn't
nest?
Since we may end up having to block comment out huge chunks of code since
conditional compilation will require grammatically correct code, if your
code isn't (yet) grammatically correct, you can't even get rid of it.  If it
contains any C block comments, you can't even comment it out properly.  So
I'd have to vote for nesting of C block comments.

Sean
Oct 26 2001
prev sibling next sibling parent Roland <rv ronetech.com> writes:
Richard Krehbiel a écrit :


 I personally have wished for *more* macro processing power.


I agree.

The most powerfull macros i know are MASM assembly langage macro.
I used it two much in my young time but it is very very powerfull.

well i can understand it is not really what walter have in mind creating a
simpler and safer langage..

Congratulations

Roland
Aug 23 2001
prev sibling next sibling parent "Ben Cohen" <bc skygate.co.uk> writes:
In article <9lgk0b$243j$1 digitaldaemon.com>, "Richard Krehbiel"
<rich kastle.com> wrote:


 Okay, why is it that everybody thinks the C preprocessor is terrible and

 D don't have one.  I just don't get this one.
 
 I personally have wished for *more* macro processing power.
 
 Not for typedefs.  Not for constant definitions.  Not for #include files
 or guards.  For *macros*.


Here is an example of a use of macros which I don't think has been
mentioned here or in the spec.  (If it did, I missed it, anyway.)

Suppose you want a macro which uses a variable local to the function in
which you call it.  You can do this in D by simply defining a function and
passing the variable as a parameter (as suggested in the spec).

E.g.:

int X(int i) { return i + i / 3; }

int my_function(int v)  {
    return X(v) * X(v);
}


For some reason you don't want to pass the parameter each time -- perhaps
because you want to use several parameters and the macro will be called
lots of times.  This can be solved by using nested functions.  (I'm not
sure whether D supports these.)

E.g.:

void my_function(int v, int w)  {
    int X() {return v + w/3; }

    return X() * X();
}


Now suppose you have several functions which each want to call the nested
function.  You could redefine the nested function each time, but this
would duplicate effort and might make errors more likely.  Perhaps there
should be a macro construct, similar to that of functions, which can only
be called within a function (and where the variable names used in the
macro must be in scope wherever the macro is used).

E.g.:

int w = 24;

macro int X() {return v + w/3;}

int my_function(int v) {
    return X() * X();
}

int another_function() {
    int v;
    return X();
}

int yuk() {
    return X();    /* This isn't allowed because
                                        there is no v in scope.*/
}

This is a reasonably common use of macros, and one of their powers.  Of
course, it is arguably a Bad Thing because it could be used unwisely, but
it would also be handy.

Do you think this would be useful in the language?  If not, then the
example should probably be added to the spec with an explanation.

What about if the macro has side-effects, e.g.:

macro int X() {v++;  return v + w/3;}
Sep 28 2001
prev sibling parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9lgk0b$243j$1 digitaldaemon.com>, "Richard Krehbiel"
<rich kastle.com> wrote:


 Okay, why is it that everybody thinks the C preprocessor is terrible and

 D don't have one.  I just don't get this one.
 
 I personally have wished for *more* macro processing power.
 
 Not for typedefs.  Not for constant definitions.  Not for #include files
 or guards.  For *macros*.


Another thing:  This is what the spec says about inlining
macros/lightweight functions:

    8. Macros as lightweight inline functions:
        #define X(i)    ((i) = (i) / 3)
               In D:
        int X(int i) { return i = i / 3; }
               The compiler optimizer will inline it; no efficiency is
       lost.

What happens if the macro is in another package or module?

Say X() is defined in module A.  I write module B which includes/imports
module A; a function F() in module B calls X().

If you do this in C, the function X() will be expanded and hence inlined
(from the header file) in the function F().  What happens in D?
Sep 28 2001
parent "Walter" <walter digitalmars.com> writes:
It still gets inlined. The function body gets imported along with its
declaration. -Walter

Ben Cohen wrote in message <9p1eei$1k5t$1 digitaldaemon.com>...

In article <9lgk0b$243j$1 digitaldaemon.com>, "Richard Krehbiel"
<rich kastle.com> wrote:


 Okay, why is it that everybody thinks the C preprocessor is terrible and

 D don't have one.  I just don't get this one.

 I personally have wished for *more* macro processing power.

 Not for typedefs.  Not for constant definitions.  Not for #include files
 or guards.  For *macros*.


Another thing:  This is what the spec says about inlining
macros/lightweight functions:

    8. Macros as lightweight inline functions:
        #define X(i)    ((i) = (i) / 3)
               In D:
        int X(int i) { return i = i / 3; }
               The compiler optimizer will inline it; no efficiency is
       lost.

What happens if the macro is in another package or module?

Say X() is defined in module A.  I write module B which includes/imports
module A; a function F() in module B calls X().

If you do this in C, the function X() will be expanded and hence inlined
(from the header file) in the function F().  What happens in D?
Sep 28 2001