From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1145 invoked by alias); 28 Jun 2004 18:27:58 -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 1047 invoked from network); 28 Jun 2004 18:27:53 -0000 Received: from unknown (HELO develer.com) (151.38.19.110) by sourceware.org with SMTP; 28 Jun 2004 18:27:53 -0000 Received: (qmail 12613 invoked from network); 28 Jun 2004 18:20:36 -0000 Received: from beetle.trilan (HELO ?10.3.2.254?) (?5p6zOLMiVJJRfdYjSC4yBoqwkYCFkUwi?@10.3.2.254) by trinity.trilan with SMTP; 28 Jun 2004 18:20:36 -0000 Message-ID: <40E06174.9020203@develer.com> Date: Mon, 28 Jun 2004 18:27: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: Andrew Cagney 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> <40E03CB7.1060500@gnu.org> In-Reply-To: <40E03CB7.1060500@gnu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00648.txt.bz2 Andrew Cagney wrote: >>Andrew Cagney wrote: >>Hmmm... What's the advantage of using XZALLOC over XCALLOC? > > It avoids that extra argument (but yes, XZALLOC should be implemented > using XCALLOC). Yes, I've always hated the few C library functions with size/number of elements pair, as if the caller couldn't do multiplications. (fread() and fwrite() come to mind.) >>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(). This violates incapsulation IMHO. A function alloc_foo() should always be paired with free_foo(), even when there's no immediate need for it. The cost of this abstraction is zero. The benefits range from easier debugging to extensibility. >>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 :-) If so, I may rename these macros for libiberty. Expecially for allocation and locking, I tend to like uppercase names because it makes them more visible in the code. Making allocations easier to spot in the code is good because thery're a notorious source of hard to track bugs in large applications. >>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. My preference for XNEW() over XMALLOC() isn't at all strong (I find the first one a little faster to type and read). What I really care about is that we use a corresponding XDELETE() or XFREE() to release that memory. I also think we need XNEWVEC() (or XMALLOCVEC()) and their deallocators. This not only makes it easier to support C++, it's also useful for debugging. I don't care too much about the realloc() interface since it's rarely used, but we can have it for the sake of completeness. > The bottom line is that there's no "right" answer here. Agreed. Then we should pick a solution that doesn't displease too many developers and use that as consistently as possible. >>(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. I'd hope we could all agree on a common set of memory allocation helpers and put them in libiberty for the benefit of all projects. The proposed xnew/xdelete interface is clearly a superset of what GDB has been using. It's already used by libcpp and I've got a patch extending its usage all over GCC. The GDB macros would have to be augmented to be useful for GCC's long term plans, so we can't just move them to libiberty. 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. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/