public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
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	[thread overview]
Message-ID: <200409141350.43359.bangerth@ices.utexas.edu> (raw)


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/

             reply	other threads:[~2004-09-14 18:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-14 19:11 Wolfgang Bangerth [this message]
2004-09-14 19:17 ` Richard Guenther
2004-09-14 19:17   ` Theodore Papadopoulo
2004-09-14 19:22     ` Wolfgang Bangerth
2004-09-14 19:20   ` Wolfgang Bangerth
2004-09-14 19:24     ` Daniel Berlin
2004-09-14 19:44       ` Wolfgang Bangerth
2004-09-17 17:43 ` Benjamin Kosnik
2004-09-17 19:27   ` Mark Mitchell
2004-09-17 19:57     ` Gabriel Dos Reis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200409141350.43359.bangerth@ices.utexas.edu \
    --to=bangerth@ices.utexas.edu \
    --cc=bugzilla-masters@dberlin.org \
    --cc=gcc@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).