From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27094 invoked by alias); 15 Feb 2007 22:10:32 -0000 Received: (qmail 27079 invoked by uid 22791); 15 Feb 2007 22:10:30 -0000 X-Spam-Check-By: sourceware.org Received: from upstrm185.psg-ucsf.org (HELO biostat.ucsf.edu) (38.99.193.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Feb 2007 22:10:22 +0000 Received: from wsp012651wss.ucsf.edu ([128.218.6.3] helo=iron.psg.net) by biostat.ucsf.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1HHoo0-00001n-Ex; Thu, 15 Feb 2007 14:10:20 -0800 Received: from localhost ([127.0.0.1]) by iron.psg.net with esmtp (Exim 4.63) (envelope-from ) id 1HHonj-0005XZ-PJ; Thu, 15 Feb 2007 14:10:18 -0800 Subject: Re: Associating C++ new with constructor From: Ross Boylan To: Michael Veksler Cc: ross@biostat.ucsf.edu, Ross Boylan , gdb@sourceware.org In-Reply-To: <45D4C2A5.4010807@tx.technion.ac.il> References: <20070215073516.GW5871@wheat.betterworld.us> <45D46192.30504@tx.technion.ac.il> <20070215182625.GX5871@wheat.betterworld.us> <45D4C2A5.4010807@tx.technion.ac.il> Content-Type: text/plain Date: Fri, 16 Feb 2007 05:03:00 -0000 Message-Id: <1171577403.9347.22.camel@iron.psg.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Spam_score: -1.4 X-Spam_score_int: -13 X-Spam_bar: - X-Spam_report: (-1.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 AWL AWL: From: address is in the auto white-list X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00165.txt.bz2 On Thu, 2007-02-15 at 22:29 +0200, Michael Veksler wrote: > Ross Boylan wrote: > ... > > On Thu, Feb 15, 2007 at 03:35:14PM +0200, Michael Veksler wrote: > > > >> The idea is simple, and took me less than a day to implement: > >> Define a template class that can monitor object creation and > >> destruction. > >> Insert a member of this type into all non-POD classes: > >> class MyFoo { > >> .... > >> .... > >> ... > >> Count m_count_for_MyFoo; > >> }; > >> > The difficulty with this, is that it will work reliably only for > non-POD classes. For POD (Plain Old Data) classes or > structs, you are not allowed to automatically modify them, > because they might participate in code such as > struct A { > int a, b; > }; > void Serialize(ostream & out, const A& a) { > out.write(reinterpret_cast(&a), sizeof(a)); > } > > This is well defined only if A is a POD, if you add a Count > instance then the program becomes: > 1. undefined > 2. outputs wrong stuff to the stream. I'm not following. Do you mean that the C++ standard doesn't like the code, or just that streaming out (and back in) an arbitrary object (the counter instance) is unlikely to work, along with any other operations that treat A as a bucket of bits (e.g., memmove)? .... > >> It is imperfect since it can't reliably detect all > >> non-POD classes, and it does not work for std::*** > >> classes. To make it 100% reliable, I had to write > >> a complete C++ parser!. > >> > > > > Why isn't this reliable for all classes in your source code (at least > > if you add a search for "struct")? Are you referring to cases that > > use pre-processor magic, or is there something else? > > > Read my comment above about the importance of non-POD checks. > There is no preprocessor magic, only a trivial perl script that inserts > instances into non-POD classes. The inaccuracy comes from > > 1. It is difficult to find all definitions of all classes. You should > ignore > occurrences of the "class" word in strings and in /* */ comments. > You should find "class" words expanded by some user macros. That's what I meant by my reference to "preprocessor magic" above. > This is virtually impossible to get right without at least running > a preprocessor. > 2. It is difficult to be certain that some class is a non-POD class, > since its POD-ness depends also on its parents and members. > Also, user's macros may hide stuff, like virtual methods. > Templates make it even more difficult. > > I simply made some dumb assumptions in my script that all "class" > definitions are non-POD (or at least never used as POD), and > all "struct" definitions are suspected to be POD. Fortunately, > this assumption is correct most of the time due to common > coding conventions. > > Another approach is in libcwd, which records the class along with the > > memory allocation if you insert a call to AllocTag() after the call to > > new. AllocTag uses templates under the hood to get the type of the > > pointer automatically, and libcwd provides a macro NEW that will take > > care of it automatically, e.g., A *pA = NEW(A()). > > > So you have to write your code this way, or write a preprocessor script > to modify > > A *pA= new A(new B, new C[5])); > > to > > A *pA= NEW(NEW(B), NEW_ARRAY(C, 5)); Yes (I'm not sure above the array syntax either). Actually, nesting the NEWs might blow up, since the macro expands to a couple of statements (I think--I guess it could use a "," operator). > > (I just guess how new over an array are done, I don't really use libcwd). > > This problem was driving me crazy enough that I was looking into > > putting hooks in gcc, which has the advantage of providing a C++ > > parser. That approach has a few disadvantages. Aside from being a > > big project (at least for someone like myself who knows little about > > compilers), it would be impractical to redistribute. > > > I don't think there should be any problem to redistribute such a tool. > I know of at least one such project. If my instructions for building the test suite start with "build a custom compiler with this patch set" that is likely to be off-putting. In fact, it's off-putting for me :) There's a project to make it easier to create addons to gcc (GEM), but since it's not in the main distribution one has to build a custom compiler to use an addon anyway. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062