Re: SBuf review at r9370

On 03/04/2009 06:09 AM, Kinkie wrote:
> Who'd be in charge of managing the passed memory block?
> I see two choices:
> - the caller is in charge
> then absorb becomes an alias of assign() and has no reason to exist
> except create confusion
> - absorb frees
> this would make the behaviour more consistent with the eventual
> impementation, and a mismanaged pointer will bomb immediately.
>
> Do you have a path you'd prefer to see?
>
Only "absorb frees" path makes sense, as you pointed out yourself. This
is why the proposed method is called absorb :-).

> Done. Some resizing may still occur, because:
> 1- we're not copying the whole MemBlock, just the portion that interests us
> 2- rounding to memory boundaries due to (eventually) MemPools
>
Sure, but all those are under-the-hood things that cow() should not
worry about.
> estimateCapacity() which right now statically suggests a 20% increase in sizes
>
I expect 50% or 100% increase would work better, but this is pure
speculation on my part and not a big deal. Let's see what others suggest.

> MemPools integration will see memAllocationPolicy be replaced by a
> call to Mem::memAllocateString which will choose the right pool and
> feed the new size back
>
You may want to add the above plan as a source comment.
>> But who supplies the file and line values to the constructor if we just
>> call throw?
>>
> The same way TextException does:
> throw someException(__FILE__,__LINE__)
>
Ah, I see now. Not sure why I missed that before, sorry. BTW, __FILE__
should be replaced with the new DebugBaseName() or whatever we called
that thing, I guess. One more reason to enhance Throw() so that it can
correctly throw custom exceptions.
> Hm.. How about
> - slice
> - shorten
> - chop
> - range
> - cut
>
Let's use chop() or, if you prefer, zoom().

HTH,

Alex.
Received on Wed Mar 04 2009 - 20:45:56 MST