From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15584 invoked by alias); 18 Apr 2012 15:28:30 -0000 Received: (qmail 15574 invoked by uid 22791); 18 Apr 2012 15:28:28 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,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 15:27:58 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IFRviV013687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 11:27:57 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3IFRuGZ020243; Wed, 18 Apr 2012 11:27:56 -0400 Message-ID: <4F8EDD7B.2010602@redhat.com> Date: Wed, 18 Apr 2012 15:28:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Kratochvil CC: Tom Tromey , 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> <20120416065456.GA30097@host2.jankratochvil.net> <4F8ECB72.70708@redhat.com> <20120418151553.GA16768@host2.jankratochvil.net> In-Reply-To: <20120418151553.GA16768@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00116.txt.bz2 On 04/18/2012 04:15 PM, Jan Kratochvil wrote: > On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote: >> On 04/16/2012 07:54 AM, Jan Kratochvil wrote: >>> 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++. >> >> I don't even know how to begin to respond to that. :-) The symbols side is perhaps >> the part of a debugger that needs the most care about memory, and where you'll >> most likely to see the need for POD types, and lower level handling of >> memory, like the bcache. > > This is the current wrong approach where > (a) CUs are expanded fully, not just the one or few symbols one started > expanding that CU for. > (b) CUs are expanded needlessly, such as during -expansion, there are > more cases I did not analyze. > > And then with 99% of symbols not needed at all one tries to optimize every bit > out of each symbol to make the 100% total size bearable... You appear to be talking again about high level design choices that really doesn't have much to do with the language they're implemented in. Sure, C++ would make some things easier, but it also makes other objectives harder or impossible. It's a compromise. > Just because > everything is statically accessed and the expansion cannot be easily done > on-demand when one accesses the fields by using getters everywhere. I don't understand what you mean. Certainly adding the C++ getters would be as much work as adding C getters. It's not like C++ writes itself. Again, you don't have to convince me that C++ is nice. I know it is. I like it. I've written C++ for years and practically nothing else. ut I don't like the prospect of a fragmented GDB with important parts in C and others in C++, with all the same issues you don't like in C still in important and wide use. I loathe the idea of someone contributing some new code, and having to say "nice, but please rewrite it in C, because we may need it for X". If we stick to one language everywhere, in the net sum, there's less to learn for new comers. > I can't believe we do not agree on such basic way forward. > As one of the many examples the current main_type is unbelievable, I would not > think it is possible to create something so bizarre, it could be sure fixed by > redesigning it even in C (one big union with all fields specific per type and > not just generic fields each overloaded differently for each type). But then > we would end up with GTK - it has the right design but it is still C++-in-C, > I hope everyone agrees GTK is wrong. ... -- Pedro Alves