George <greerga@circlemud.org> writes:
> On Mon, 20 Apr 1998, James Turner wrote:
>
> >That's not the answer either. However, there is middle ground, and I
> >feel I've reached it in my code. It simplifies the above and makes it
> >easier to follow what the code does.
>
> What do you have so we may comment on it?
> >It's more clear what the data actually is. The struct makes it harder
> >to follow, makes prototypes and declarations longer, and distracts the
> >reader from what actually is being declared.
>
> As was already said, it can make it harder to read. I like to know that my
> structure is a 'struct' and isn't yelling at me for no reason. Data types
> shouldn't be capitalized without regard.
The exact name of the data type is unimportant. Call it char_data,
and call the structure char_data_s or something. The exact name
doesn't matter, and whether to do this is a matter of opinion.
However, I find it makes the code cleaner and easier to read.
> >I can make ACMD's for things that aren't commands. Just because it is
> >declared that way doesn't mean it IS a command. Call the functions
>
> Just because I declare something to return 'int' doesn't mean it has to.
> (See getc() for an example.)
>
> You're arguing pedantically.
getc() uses the whole integer so that it can return EOF. It has to
use the larger type so that it can get all 256 posibilities for the
next char in the file, while simultaneously being able to return an
error when the end of the file is reached.
I am arguing good design, and proper use of the language. Using
macros like this are ugly and, while it may save a little bit of
typing, isn't anything other than a hack -- and an unnecessary one at
that.
> >do_* or cmd_* or whatnot. As for changing the spells and commands --
> >if your making the change in the structure just for one or two
> >commands, you're probably going about it wrong. If most commands will
> >take advamtage of the changes, then you need to go into each function
> >anyway.
>
> But then you won't need to change those that don't use it.
Can you provide an example of such a change? Has anyone found there
to be any kind of parameter not currently passed that is needed?
There is very little that you would need to pass that isn't inherited
from the parameters that are already passed... unless it was data that
varied per command, then you would need to change the entire command
table as well.
> >No. A prototype generating script, or a sec script, will expand them
> >in-place to proper functions.
>
> Personally I turn on -Wmissing-prototypes and take the compiler warning.
I turn them on as well, but it doesn't write the prototypes for you ;)
> >> I'm assuming you don't like CREATE() either then.
>
> Although it's most likely uglier now.
victim = mud_calloc(1, sizeof(CHAR_DATA));
as opposed to
CREATE(victim, 1, CHAR_DATA);
The second is ugglier IMO. It doesn't behave like a function in two
respects -- the pointer is modified, and CHAR_DATA isn't valid outside
of the sizeof(). This is ugliness that can easily be avoided. As it
stands, the CREATE macro, strictly looking at its usage, doesn't
clearly assign pointers or whatnot. It's ugly.
> >Not that much unnecessary casting -- it can be hidden with wrapper
> >functions and thereby ensure type safety. As for traversing a list
> >given an arbitrary member, how often is that necessary?
>
> You're given a person, find who is in the same room.
If you're given a person, then you can only find the people _after_
them in a room -- not before. You still have to refer to
world[IN_ROOM(ch)].people to get the entire list.
> >The current arrangement is suboptimal (to put it mildly). The weak
> >inheritance would IMO be more efficient, more clear, and make it
> >easier to expand later on. Plus, there are way too many embedded
> >structures anyway.
>
> You're talking C++ again unless C has inheritance now. Embedded structures
> are not evil although I don't argue the current arrangement isn't the best.
C can have a form of weak inheritance, as I mentioned in a previous
email.
struct base {...};
struct inherited {struct base b; ...};
In this case, inherited is weakly inherited from the class base. You
can refer to struct inherited via struct inherited *, or via struct
base *. base could have a magic byte in the beginning if necessary.
This is how C++ handles single inheritance internally. Since b is at
the zero offset of the structure, any pointer to an inherited is also
a pointer to a base.
This could be done in circle as
struct char_data {...}; /* data common to mobs/players */
struct mob_data {struct char_data ch; ...}; /* data only for mobs */
struct player_data {struct char_data ch; ...} /* data only for players */
--
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