Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 66.249.82.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=IQNhIrUTCr7d6oTeRP7RBUwKS7TnDmuDPApDV26kRBz/R02wd7d9eXyFz7qXpDMo7LRviCzypecpdFccU1b98P8pbwrsNQ4G3Sr3x+Ag8ouMvV0naZIbKfsLlqJ+tOAjUglYc/C2TQUaYrzMeEKfJ5d+Mnv4ClsEGXfUNC0l9pA=
Message-ID: <47BF8F6C.7010806@roguewave.com>
Date: Fri, 22 Feb 2008 20:13:48 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r629584 - /stdcxx/trunk/include/string.cc
References: <20080220193716.074291A9832@eris.apache.org>
 <47BF24BE.8070003@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE64383C3E9D@epmsa009.minsk.epam.com>
In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE64383C3E9D@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Farid Zaripov wrote:
> From: Martin Sebor [mailto:sebor@roguewave.com]
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r629584 - /stdcxx/trunk/include/string.cc
> 
> 
> 
>>> Author: faridz
>>> Date: Wed Feb 20 11:37:12 2008
>>> New Revision: 629584
>>>
>>> URL: http://svn.apache.org/viewvc?rev=629584&view=rev
>>> Log:
>>> 2008-02-20 Farid Zaripov <farid_zaripov@epam.com>
>>>
>>>       * include/string.cc (__rw_replace): Removed unused variable __delta.
>>>       (__rw_replace_aux): Removed unused typedef. Used ::operator new() and
>>>       ::operator delete() instead of std::allocator::allocate() and
>>>       std::allocator::deallocate() respectively (since private base class
>>>       std::allocator is not accessible in __rw_replace_aux()).
>> I don't think we're allowed to bypass the allocator and call new
>> directly.
> 
>   Why? Here the operator new() used for allocate the temporary buffer and it's deallocated within this function.

Ah. You're right, that shouldn't matter. Sorry for the noise.

(Although if it's temporary storage, we might want to consider either
allocating it directly on the stack, if the range is reasonably small,
or using the temporary buffer facility, __rw_tmpbuf()).

Martin