Re: pseudo-specs for a String class: char *buf

On Thu, Sep 4, 2008 at 12:31 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Thu, 2008-09-04 at 00:12 +0200, Kinkie wrote:
>
>> > I do not think an offset would be significantly less efficient in this
>> > context. I bet 90+% of operations that require raw data access are far
>> > more expensive than adding an offset to a pointer.
>>
>> The most common one is a NULL check, which is hard to express using
>> (offset/length).
>
> As you know, I do not know what you mean by a NULL check (buffers or
> strings are not pointers). If you mean an isEmpty() check, then it is
> implemented as (!length) as the offset is irrelevant for an empty
> string.

There are uses for declaring an object as undefined, which is a
different thing than a zero-length string
Take the tokenizer for example. a null (we may call it invalid,
undefined, no-store) KBuf is a very conveniente way to signal
"end-of-stream", as opposed to "a token of zero length". Without this,
an exception will have to be raised to signal the end-of-stream
condition.

> If you mean the old MemBuf::isNull() check, then it will disappear when
> a proper buffer class is available (i.e., it will not be common at all).
> That check comes from C code and is irrelevant in this context.

Maybe you're right and I was too much C-minded when designing the class innards.

>> Further extra work would be the need of more temporary storage to
>> rebuild the char* out of (memhandle->mem + offset).
>> Extremely small details, but I expect they'll be very common
>> operations (I bumped the size of the stat-counters to 64bits).
>
> Again, I believe that common operations that require raw data access are
> far more expensive than adding an offset to a pointer.
>
>> In the meantime, I ask everyone who can spare 5 minutes to just grab
>> the code off launchapd and see it live ("make" will compile and launch
>> a builtin testsuite/demo, "make dox" will generate the class reference
>> - the code is extensively documented).
>
> I trust you that the code compiles and runs, but so does the current
> ugly code, so I am not sure what is the point of "seeing it live",
> especially if we disagree on basic design principles. Do you expect
> something specific from that "5 minute" exercise?

A feel for the presence (or hopefully absence) of obvious warts.

Thanks.

-- 
 /kinkie