Re: pseudo-specs for a String class: tokenization

On Mon, Sep 8, 2008 at 5:11 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Mon, 2008-09-08 at 15:49 +0200, Kinkie wrote:
>
>> But I'd leave the operator =
>>
>> KBuf foo="bar";
>> is quite convenient IMO.
>
> It sure is, and I have no objections at this point.
>
> In many cases, the assignment would look like
>
> String foo = some expression returning char*;
>
> though and the developer will miss cases where a String is converted to
> char* and then converted back to [a new] String. In other words, the
> char* assignment operator helps to miss escapes from the carefully
> designed String and Buffer "garden" even if it only provides a backdoor
> into that garden.
>
> Since statements like the example above should be rarely executed (for
> performance reasons), I think making them inconvenient may be a good
> thing:
>
> String foo = String::Allocate("bar"); // XXX: expensive!
> or
> String foo = String::Create("bar"); // TODO: make a static const

Hi all

The current way to do this is:
char foo[]="blah blah blah";
KBuf bar;
bar.assign(foo);

Is this inconvenient enough?
The previous
KBuf foo="blah" syntax worked via the KBuf(const char *) constructor
which I've currently commented out.

I have posted a doxygen-generated interface specification at
http://www.kinkie.it/pub/dox/, which I'd invite you all to check out.

There's a quite important aspect I'd like to clear: currently most
manipulation functions modify the KBuf itself, i.e.

KBuf foo.assing("foo");
foo.append(" bar");
// foo now contains "foo bar".

An alternative would be to always return fresh KBuf, or in other words:

KBuf foo.assing("foo");
foo=foo.append(" bar");

The choice was made because it's more efficient, but it may be counterintuitive.
There's a third option, which is to have two operators for most
functions, like i've done with the slice()/sliceCopy() operators. The
downside would be to double the interface size..

Thoughts?

-- 
 /kinkie