On Mon, 1 Dec 1997, Akuma/Chris Baggett/DOOMer wrote:
> i realize coding sockets with C++ classes would probably be a good
> change, but is there any other real major differences/advantages
> that can be made from coding in C++??
> ch.get_name() seems like a bit of a waste to access a private member
> of the char_data class/struct.
We've been converting AR the last week, to C++. It's definitily worth it,
though we are far from finished.
Memory management - before, we used to use macro-generated functions like
free_char, new_char that would call appropriate real_free/real_new
functions that would free/allocate strings and recycle the lists. Now,
this stuff is done via the new/delete operator, so using ch = new
Character will do the right thing. Plus, a class that does not want full
recycling but wants memory for it to come from the internal manager just
inherits a SAM class (SAM = Shared Allocation Mananger):
class Account : public SAM
{
Bitfields - slowly converting all the int-based bitfields to a templated
version. In the template parameter, width is specified. It can be
increased as required. The bitfields are always saved as strings now, so
there's no problem adding new ones. Values are automatically assigned and
a string <> value table automatically built using some macro-magic and
shell scripts. It looks something like:
ch->state.set(STATE_DOWN); // Set that bit
if (ch->state(STATE_DOWN)) // Test that bit
Bitfield<4, state_flags> state; // 4-byte bitfield, strings are in state_flags
fprintf(fp, "%s~\n", ch->state.toString()); // Print the string
ch->state.set(fp.readTempString());
Read string into temporary buffer, let ch->state parse it and set its bits
accordingly. fp is a MappedFile object, an mmap-based file input class.
Generic objects handled via templates. Templated lists and hashtables
eliminate a lot of duplicate code. Iterator allow you not to worry about
saving ch->next_in_room before possibly killing ch.
Stricter type checking, enforced by the name mangling.
Buffers. I use some dynamic crashproof self-expanding buffers which work
much easier with objects - since when I allocate a buffer on the stack in
the beginning of a function, I am sure it will be freed when the function
returns.
Strings. No more worrying about forgetting to free some string field when
you free the structure. A String object's destructor will take care of it.
Readability. d->print("Hello!\n"); looks much nicer than
write_to_buffer(d,"Hello\n");. Plus, in the member functions of a
character/descriptor, you can refer to the variables of that character
without putting ch-> in front of it.
Oh, we don't bother with encapsulating data into getXXX/setXXX functions -
unless there is more to it than just setting/getting the data. So, there's
no ch->getMove() for example.
PS: Remember that in most cases, there is no speed penalty - for example,
the bitfields we have are just as fast as using IS_SET().
=============================================================================
Erwin Andreasen Herlev, Denmark <erwin@pip.dknet.dk> UNIX System Programmer
<URL:http://www.abandoned.org/drylock/> <*> (not speaking for) DDE
=============================================================================
+------------------------------------------------------------+
| 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/08/00 PST