> > You're right, it is a C++ standard, but it is extended to C by many
> > compilers.
>
> Which are those? GNU C. Uhhh...and...? I can't think of any more.
> It's certainly not ANSI C, and part of CircleMUD's reason for
> existence is portability.
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.
> Oh, so because some macros are _almost_ as slow as functions, you should
> make all macros at least as slow as functions. That's logical...
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.
> > You're absolutely right. However, it is not perfect, and there is
> > certainly room for improvement.
>
> Well "perfection" isn't exactly a realistic goal, now is it?
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?
> > Having multiple headers can be good or bad; there are advantages and
> > disadvantages. I prefer a single header file for the headers
> > included in every .c file. Some logical breakdown can be of use, but
> > regardless of that, the organization of circle is somewhat lacking.
>
> How is Circle's organization lacking? Please elaborate.
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). A
properly structured projects makes it easy to say "if I had a function
that did X, where would it be?" 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.
Or, while most of the affect code is in handler.c, a good bit --
including affect_update -- is in magic.c. Such an important part of
circle should probably have its own file; at the very least it
shouldn't be spread across different files, neither of which by name
makes it clear which file the code should be in.
Are you saying you never wanted to find a function yet it wasn't where
you initially thought it would be?
> > For every list you want a given character to be in using stock lists,
> > you need an added member in the char_data struct.
>
> Adding a pointer to a structure is hardly as ugly as having a 100+
> lines of code dealing with void pointers for 'data' and using
> function calls for everything under the sun, as would be necessary
> for any kind of generic C linked list structure. Playing "hide the
> 'next' pointer" in an "abstract" class is hardly going to make the
> code cleaner or more newbie friendly.
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.
void pointers aren't necessary. Note that
struct generic_list {
struct generic_list *next;
void *data;
};
Is the exact same as
struct char_list {
struct char_list *next;
struct char_data *ch;
};
At least, when it comes to how they are laid out in memory. "casting"
between them could be achieved quite easily with either memcpy
(overkill) or a bit of casting -- which could be hidden inside a
function inside the linked list implementation.
A generic linked list implementation would by no means be ugly. In
fact, if used properly, it would be quite elegant.
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.
--
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