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

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.

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.

> 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?

Thank you,

Alex.
Received on Wed Sep 03 2008 - 22:31:53 MDT