Re: Lessons learned from string-fix and consequences on StringNg design

On Fri, Feb 13, 2009 at 5:51 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/12/2009 09:19 AM, Kinkie wrote:
>> Hi all,
>> the work on string-fix is nearing completion, and it yielded some
>> interesting insight on an issue also affecting the StringNg design,
>> I'd like to have some input on: storage size and API
>>
>> StringNg uses currently size_t as its storage size, which is probably
>> a bit impractical. A on 64bit platforms, 2^64 bytes-long single-chunk
>> string doesn't really make sense. However, it is necessary for one
>> specific bit of API, which is the useage of std::string::npos as a
>> return value for "not found" in the various find() functions.
>>
>> It would IMHO make sense to:
>> 1. introduce StringNg::size_type, which should be a _signed_ 32-bit integer
>> 2. introduce a static const StringNg::npos = -1 to be used in place of
>> std::string::npos
>>
>> 2Gb-long Strings should suffice for a while, and the String design is
>> probably not very sane for Strings whose max is not known in advance
>> and are bigger than a few Mb anyways.
>>
>> What do you guys think?
> StringNg::size_type should be added. I believe that was one of the
> review items.

It is. I had forgotten.

> StringNg::npos should be added. Sorry if I missed that during the review
> (IIRC, I thought you already had it).

It's not, will add.

> Whether StringNg::size_type is std::string::size_type, size_t,
> std::size_type, or something else is not very important for now, IMO. If
> you feel like saving a few bytes on a 64-bit platform, feel free to do
> that. Naturally, the more non-standard your StringNg::size_type is, the
> more conversions (explicit or implicit) we would have to deal with.

If properly parametrized, changing that is relatively easy (done that
twice with OldString).
psize() and friend macros help a lot there.

> As for overflow checks, I would throw in grow() or equivalent if the
> size gets too big. Adding debugging when the size exceeds some large
> threshold is probably not needed because we can grep for that without an
> explicit debug statement. Or did you want to add a level-1 warning to
> the admin?

The latter. Say that a StringNg can be up to 2Gb big.
I'd rather level-1 warn at .5Gb and throw at 2Gb than just throw at 1
(but then things will have gone bad quite long before that).

-- 
    /kinkie