From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16536 invoked by alias); 16 Apr 2012 06:55:22 -0000 Received: (qmail 16522 invoked by uid 22791); 16 Apr 2012 06:55:19 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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; Mon, 16 Apr 2012 06:55:01 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3G6t1mG022384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Apr 2012 02:55:01 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3G6svFS013115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 16 Apr 2012 02:54:59 -0400 Date: Mon, 16 Apr 2012 06:55:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Tom Tromey , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? Message-ID: <20120416065456.GA30097@host2.jankratochvil.net> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F833D29.4050102@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-04/txt/msg00104.txt.bz2 On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote: > Symbol/types even are long lived objects, it's not common at all to need to > worry about leaks (RAII/exceptions) here. They are and they should not be, this is what archer-jankratochvil-vla with dynamic types is there for and which are not well maintainable without C++. There was Tom's reference counting implementation which I found fragile + complicated so I wrote a custom garbage collector [patch 0/8] Types Garbage Collector (for VLA+Python) http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html but it was sure also a wheel reinvention, with RAII it would be all easier (sure not automagical but some parts of reference counting done automatically). > On 04/09/2012 08:05 PM, Jan Kratochvil wrote: > > Not just that one, std::string vs. cleanups vs. exceptions are even more > > wanted (by me); just static typing (probably) cannot be done without C++, > > the other parts are still being fixed up without C++. > > Sure, there will always be bugs. C++ doesn't magically make all bugs go away. > Even RAII is not _that_ different from cleanups. It is very different, for the very common std::string one does not even have to start thinking about any cleanups. If GDB should stay with C then OK (although FYI I am not so in favor of it). But then it should be real C - therefore without GDB cleanups, without GDB TRY_CATCH etc. etc., proper C code returning error codes from each function and each caller checking it and doing all the local cleanups by hand. I do not know any larger project in C with proper error checking, there are: * Linux kernel lacks proper error reporting, common unclear EPERM from ptrace for 100+ different reasons is a great illustration. At most it uses printk, not too good and even reusable for GDB. * GCC uses an extra garbage collector with terrible markers in C code, that is also not a good example to follow. I do not remember / know how they resolve error reporting / exceptions in GCC. * There sure are more larger projects in plain C, but which ones? Daniel's idea of having two - light (C, separate code) + heavy (C++, GDB sharing code) - gdbservers I had on my mind myself before his post. Thanks, Jan