From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24512 invoked by alias); 18 Apr 2012 20:25:26 -0000 Received: (qmail 24477 invoked by uid 22791); 18 Apr 2012 20:25:20 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Apr 2012 20:24:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IKOdWI008373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 16:24:39 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3IKObl0011028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 16:24:38 -0400 From: Tom Tromey To: Pedro Alves Cc: Jan Kratochvil , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> Date: Wed, 18 Apr 2012 20:25:00 -0000 In-Reply-To: <4F833D29.4050102@redhat.com> (Pedro Alves's message of "Mon, 09 Apr 2012 20:48:57 +0100") Message-ID: <8762cwpz3u.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-04/txt/msg00137.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Even Android/Bionic doesn't support C++ exceptions (not sure Pedro> if it doesn't in recent versions or not). I think this is an interesting point, but downthread Paul Smith raised the idea of statically linking libstdc++; and I was wondering whether on really space-constrained systems one might enable SJLJ exceptions to try to save space from the unwind tables, my thinking being that this would reasonably faithfully mimic how the code actually works today. Pedro> It is very much not clear to me that it is worth the pain (that I Pedro> tried to show we will end up with) to bring in C++ for this. Pedro> Symbol/types even are long lived objects, it's not common at all Pedro> to need to worry about leaks (RAII/exceptions) here. And all we Pedro> have are simple hierarchies. As much as I like C++, C does quite Pedro> fine here too. The language it is written in is not the problem Pedro> with our symbol tables. We're going to make symbols more complicated to make lazy CU expansion work, and maybe some other things. The issue isn't whether it is possible, but instead the cost. On the whole I think we spend a lot of time in gdb tending to self-created problems. Open data structures (symbol tables are particularly bad here), inconsistent use of accessors, etc, make some kinds of refactorings harder than they need to be. I realize that switching to C++ is not a panacea for this. Fixing symbol tables is just hard regardless of how we do it, because the original sins are all baked into the code already. But, there are changes that this move would undoubtedly facilitate. For example, I think we need to virtualize struct value storage to deal with VLA and sliced arrays. To me this looks pretty awful from C; but simpler from C++. Pedro> Even RAII is not _that_ different from cleanups. No, it really is. It is not dynamic, and you don't have to remember to call do_cleanups on all exit paths. I've fixed any number of memory (and, IIRC, file descriptor) leaks caused precisely because cleanups are less good than RAII. Basically, with cleanups the default is full generality, but this is wrong. With RAII the default is block scoping, and you have to expend effort to do weird stuff. Pedro> We still need to have a way to tell the RAII wrapper objects to Pedro> stop managing whatever they're managing, for instance. There are plenty of canned solutions. Pedro> We should consider this very very carefully, not just flip just Pedro> because. I don't think that is an accurate characterization of the proposal. I realize the threads get a bit heated though. I agree that we should consider it very carefully. And I think we are. Tom