Marvin Humphrey wrote on 09/01/2009 10:58 AM:
Right now, this data structure bears the whimsical name "ZombieCharBuf", as in
"A CharBuf which cannot be Destroyed." ZombieCharBufs are either created on
the stack or as compile-time static or global variables; they are never
malloc'd. Calling Destroy() on them is illegal and triggers an exception,
hence the name. However, "ZombieCharBuf" is not meant to be a final name;
consider it an intentionally irritating reminder that there are issues with
the CharBuf hierarchy regarding readonly strings and compatibility with
multiple Unicode encodings that remain to be resolved. :)
I'd seen that name in the code just this last weekend (yes, I do read it
when looking for good ideas...) and wondered what that was. Now All Is
Illuminated.
The one thing that bothers me about this scheme is that it forces us to publish
the struct definition of ZombieCharBuf. Ordinarily, class struct definitions
will be opaque -- but the compiler needs to know at least sizeof(ZombieCharBuf)
in order to allocate the proper amount of stack memory.
What alternatives are there to publishing the struct? Isn't that pretty
typical, to make some public .h file available with those kind of defs
in it? Or are you worried that if the struct changes internally, that
existing code might have abused it and will croak or worse on Lucy
upgrade? In that latter case, I think following the Perl course of "what
is documented is what is guaranteed" seems fair. Something like:
ZombieCharBuf *zcb = malloc(sizeof(ZombieCharBuf));
is about all any host language can expect to work.
On the issue of names, why not LucyCharBuf?
--
Peter Karman . http://peknet.com/ . [email protected]
