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

2009-02-16 Thread Kinkie
>> Definately. With a 32-bit signed size it _should_ be large enough for >> most uses. A debugs when it goes close to or over the signed rollover >> would be critical IMO. Maybe more, but debugs & assert for now. > Do not assert(), just use Must(false) or equivalent. No reason to kill > the proxy i

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

2009-02-16 Thread Alex Rousskov
On 02/13/2009 10:00 PM, Amos Jeffries wrote: > Kinkie wrote: >> On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom >> wrote: >>> tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: It would IMHO make sense to: 1. introduce StringNg::size_type, which should be a _signed_ 32-bit integer

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

2009-02-16 Thread Kinkie
On Sat, Feb 14, 2009 at 6:00 AM, Amos Jeffries wrote: > Kinkie wrote: >> >> On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom >> wrote: >>> >>> tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: It would IMHO make sense to: 1. introduce StringNg::size_type, which should be a _signed

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

2009-02-13 Thread Amos Jeffries
Kinkie wrote: On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom wrote: tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: 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

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

2009-02-13 Thread Alex Rousskov
On 02/13/2009 10:31 AM, Kinkie wrote: >> 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 w

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

2009-02-13 Thread Kinkie
On Fri, Feb 13, 2009 at 5:51 PM, Alex Rousskov 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 an

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

2009-02-13 Thread Alex Rousskov
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,

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

2009-02-13 Thread Kinkie
On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom wrote: > tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: >> 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 >> s

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

2009-02-13 Thread Henrik Nordstrom
tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: > 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 Or use size_t in the API while using a smaler t

Lessons learned from string-fix and consequences on StringNg design

2009-02-12 Thread Kinkie
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