From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12822 invoked by alias); 14 Sep 2004 18:50:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12800 invoked from network); 14 Sep 2004 18:50:47 -0000 Received: from unknown (HELO vortex.ices.utexas.edu) (128.83.68.102) by sourceware.org with SMTP; 14 Sep 2004 18:50:47 -0000 Received: from terra.ices.utexas.edu (IDENT:YmtbqaUK2s9DZ8fFz31QHCjwCRHIxA5X@terra.ices.utexas.edu [128.83.68.97]) by vortex.ices.utexas.edu (8.12.8/8.12.9) with ESMTP id i8EIojR0006570; Tue, 14 Sep 2004 13:50:45 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by terra.ices.utexas.edu (8.12.8/8.12.8) id i8EIoiIc022247; Tue, 14 Sep 2004 13:50:44 -0500 From: Wolfgang Bangerth To: gcc@gcc.gnu.org, libstdc++@gcc.gnu.org, bugzilla-masters@dberlin.org Subject: Style of libstdc++ header files Date: Tue, 14 Sep 2004 19:11:00 -0000 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409141350.43359.bangerth@ices.utexas.edu> X-SW-Source: 2004-09/txt/msg00872.txt.bz2 libstdc++ and other compiler library header file writers, the other day I again ploughed for several hours through libstdc++ headers trying to reduce a testcase and it occurred to me again that I had always meant to share some piece of experience: When we try to reduce a testcase, we try to strip away large chunks of code. This is fairly straightforward for code like this: class X { void method1 (); //... void method100 (); }; void X::method1 () {...} //... void X::method100 () {...} The reason is this: we try to remove all the definitions of X::method1...100. If this succeeds, then fine. If not, then we remove 50-100 and see whether the bug is still there, and so on. Note in particular that removing the _definition_ of a function can _never_ introduce a new compile-time error, since the declaration is still there. Thus, if only method63 is necessary to show a particular ICE or compiler error, we're there relatively quickly by bisection of the whole block of function definitions. method63 will then only call a very small number of functions in class X, so that I can also bulk delete the declarations of the other methods. Unfortunately, libstdc++ is, mostly, not written that way: there are a lot of definitions of member functions inlined into the class declaration. Now consider what happens here: class X { void method1 () {} void method2 () { method1(); } void method3 () { method2(); something_else(); } }; Assume that the problem happens because method3 tries to do something in something_else(). method[12] are not involved at all, and I would like to delete their definitions because they use other stuff that I'd like to remove as well. Alas, I can't: I can't just bulk delete the entire block method1--method2, since method3 calls method2 which in turn calls method2. What I need to do is painstakingly edit the contents of the inlined definitions of these functions because I can't just delete the entire block without also removing the necessary declarations. In effect, the work I will have to do is more like linear in the number of functions in a class, rather than the previous logarithmic complexity. This can be all the difference between a quick 15 minute reduction of a 50kloc testcase, or, like yesterday, one that takes the better part of a football game transmission (i.e. 2-3 hours). My request therefore would be if the libstdc++ people could comment if it is possible to gradually move away from their style of using inlined function definitions, and towards a style where function declarations and definitions are always clearly separated. I understand that this is a huge change, but one that could make the life of us bugmasters so much easier! Thanks Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/