"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
> code on a mud where the exact conversion you'd like had taken place.
> Instead of "GET_NAME(ch)" one had "GetName(ch)". Instead of typing
> "struct char_data" one typed "CharData", etc. You know what this did?
> Very little indeed. I actually had more trouble reading and using that
> code than I did any other sort - and considering I've been used 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.
> > > typechecking when appropriate. GET_NAME(obj) or GET_LEVEL(room) don't
> > > make sense, yet the compiler, instead of spitting out an error about
> > > invalid types, will complain about there not being certain fields in
> > > certain types.
>
> If you can't figure out this error, you probably should't code. If you
> don't know enough about the system you're programing on to try to get the
> level of a room, you probably should examine the code. And if you do all
> of the above, you'll still get an error pointing to the line of the error,
> and it takes seconds to fix. I assume that a person would be just as
> likely to type GET_LEVEL(room) where GET_LEVEL is a function. Sure, you
> get a slightly more descriptive error message, but this isn't the sort of
> thing that would hold you up for more than maybe 10 seconds. IMHO, its a
> waste of time to even argue about this.
I completely agree that some people shouldn't be coding on a mud --
but everyone starts somewhere. There are many benefits to using
functions over macros. Particularly we can use simple drop-in
replacements since the current code already uses a specific interface
(ie it usually doesn't access data directly).
If you feel it is a waste of time to argue, you're welcome to stop.
However, Circle in some places has an amateurish look to the design
and coding, and it is clear that layer upon layer has been added as
time has progressed -- what was once good design is hampered, or
cripled, by the addition of features on top of a few shakey joints.
> This seems nit-picky. Say you have a race on your mud, and you
> can dynamically create races, with min/max values for strength, and this
> has an effect on the effective strenght of a character.. depending on how
> you design it, I'm sure you'd opt to use a table lookup - look how the
> ascii dynamic boards work. Notice though, that in stock code, where
> boards are in an array, this can be easily accessed. Its all a matter of
> how you choose to code something based on what you need to acomplish.
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.
> > > That won't work, because it will get the dex of the next victim,
> > > and the con of the one after that. Contrived example somewhat, but
> > > macros have their limits, George. They are headaches to maintain and
> >
> > It is contrived. Macros aren't the end all be all of existance,
> > they're literally shorthand. Creative use of macros makes code readable.
> > They're just code, just like any other code (cept its preprocessed), and
> > just as hard to mantain and expand as normal code. C'mon. This is starting
> > to look more like an argument over 'The One True Coding Style'.
#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 are confusing style with design.
> I don't think that macros actually would affect (improve or
> worsen) running time. They're pre-proceesed, just like has been said
> before. They're replaced with actual code. Arugments for speed is a moot
> point.
You are incorrect. Macros, since they do not have the overhead of
function calls, can be significantly faster than full functions. That
is why C++ (and some C extensions) supports inlining of functions --
to gain the speed of macros with the flexibility of functions.
> 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.
Macros do not have typechecking, for one. 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. Macros have their uses; but they shouldn't be
used as blindly and frequently as the current code does.
> 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
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.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST