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

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.

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

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.

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?

HTH,

Alex.
Received on Fri Feb 13 2009 - 16:51:50 MST