Re: Circlemud design issues

From: George (greerga@CIRCLEMUD.ORG)
Date: 04/20/98

[ Ok, so I forgot there were replies already en route. ]

On Mon, 20 Apr 1998, James Turner wrote:

>"Patrick J. Dughi" <dughi@IMAXX.NET> writes:
>>         Truth to be told, the current macro set adds readability at the
>>  expense of nothing so noticable as expandibility.  I had the misfortune to
>>  circle/diku and the like for about 5 years now, it came as a blow.  The
>>  macros, in my estimation, are simply short-hand for elements of commonly
>>  accessed structures (baring CAN_SEE.. I should re-write that one to a
>>  function).  Everything else is usually a simple if or value return.
>The name isn't what is important.  Call the functions whatever you
>want.  But having them as macros simply is not the way to go.  It's
>ugly, obfuscates the actual code, and is bad design.

I think we're all going to have to just disagree here.

>If the board system had been designed with simple data access methods,
>akin to C++ class methods, then redoing the underside (how they are
>stored, etc) wouldn't necessitate rewriting of other portions of the
>code.  Abstracting data is a _good_ thing, which inlining (and to a
>lesser extent, macros) allow.

But without going to C++, 'getName(ch) = NULL;' would not work as it does
now.  You'd either have to keep the macro, make a setName(), or use the
full structure.

>#define MAX(a, b) ((a) > (b) ? (a) : (b))
>top = MAX(x++, 4);
>There is an error.  It will not behave as expected.  Macros are NOT
>just like any other code, and if you feel that, then you need to take
>a deeper look.  They can cleverly disguise themselves as normal code
>on the surface, but deep down, they are not.

You have to be smarter than the code.  When things are simple, you make it
a macro. If you outgrow the macro, then you either add a more general macro
or convert it to a function depending on your need.

>>         As for three if/and/or code, wouldn't you be duplicating that in a
>>  function anywway. Whats the big deal if its a function or a macro? Just
>>  make sure to include your backslash, and its the same thing.  And if a
>>  macro is already set up, wouldn't it be harder (20 seconds more) to turn
>>  it into a function than just adding another && IS_A_DEAF_MUTE(ch) to the
>>  end?  C'mon.
>Functions and macros are NOT the same thing by including backslashes.

He wasn't saying they were, just that you would duplicate the check the
macro does inside the function anyway.  So in the effort to avoid multiple
&& and || in a macro, you'd end up with them anyway in the function.

>Macros do not have typechecking, for one.

Which is why you have to be smarter than the code.  As an example, you
should know not to do GET_MOB_VNUM() on a room.

>Another issue is that some macros cannot be placed in some situations.
>For instance, if you want to have multiple expressions in a macro, you
>have to surround it with a do {} while(0) loop.

But you just placed the macro in that situation.

What do you have in mind where you cannot use a macro?  If you mean
variable arguments, that doesn't count since you can just #define the name
of the function without the ().

>Macros have their uses;  but they shouldn't be used as blindly and
>frequently as the current code does.

This is starting to sound like a holy war.

>>         Macros are useful, circle uses them all over because they're
>>  useful, though in most places if there is alot of processing, loops and
>>  the like, of course, we use functions.  In the end there's no difference
>>  thats worth even arguing over. Give it a rest.
>Your view of what a macro is is somewhat incorrect.  They are not just
>like functions -- they are fundamentally different.  There is a large

They can be just like functions in most respects.  They don't have to be,
but they can be.

>amount of documentation of this in the literature and on the net.  I
>would suggest checking into some of this if you are still not clear on
>the distinctions.  You have an intuitive feel for macros; however,
>that is not sufficient.

I'd like to see you do token pasting with functions.

George Greer  -   | Genius may have its limitations, but stupidity | is not thus handicapped. -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST