From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by sourceware.org (Postfix) with ESMTPS id 9DCB73858D39 for ; Fri, 4 Mar 2022 16:23:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DCB73858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway3.mail.pro1.eigbox.com (Postfix) with ESMTP id 11BF0100480CF for ; Fri, 4 Mar 2022 16:23:13 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id QAi0n0I0dQs3CQAi0n6Jej; Fri, 04 Mar 2022 16:23:13 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=d8AwdTvE c=1 sm=1 tr=0 ts=62223cf1 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=o8Y5sQTvuykA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CTYlbKl8YKKk6nyAd6cA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=y0zyS4sbcvxMP16fnyfWKqT3gvuEvRVPXTK3BF2fto8=; b=Hj3ZtWUsvVkGvna5R5H8gcFWyu 31mIDLa5FzUpBhKXSkSWzX7+DCM1eAVuryNbLbVLIRHXJT5/NORQsyPaV4MgpYIFR/F9396fTZs9u 3+pZ9koFaypgZPr9rKkIU7pBg; Received: from 75-166-141-253.hlrn.qwest.net ([75.166.141.253]:37906 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nQAi0-0023Xy-4X; Fri, 04 Mar 2022 09:23:12 -0700 From: Tom Tromey To: Simon Marchi via Gdb-patches Subject: Re: [PATCH 4/4] gdb: make internalvar use a variant References: <20220201140717.3046952-1-simon.marchi@polymtl.ca> <20220201140717.3046952-5-simon.marchi@polymtl.ca> X-Attribution: Tom Date: Fri, 04 Mar 2022 09:23:11 -0700 In-Reply-To: <20220201140717.3046952-5-simon.marchi@polymtl.ca> (Simon Marchi via Gdb-patches's message of "Tue, 1 Feb 2022 09:07:17 -0500") Message-ID: <87bkylu1ow.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.141.253 X-Source-L: No X-Exim-ID: 1nQAi0-0023Xy-4X X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-141-253.hlrn.qwest.net (murgatroyd) [75.166.141.253]:37906 X-Source-Auth: tom+tromey.com X-Email-Count: 5 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3024.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2022 16:23:15 -0000 Simon> The advantage of a variant here is that we can more easily use non-POD Simon> types in the alternatives. And since it remembers which alternative is Simon> the current one, accesses are checked so that accesses to the wrong Simon> alternative throw an exception (see question about that below). I was wondering if we really need internalvars that can "switch" like this. Like, could we just subclass internalvar instead and get rid of the "kind" / payload stuff. [...] Simon> with some functor + std::visit. FWIW I tend to dislike the visitor pattern anyhow. IME it is just a pain to use well -- lots of callbacks, the code becomes unreadable. Simon> - The library uses std::variant if it is available (so, if building Simon> with C++17). I think there are slight differences between the std Simon> and nonstd versions of variant. I can't really explain what they Simon> are, I am not expert enough in C++. But for example, when I had not Simon> made my visitor's methods const, the code would compile with Simon> std::variant but not nonstd::variant. This means we could get some Simon> occasional build failures if some people build in C++11/14 and others Simon> C++17. One way to avoid this would be to define the macro Simon> variant_CONFIG_SELECT_VARIANT so that we always use nonstd::variant, Simon> regardless of the C++ version. The small downside is that we Simon> wouldn't be testing against std::variant, so some day in the future Simon> we want to make the switch to use std::variant, we'll have some fixes Simon> to do. We already have a problem along these lines with string_view, I think, where we imported one that allows nullptr, then the standard changed(?). On the whole I'd prefer we try to stick to the standard stuff, if possible, because once these divergences come in they seem hard to root out. Simon> With exceptions enabled, bad_variant_access is thrown. Without Simon> exceptions enabled, an assert() fails. In our context, it would be Simon> nice if we could call gdb_assert fails, such that we get the usual Simon> "internal error" message if that ever happens. I don't see an easy Simon> way to do this other than modifying the header file itself. Yeah, not sure what to do about that except write some kind of wrapper. Tom