George <greerga@circlemud.org> writes:
> >> You forgot to cast the mud_calloc return value away from 'void *'.
> >
> >There's no need to cast up. Promotion is automatic. It's casting
> >down (losing information) that you need to be explicit.
>
> It's the warning part that was meant. You have to do it or a compiler has
> every right to warn you about it. ANSI C++ forbids implicit conversions
> from a void * also, not that this is C++, but something to keep in mind
> since people do make it C++. bpl13 will compile under C++ and the cast is
> there for a reason.
ANSI C allows promotion up. It is not an error, or a warning, under
'gcc -Wall' and, though I cannot speak for other compilers, I would
not be surprised if they did not warn, either.
As for C++, you are right, it is something to keep in mind. However,
instead of compiling C code in a C++ compiler, modules should be added
at link time, and use of 'extern "C"' should take care of most
problems like this.
C++ is not a spiffy, shiney new C. It is a fundamentally different
language if you follow the precepts and philosophies set down. void
pointers are no where near as necessary in C++ as C (except when
either interfacing to C or ignoring/abusing C++'s benefits). If you
compile C code under C++, you're going to have problems. C++ is not
quite a perfect superset of C. There are differences.
C++ does indeed support 99.9% of C code... but asking it to function
like that isn't the best use of the language.
> >No... you're mistaken. IN_ROOM(ch) returns an offset (as you know),
> >not a pointer. You gave me a character and I returned a list
> >containing those in the same room. Going through the world array
> >doesn't enter into the topic being discussed, ie, accessing a list
> >from an arbitrary member without any a priori knowledge.
>
> In response to:
>
> >> >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 never said it had to be a pointer, integer, or what. But I'm still
> traversing the list given the arbitrary member. Drop the 'prior knowledge'
> BS, that wasn't a requirement until you were wrong.
Look. You said that using the current method of linked lists has an
advantage over using external pointers because, in part, given an
arbitrary member of a list, you can go through the list. But this
ability is not a property of the list code, since it is a single list
-- you can only take tail ends of particular lists.
In your example of finding the others in the room, you do not rely at
all on the nature of the linked lists. If world[n].people returned
the type CharList, then it would still function exactly as you said.
Your argument not only isn't true, but it didn't make sense when you
made it.
> >1. Robustness
> >2. Stability
> >3. Flexibility
> >4. Reliability
> >5. Predictability (both in structure and in operation)
> >
> >Using "weak inheritance" can help achieve all of those.
>
> But you're also increasing complexity all because you want to catch invalid
> pointers. If you remeber to NULL pointers first, or not reuse them, the
> problem will not occur. The Linux kernel uses it when a function can be
> passed many different structures and it needs to determine their type.
> CircleMUD doesn't need that in anything as of yet. (Unless you want to make
> a free() wrapper, but it's quite unncessary.)
The purpose of 'weak interitance' is not to catch invalid pointers.
It is to better structure the global structures, particularly for
characters, mobs, and players. It can help with pointer validity
issues, but that is not its main purpose.
As-is, the current method of having a single char_data structure that
has some entries NULL and some valid depending on if you're dealing
with a player or a mob is messy, ugly, and difficult to maintain
(particularly with the nested structures). Adding this type of
inheritance would allow for better casting when needed, and added
flexibility across the board.
> > Circle can move forward in two ways. One is adding features, the
> >other is cementing the base more firmly. One without the other is a
>
> Check out the 486k CircleMUD bpl13 patch some day.
You're killing bugs, not improving design. If all you want to do is
kill bugs, then go ahead; but you're neglecting a very important
aspect of code maintenance.
George, why are you so rabidly against change? From the beginning,
you've taken an adversarial approach, and made the argument personal.
Whether that was your intent I don't know; however, that is what has
happened.
--
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