Subject: commit: UT_String
From: Mike Nordell (tamlin@algonet.se)
Date: Fri Jun 01 2001 - 19:30:53 CDT
There's no way we're gonna carry around a vftable in UT_String. No way!
Neither should it inherit any other class, especially not one with a vftable
of its own.
I'm sorry, but this I can't let go unnoticed.
This class was designed to be lean. If we need that hashcode() function, it
should be a freestanding function, overloaded on the UT_String type. That
function should not return a size_t (if it was copied from some of my
template->Abi-style converted hash map code I apologize for missing this in
the conversion). It should return an unsigned integral value (like
UT_uint32), and though size_t fits that bill it's not a size that is
returned.
Remember, there is more than one way to skin a cat, err, to express an
interface. It also takes careful consideration before adding vftables to
some classes *especially if they have value semantics*.
If the strings are to be ref-counted, inheriting XAP_AbiObject was precisely
the wrong way to do it. It should be a property of the string class, where
it stores a ref-count in the string buffer.
I have reverted the bloating changes to UT_String and UT_UCS2String.
Commit: util/xp/ut_string_class.*
/Mike - please try to not cc
This archive was generated by hypermail 2b25 : Fri Jun 01 2001 - 19:32:29 CDT