Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
If that is the case, then why would we possibly need this
same code in any of the other methods that are used to extend
the original string?
I don't think we do, really. I suspect the main reason why the
code is in all other (out-
Travis Vitek wrote:
Stupid outlook.
[21.3.5.2 p4] Effects: Determines the effective length rlen of the
string to append as the smaller of n and str.size() - pos. The function
then throws length_error if size() >= npos - rlen.
The append that I'm invoking is described to behave as if it had ca
Stupid outlook.
>
>[21.3.5.2 p4] Effects: Determines the effective length rlen of the
>string to append as the smaller of n and str.size() - pos. The function
>then throws length_error if size() >= npos - rlen.
>
>The append that I'm invoking is described to behave as if it had called
>that func
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>> template
>> class Xallocator
>> {
>> public:
>> typedef unsigned char size_type;
>
>I suspect the problem might actually be here. Once you define
>size_type to a type with a more generous range the test case
>passes. I made this and a f
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
If that is the case, then why would we possibly need this
same code in any of the other methods that are used to extend
the original string?
I don't think we do, really. I suspect the main reason why the
code is in all other (out-
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>> If that is the case, then why would we possibly need this
>> same code in any of the other methods that are used to extend
>> the original string?
>
>I don't think we do, really. I suspect the main reason why the
>code is in all other (out-of-li
Travis Vitek wrote:
Martin,
I think that you are right in the case of push_back, or when the string
to append is short. My last testcase didn't prove anything. This one
does. If you use the current trunk, this prints '4 ' to the console.
i.e. appending 20 characters to a buffer with 240 s
Travis Vitek wrote:
[...]
The change also seems unnecessary -- when size() equals capacity()
we check that it doesn't exceed max_size() before allocating more
memory in append(). Otherwise, when size() is less than capacity()
(or rather capacity() - 1), there should be no reason to check
against
Martin,
I think that you are right in the case of push_back, or when the string
to append is short. My last testcase didn't prove anything. This one
does. If you use the current trunk, this prints '4 ' to the console.
i.e. appending 20 characters to a buffer with 240 should not get you 4,
s
Martin Sebor wrote:
>
>Travis Vitek wrote:
>> It appears that recent changes to string have accidentally
>> removed some overflow checking that used to be in the
>> basic_string::append() and push_back() methods. The following
>> patch adds the checks back in.
>
>Does this fix a test failure? O
Travis Vitek wrote:
It appears that recent changes to string have accidentally removed some
overflow checking that used to be in the basic_string::append() and
push_back() methods. The following patch adds the checks back in.
Does this fix a test failure? Or some regression? (If the former,
whi
Travis Vitek wrote:
>
>It appears that recent changes to string have accidentally removed some
>overflow checking that used to be in the basic_string::append() and
>push_back() methods. The following patch adds the checks back in.
>
>Travis
>
Lets try that again. This one has the correct method
12 matches
Mail list logo
