From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by sourceware.org (Postfix) with ESMTPS id 2E33E3858404 for ; Thu, 12 Oct 2023 18:44:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E33E3858404 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-32d80ae19f8so1057271f8f.2 for ; Thu, 12 Oct 2023 11:44:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697136279; x=1697741079; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pmXvTSSyknp2SBEaoh+MajM4zFbsabhgCIkwz/e13f8=; b=BfTgYm8JqQ9wbqYemFy/vLDy1jSOIERxoDypSoDGDvijFa/fFoGzGCv6s6dIDwU4l2 blrQ/srouxodu8g2SRvV/pkpT8dmVoV/pCY/ihxAvmSZvd9kmuGro877kdwbZQWI1dX5 7gtqOf43wPFrH4OSTG3cl8fbg6oiigjAQjmTXJYJuXvMcmlWTLtsS7ysAX0sbXVRZPuD cjQ1kbK0KNewEqd8U+54IC8VdKakIstq6u18M5iE/UkoS5LvvjLj2kHXjAxqcgxpLZ9V 0bajG9H3/xXt5dMVzBpwVOCwYh75Zh+DlapLltGkGULzln5zAmLJYZS4j9uJIFO5t3S/ O/6g== X-Gm-Message-State: AOJu0YwccGEHZBDZn/cSwZZKxU8iEC+D+X58PLVUzDloJsa3f+VhUeFc V2USqA24QwaTSvmmbWLPGy8= X-Google-Smtp-Source: AGHT+IFm41JyphFqEUlNQGuNHh4iJeUwX/FXeBni/tufViEbi1L7nxo7+KIAVB9QpfRbt4EPc1BZKg== X-Received: by 2002:a05:6000:48:b0:31f:f8a5:15db with SMTP id k8-20020a056000004800b0031ff8a515dbmr21705396wrx.48.1697136278913; Thu, 12 Oct 2023 11:44:38 -0700 (PDT) Received: from ?IPV6:2001:8a0:f939:d200:dedd:c263:b7d3:9ba1? ([2001:8a0:f939:d200:dedd:c263:b7d3:9ba1]) by smtp.gmail.com with ESMTPSA id p7-20020a056000018700b003217cbab88bsm55712wrx.16.2023.10.12.11.44.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Oct 2023 11:44:38 -0700 (PDT) Message-ID: <4f1176f7-8816-4ec8-a9bd-db7830097c62@palves.net> Date: Thu, 12 Oct 2023 19:44:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Use std::optional when available Content-Language: en-US To: Tom Tromey , Andrew Burgess Cc: Tom Tromey via Gdb-patches References: <20231005160543.2627733-1-tromey@adacore.com> <87y1gcc6kt.fsf@redhat.com> <874jiywhfs.fsf@tromey.com> From: Pedro Alves In-Reply-To: <874jiywhfs.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-10-10 17:49, Tom Tromey wrote: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> I think this change needs to be held off until we move to C++17 - at > Andrew> which point gdb::optional can just be dropped. > > Once we switch I think we can just remove this code entirely. Agreed, once we can rely on std::optional, we should delete all the tests under gdb/unittest/optional/. They were originally copied from libstdc++'s testsuite, to make sure our gdb::optional behaved the same as std::optional, in the subset of features it did support. See d35d19584cf5. BTW, with C++17, gdb::string_view can be replaced with std::string_view too, and the whole of gdb/unittests/basic_string_view/ can go away too. Pedro Alves > > GDB 14 branched, so I think we're ready for that now. > >>> +#if __cplusplus < 201703L > > Andrew> Ignoring my previous comment for a moment; we now rely on this version > Andrew> number being defined the same in two files. Would it be better to move > Andrew> the '#define GDB_OPTIONAL' into gdb_optional.h? Then we can be certain > Andrew> that it will be defined correctly, and in sync with any future changes > Andrew> made in that file? > > I don't think that would really help. IIUC the issue would be compiling > two source files with different -std settings. But in this case > gdb_optional.h would react to this. Maybe I'm not understanding what > you mean though. > > It seems to me that we simply don't need to support compiling the tree > with different std settings for different files -- it should be fine to > just assume that everything is compiled compatibly. > > Tom