Re: SBuf review at r9370

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 25 Feb 2009 23:26:19 -0700

On 02/25/2009 07:37 PM, Amos Jeffries wrote:
> Alex Rousskov wrote:
>> * I wonder if SBuf::grow() should be moved to MemBlob that may
>> (eventually) have a low-level knowledge on how to do that efficiently.
>> What do you and others think?
>
> As long as MemBlob::grow() returns a pointer/reference to larger self
> or larger copy that SBuf can change to use.
MemBlob::grow() would enlarge the internal blob memory so it does not
really need to return anything. The caller already has access to the
blob and that is all the caller needs:

    MemBlob b;
    ...
    b.grow(newMinSize);
    b.append(foo, sizeof(foo));

> AND as long as SBuf::grow() is only needed internally. Yet another
> wrapper indirection is the last thing we need for String.
I do not see any problems with calling mem->grow() from SBuf. The
question, IMO, is:

Should MemBlob have a grow/reserve() interface or should MemBlob never
change its buffer size?

In other words, does MemBlob represent a fixed-size buffer or a
potentially resizable buffer?

> max() and min() are themselves provided in the compat layer right next
> to "#define XMAX(a,b) (max(a,b))" and XMIN likewise.
>
> Does anyone know of a reason why we can't simply use min() and max()
> directly?
Could be some kind of backward compatibility with Squid2. Let's use
min() and max() inlined if we have them already.

Thank you,

Alex.
Received on Thu Feb 26 2009 - 06:26:23 MST

This archive was generated by hypermail 2.2.0 : Thu Feb 26 2009 - 12:00:04 MST