From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 881 invoked by alias); 28 Jun 2004 15:43:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 805 invoked from network); 28 Jun 2004 15:43:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 28 Jun 2004 15:43:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5SFhve3002784; Mon, 28 Jun 2004 11:43:58 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5SFhu013270; Mon, 28 Jun 2004 11:43:56 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C5DC42B9D; Mon, 28 Jun 2004 11:43:51 -0400 (EDT) Message-ID: <40E03CB7.1060500@gnu.org> Date: Mon, 28 Jun 2004 15:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Bernardo Innocenti Cc: Daniel Jacobowitz , Ian Lance Taylor , GCC Patches , gdb-patches@sources.redhat.com, binutils@sources.redhat.com, DJ Delorie Subject: Re: [top-level] C++-friendly allocators for libiberty References: <40DCC86A.4010306@develer.com> <40DCD0EE.9010208@develer.com> <40DCE1C8.4020202@develer.com> <20040626024617.GA31620@nevyn.them.org> <40DDB0B7.1040902@gnu.org> <40DE5CC0.7070102@develer.com> In-Reply-To: <40DE5CC0.7070102@develer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00641.txt.bz2 > Andrew Cagney wrote: > > >>>>>Bernando, you've now got an interface which allows reallocating to a >>>>>variable size, but not allocating to one... There's no need for a >>>>>rush, let's give people some time to comment before putting this into >>>>>libiberty. As DJ says, it's hard to take things out of libiberty. >> >>> >>> I guess daniel had this in mind: >>> >> >>>>>/* Utility macros to allocate typed memory. Avoids errors like: >>>>> struct foo *foo = xmalloc (sizeof struct bar); and memset (foo, >>>>> sizeof (struct foo), 0). */ >>>>>#define XZALLOC(TYPE) ((TYPE*) memset (xmalloc (sizeof (TYPE)), 0, sizeof (TYPE) >>>>>)) >>>>>#define XMALLOC(TYPE) ((TYPE*) xmalloc (sizeof (TYPE))) >>>>>#define XCALLOC(NMEMB, TYPE) ((TYPE*) xcalloc ((NMEMB), sizeof (TYPE))) > > > Hmmm... What's the advantage of using XZALLOC over XCALLOC? It avoids that extra argument (but yes, XZALLOC should be implemented using XCALLOC). > These macros don't address vector allocations and aren't paired > with corresponding macros to release memory. So far no need. Since its C everyone already knows to call free(). >>They first appeared in GDB in '99 and were added to GDB's global header >>> file in '02 (and I'm sure the idea was stolen from elsewhere). Unlike >>> the macros being proposed, these: >>> >>> - use uppercase to make it very very clear that they are macros > > > This contraddicts the GCC addenda to the GNU coding conventions: macros > meant to be used like C functions should be named like C functions. > See http://gcc.gnu.org/codingconventions.html (Miscellaneous Conventions). Fortunatly that addenda _only_ applies to GCC :-) >>> - are named in a way that directly reflects their C herritage > > > What we're trying to do is getting away from the (dangerous) C > practice of allocating structures by casting around void pointers > to raw memory blocks. Right, and the above achieved that goal, and using a naming convention that is very familar to the C programmer. The bottom line is that there's no "right" answer here. > The libcpp macros for type-safe memory allocation resemble C++-style > memory allocation, hence the new/delete names. > (Actually, C++'s new and delete would also perform construction > and destruction, which we can't possibly do in C). So lets (as in GDB, GCC and BINUTILS) stop beating about the bush and accept C++ (and yes I hate C++). Lets add these to a GCC(?) specific include/ header. That way projects that want those macros can. Andrew