On Mon, 20 Apr 1998, James Turner wrote:
>Definitely, though I don't know how necessary or useful multithreading
>would be... like changing to C++, it isn't something we should do
>midstream unless there is hugely compelling need. But that horrid
>global variable buf needs killing! :)
The example Jeremy gave was to have one thread for each person. That would
eliminate 'lag' from commands which take forever, prevent infinite loops
from affecting everyone, and allow the use of blocking socket I/O.
>Can you clear me up, and perhaps others at the same time? What are
>the design goals of the Circlemud project? Have plans been made for
>what version 4.0 will include, or 3.1?
3.0 won't get anything new except AutoEQ (bpl14) and alias saving (TBA).
The version after 3.0 _may_or_may_not_ have any of the following:
* ASCII pfiles
* rewritten skill system
* new buffer handling
* better (but still very simple) OLC
That's off the top of my head, no promises, warranties, or other
implications to raise your hopes.
>Macros are hideous :) We should replace them with functions. I
>wasn't suggesting we do things like ch->name; we should have
>
>const char *getName(CHAR_DATA *ch);
Uh, why? If you want that, run 's/GET_NAME/getName/g'.
Macros are meant to be indistinguishable from functions.
>There is very little that actually needs doing with a macro.
>Particularly, the data access macros (GET_NAME, OBJ_FLAGS, etc) should be
>functions, not macros. That way we can add proper flow control, as well
>as leaving room for later changes in the data structures.
What kind of flow control would a data access macro need to do besides
limited array bounds checks? (Do not argue about NULL checking.)
CAN_SEE() gets unwieldly but can still be followed.
There are also things macros may do which functions may not. (Like say, a
short_description macro which works for both mobs and objects.)
>As I mentioned in my response to another message, we need to be able
>to explicitly dictate which functions get inline'd. gcc is smart, but
Just because you declare it 'inline,' doesn't mean it will be.
>it can't properly predict the flow graphs of code once it is actually
>executed. Also, it won't inline every function -- that would make a
>HUGE executable. It tried to pick and choose; we should help it.
You cannot inline every function.
>int getAbility(ch, ABIL_STRENGTH);
>int setAbility(ch, ABIL_STRENGTH, 15);
>int getRealAbility(ch, ABIL_INTELLIGENCE);
>const char *getAbilityName(ABIL_PERCEPTION);
>
>Those kinds of things. It makes it easy to add or remove abilities,
>as well as using a uniform interface to fundamental abilities (ie the
>ones stock has now) and derived abilities (say we want an ability
>based partially on strength and endurance).
#define GET_STR(ch) ((GET_DEX(ch) + GET_CON(ch)) / 2)
>It does make the code a small bit wordier. However, it abstracts the
>underlying structures as well as providing range checking and so forth.
Could do that in a macro too.
>
>I use the word guild for what most people call clans, I believe.
>Groups that players can divide themselves into. Allegiances, so to
>speak. Not the guilds that stock has (ie not the 4 basic clases).
Doubt you'll get that into stock code.
--
George Greer - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| 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