On Thursday 05 July 2001 02:11 pm, Dan Sugalski wrote:
> =begin question
>
> Should we scrap the buffer pointer and just tack the buffer on the end
> of the structure? Saves a level of indirection, but means if we need
> to make the buffer bigger we have to adjust anything pointing to it.
>
> =end question
This is probably silly to consider, and it may have been brought up before,
and, of course, I'm bringing it up *after* you've already closed it out, but
leaving it as a buffer pointer could make string->number->string conversions
almost as simple as a pointer copy.
Taken to its extreme, you could run all conversions through bignum (or
bigfloat), if you decided not to rely on platform support for it. This
would give you a single piece of code to handle number detection and
manipulation, which means potential modularization (perhaps a third-party
lib), consistent results across platforms, and, well, just one piece of code
to tweak and maintain. (I think that that could also include bigocts,
bighexs, and bigbins, too.) Taken to its extreme extreme, there wouldn't
even really need to be a big* type - just big* code, a flag, and builtin
logic to treat a regular string as a big*.
With the buffer length specified, you may not even need to normalize an
exponent string to a non-exponential string - you could simply set the
buffer length short. (Of course, this could cause some resize problems, if
the bignum tries to grow a string that is really longer than it thinks it
is, if you follow.)
Taken to its not-so-extreme-case, if you make an assumption (which may be
bad Bad BAD!) that most numeric work would have an implicit exponent of
10^0, then it *is* a simple pointer copy - at least until the big* decides
to normalize it to something else. That would cause the big* and the string
value to get out of sync, but you're going to need to address the conversion
back anyway.....
--
Bryan C. Warnock
[EMAIL PROTECTED]
