>> 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
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
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
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
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
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
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,
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
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
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
10 matches
Mail list logo