From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10785 invoked by alias); 1 Jul 2004 07:18:08 -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 10582 invoked from network); 1 Jul 2004 07:18:04 -0000 Received: from unknown (HELO develer.com) (151.38.19.110) by sourceware.org with SMTP; 1 Jul 2004 07:18:04 -0000 Received: (qmail 10678 invoked from network); 1 Jul 2004 07:17:27 -0000 Received: from beetle.trilan (HELO ?10.3.2.254?) (?VWTXl4XRzpV87IgIfkSnndTASMKwdIoO?@10.3.2.254) by trinity.trilan with SMTP; 1 Jul 2004 07:17:27 -0000 Message-ID: <40E3BA87.9070107@develer.com> Date: Thu, 01 Jul 2004 07:18:00 -0000 From: Bernardo Innocenti Organization: Develer S.r.l. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625 MIME-Version: 1.0 To: Bernardo Innocenti CC: Andrew Cagney , 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> <40E03CB7.1060500@gnu.org> <40E06174.9020203@develer.com> In-Reply-To: <40E06174.9020203@develer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00002.txt.bz2 Bernardo Innocenti wrote: > Couldn't we just agree on a few naming issues and use the > same macros everywhere? I'd like to hear from the > binutils people too. I'm leaving for vacation and I'll be (mostly) away from the keyboard for one week. This is the libiberty patch again updated with the latest suggestions. The X*VAR() macros try to provide a full interface to allocat structures of variable lenght. They're not used anywhere at the moment, so I could drop them in case the interface doesn't seem useful enough. Andrew Cagney suggested using a different naming scheme (XMALLOC, XCALLOC...) that has the advantage of being more familiar to C programmers and has been used in GDB for a few years. I still prefer XNEW/XDELETE, but I'm open to changes if someone suggests names for the full set, including the deallocators. include/ 2004-06-26 Bernardo Innocenti * include/libiberty.h (xnew, xcnew, xnewvec, xcnewvec, xobnew): Move here from libcpp/internal.h. (xdelete, xresizevec, xdeletevec, xnewvar, xcnewvar, xresizevar): New macros. diff -u -p -r1.35 libiberty.h --- include/libiberty.h 15 May 2003 19:02:12 -0000 1.35 +++ include/libiberty.h 26 Jun 2004 16:35:34 -0000 @@ -250,6 +250,37 @@ extern PTR xmemdup PARAMS ((const PTR, s extern double physmem_total PARAMS ((void)); extern double physmem_available PARAMS ((void)); + +/* These macros provide a K&R/C89/C++-friendly way of allocating structures + with nice encapsulation. The XDELETE*() macros are technically + superfluous, but provided here for symmetry. Using them consistently + makes it easier to update client code to use different allocators such + as new/delete and new[]/delete[]. */ + +/* Scalar allocators. */ + +#define XNEW(T) ((T *) xmalloc (sizeof (T))) +#define XCNEW(T) ((T *) xcalloc (1, sizeof (T))) +#define XDELETE(P) free ((P)) + +/* Array allocators. */ + +#define XNEWVEC(T, N) ((T *) xmalloc (sizeof (T) * (N))) +#define XCNEWVEC(T, N) ((T *) xcalloc ((N), sizeof (T))) +#define XRESIZEVEC(T, P, N) ((T *) xrealloc ((P), sizeof (T) * (N))) +#define XDELETEVEC(P) free ((P)) + +/* Allocators for variable-sized structures and raw buffers. */ + +#define XNEWVAR(T, S) ((T *) xmalloc ((S))) +#define XCNEWVAR(T, S) ((T *) xcalloc (1, (S))) +#define XRESIZEVAR(T, P, S) ((T *) xrealloc ((P), (S))) + +/* Type-safe obstack allocator. */ + +#define XOBNEW(O, T) ((T *) obstack_alloc ((O), sizeof (T))) + + /* hex character manipulation routines */ #define _hex_array_size 256 -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/