From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53202 invoked by alias); 25 Nov 2017 21:25:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 53184 invoked by uid 89); 25 Nov 2017 21:25:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=danger X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.198.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 25 Nov 2017 21:25:17 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 8425D401ABCA5 for ; Sat, 25 Nov 2017 15:25:16 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id IhwqeqRVZc72gIhwqekaxd; Sat, 25 Nov 2017 15:25:16 -0600 Received: from 71-218-90-63.hlrn.qwest.net ([71.218.90.63]:35634 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eIhwq-002GwW-6u; Sat, 25 Nov 2017 15:25:16 -0600 From: Tom Tromey To: Pedro Alves Cc: Simon Marchi , Simon Marchi , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA] C++-ify parse_format_string References: <20171123164631.11055-1-tom@tromey.com> <0350cb5f-d176-76c4-11e8-5ffb3fe8c84d@redhat.com> Date: Sat, 25 Nov 2017 21:25:00 -0000 In-Reply-To: (Pedro Alves's message of "Fri, 24 Nov 2017 12:54:33 +0000") Message-ID: <87h8tivyo4.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1eIhwq-002GwW-6u X-Source-Sender: 71-218-90-63.hlrn.qwest.net (bapiya) [71.218.90.63]:35634 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2017-11/txt/msg00659.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I call it a step backwards because simplification is done at the Pedro> cost of efficiency (individual heap allocations, changing the Pedro> ownership model), when the original code avoided that. I agree with this principle in general, but I think that in this particular case, the efficiency and/or allocation argument is not very strong -- I just doubt this code is space- or time-sensitive. So on the whole I think in this case it would be fine to use Simon's patch. Pedro> [1] - I've thought several times because that something like a zstring_view Pedro> (like string_view, but guarantees null-termination) would be handy in Pedro> a lot of places. string_view isn't mutable, though, hence the Pedro> alternative name instead. could be mut_string_view too, for example. In gdb I've often wanted something like "std::string API but unique_xmalloc_ptr allocation policy". That way one could get the handy string methods but allow nicer interfacing to things already using xmalloc (I guess primarily libiberty but also readline and sometimes BFD). The main danger I see of views is that then one must reason about lifetimes in order to use them. But in gdb maybe this can be handled via some relatively simple rules, like "never store a view on the heap". Tom