From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114085 invoked by alias); 6 Nov 2015 07:19:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 114067 invoked by uid 89); 6 Nov 2015 07:19:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Nov 2015 07:19:17 +0000 Received: from 81-64-207-100.rev.numericable.fr (HELO laptop-mg.local) ([81.64.207.100]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2015 08:19:14 +0100 Date: Fri, 06 Nov 2015 07:19:00 -0000 From: Marc Glisse Reply-To: libstdc++@gcc.gnu.org To: Jonathan Wakely cc: Daniel Gutson , gcc-patches , Aurelio Remonda , Martin Sebor , libstdc++ Subject: Re: [PATCH] Add configure flag for operator new (std::nothrow) In-Reply-To: Message-ID: References: <1446554133-3090-1-git-send-email-aurelio.remonda@tallertechnologies.com> <56391843.1070807@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-SW-Source: 2015-11/txt/msg00559.txt.bz2 On Fri, 6 Nov 2015, Jonathan Wakely wrote: > On 6 November 2015 at 09:02, Daniel Gutson > wrote: >> >> El 5/11/2015 22:56, "Jonathan Wakely" escribió: >>> >>> It can just call malloc, and the replacement operator delete can call >>> free. >> >> It can but the actual code of operator new is optimized and more complex >> (for example by using intrinsics). The user might not want to deal with the >> STL implementation internals. The code is more complex for reasons that might not apply to your code. If you are replacing new, you don't need to look at a new handler, you can write directly whatever code you want. If you know how malloc(0) behaves on your platform (or are confident that you will never call new with size 0), you can skip the initial test. IIRC I introduced the __builtin_expect in that code, but I personnally often write the following in my code, assuming that allocation will never fail: inline void* operator new(std::size_t n){return malloc(n);} inline void operator delete(void*p)noexcept{free(p);} (same with nothrow and arrays) (technically illegal because of 'inline' but I don't care) > By this argument users should never replace operator new at all. I > don't find that convincing. > > If they don't want to deal with implementation details then they don't > have to. The default implementations are optimized because they are > used by everyone and it would be silly to ship them without making > easy optimisations, but that doesn't mean that users have to do the > same thing in their own replacement allocation functions. Using > __builtin_expect makes a small difference when looping on the result > of malloc, but if you were to provide a replacement that doesn't loop > then the difference for a single branch is not very significant. Actually, it is optimized for the case where it does *not* loop (gcc by default optimizes by assuming that loops do loop). -- Marc Glisse