James Turner wrote:
> The CREATE macro does NOTHING for newbies. It is a nonstandard
> construction. It will only slow their learning of C.
That's ridiculous. It saves newbies the trouble of casting (which you
conveniently forgot about), at the very least. It also does all of the
error-checking necessary and doesn't use any void pointers, which are
not easily understood by newbies, who often have trouble enough with
pointers at all.
> Can you read? I did not say macros in general were hacks -- I said
> "but the way Circle use then is as short-hand hacks that really have
> no place anymore."
I was responding to that statement on the CircleMUD mailing list. It
is quite logical to assume that therefore I meant how are macros hacks
in how CircleMUD uses them. I know you're capable of the fundamental
logic leap, so don't pretend otherwise.
> Circle uses them as a shortcut around and short
> circuit between the two alternatives: direct access to the structures,
> or using true accessor functions. The former is no better than macros
> for handling data, and it unnecessarily ties code to internal data
> representation.
No, CircleMUD uses macros as how they were intended: to encapsulate
and rename commonly-used code you want to inline. The only benefits
you've offered for using function calls is that (a) macros, in this
instance, are a hack: which they aren't, and (b) if you want to add
more functionality, it's probably easier/better to do so in a function.
I won't deny the latter, nor have I. This is, however, a cheap
argument. What you've said is that someone might want to add
functionality that would be easier to do so in functions and then
making the magical leap to: therefore, all macros should be functions.
> #define ABS(x) ((x) > 0 ? (x) : -(x))
>
> int
> next_datapoint()
> {
> static int i = 0;
> return data[i++];
> }
>
> x = ABS(next_datapoint());
Funny, I could have swore that--as you said above--we are talking
about CircleMUD macros. There are, I imagine, less than a dozen out
of all of the macros in Circle that are actually succeptable to this
one side-effect. Which is, BTW, a side-effect of not understanding
how macros work.
> Do you see the problem? Run it through your C preprocessor if you
> don't.
You continue to claim that I am insulting and belittling people, and
yet, you are the only person who has done so in this thread.
> macros. As circle uses them, macros don't suffer from this in most
> cases. However, they can still have rather unpleasant side effects.
We're talking about macros as CircleMUD uses them, though. So, please
point out all of the bad side-effects that can occur with the Circle
macros like GET_HIT.
> Visual C++ I believe offers them; I'm not certain. However, it would
> be quite simple to use them portably. If you can't figure this out on
> your own, I'll be glad to give you a hint.
Yes, Visual C++ supports them, because it's part of the C++ standard
and that's a C++ compiler. Are you actually paying attention to what
you are saying? You want Circle to be in C, you even got mad in a
message and accused me of applying C++ paradigms to C (which I didn't),
and at the same time, you suggest using C++ features in C, and refuse
to acknowledge the fact that they aren't portable. And I'm getting
tired of you constantly implying that I don't know how to code: I am
well aware of how to make the code work on compilers that don't support
the inline keyword. My point is that such a thing isn't and shouldn't
be necessary in stock Circle.
> No. However, if you would read more closely, and participate as an
> adult and not as a whining, insulting child, you would realize that
> the point was that speed isn't really an issue for not using them.
Pardon me? Who has been whining and insulting people? I'm not going
to answer that question, as I believe it is quite obvious to anyone
reading.
> Perfection is a fine goal. Just don't expect to get there. Are you
> saying we shouldn't bother improving circle just because there might
> be lofty goals? Or are you just trying to be belligerant and not add
> anything to the conversation?
I didn't say perfection isn't a fine goal, I said it wasn't realistic.
And there's a good reason: perfection is subjective. I have a very
different idea of what the perfect code base would be than you do. So,
perfection is not realistic, and it's probably more harmful than not to
try to shape Circle to be all things for all people.
> The .c files are not well organized. For instance, some string
> handling functions (one_argument, two_arguments, plus a number of
> others) are in interpreter.c. Completely in the wrong place, but
> someone apparently didn't want to make prototypes and put them in a
> more proper place (maybe a string.c, or utils.c with str_cmp).
They are there because they are used for interpreting/parsing strings
and arguments.
> Can you honestly say that if you wanted to add a string function you
> would do it unequivocably in interpreter.c? No. In fact, it would
> only dilute interpreter.c down even further.
If it were used for interpreting and parsing strings, then it would go
in interpreter.c.
> Or, while most of the affect code is in handler.c, a good bit --
> including affect_update -- is in magic.c.
Which are the primary interfaces for affects in spells and skills. It
really isn't that poorly placed.
> Are you saying you never wanted to find a function yet it wasn't where
> you initially thought it would be?
No, I'm saying that I always found a function in a fairly logical place.
The first place I look isn't always logical, nor is it always the only
logical place to look.
> This is almost a valid point. However, think about it. If a
> structure is named char_data, it should deal with characters, right?
> Not linked lists.
And you have almost made a valid point. However, a char_data pointer
is character data. It is the supporting data for a character being in
a room, or on the MUD.
> A generic linked list implementation would by no means be ugly. In
> fact, if used properly, it would be quite elegant.
And then you have to write support functions for char_list types, or
go into naming conventions and casting in the linked list functions.
You are still complicating rather simple code and gaining no real
benefit.
> I apologize to those on the list for this post's tone, and for taking
> Mr. Koepke's way of handling things. However, I think it is time that
> if he can't be constructive that he shut the hell up, particularly
> seeing how he enjoys being as obnoxious and rude as possible to anyone
> who dares have a different idea than he.
This is the most ridiculous thing I have ever read. It's too late for
April Fool's jokes, however, so you must be serious. However, how you
can claim that I'm being obnoxious or rude because you have a different
view than I is difficult to see, considering I responded to your
message with NO insult, addressing it on a point-by-point basis. You
have done nothing but be obnoxious and rude because I disagreed with
you.
-dak
+------------------------------------------------------------+
| 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