From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76526 invoked by alias); 6 Apr 2017 10:49:55 -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 76517 invoked by uid 89); 6 Apr 2017 10:49:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 10:49:52 +0000 Received: by mail-wr0-f176.google.com with SMTP id t20so55408403wra.1 for ; Thu, 06 Apr 2017 03:49:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+UpIQfLMv2PLRFblw8OyYJs9oioJSFyO3t7qf64vFcc=; b=jM17uUzBzm7f7mZVPXgHYrwWsE9f5rBTxgWTSZpuxOq3cTjCLGdHB32F10WkGLrR4Q Yv8/fH27GEJ64hRl2URpZR8yKWbB4M9+P/25IHXw5AZ8vlc1ilpzdkE7SFTLzSCNyAbi YlDmU2kg/FJBCDIJIcnhLqpp/bwjQoWceMIqqHAUgVcU6ByUoMrj6KePRPgKwuciKg7X D/ugamOz6T1jtkiaO7Z8Dmb8+uxcApBJjeSKwemey2vqmXUbPFYira9WJ75fyQVch9zO +u+5gDUfWgdpptGDlpwxS4OyuGzhxsYBH7VkwcphIweOgt9b63ggqe06cUjN1cY6miKU kV+A== X-Gm-Message-State: AFeK/H3Cbo58O4lssML+2wuoIxMMBhPMxp4cG27Y0Z2YW1ctnLBRBY5YTfX/LEXfi7/Lr6v+ X-Received: by 10.28.209.202 with SMTP id i193mr23648221wmg.17.1491475791973; Thu, 06 Apr 2017 03:49:51 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 55sm1652118wrz.27.2017.04.06.03.49.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 03:49:50 -0700 (PDT) Subject: Re: [PATCH 2/2] Class-ify ptid_t To: Simon Marchi References: <20170404183235.10589-1-simon.marchi@ericsson.com> <20170404183235.10589-2-simon.marchi@ericsson.com> <580e9a8a-d59b-095c-cf56-ee2f50fe46df@redhat.com> <84b33a5c655af3f344494c9e9ee473d6@polymtl.ca> <03bc3933d454f9fa01567a0e1000e201@polymtl.ca> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 06 Apr 2017 10:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <03bc3933d454f9fa01567a0e1000e201@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00138.txt.bz2 On 04/06/2017 03:15 AM, Simon Marchi wrote: > On 2017-04-05 17:31, Pedro Alves wrote: >>>> It's probably going to be worth it to sprinkle "constexpr" >>>> all over the new API. Helps with static_asserts in >>>> unit testing too. *cough* :-) >>> >>> Ok, will look into it. >> >> Thanks. constexpr in C++11 forces you to write a single >> return statement (C++14 gets rid of that requirement), >> but it looks quite doable. >> >> Also, note that it's not true that this type can't have a >> constructor. It can, as long as the type remains POD. > > Ah, so I was just missing the defaulted default constructor. Adding it > makes the type trivial, which then makes it POD. Right, almost. There's a couple other requirements beyond trivial, but they're fulfilled as well. See: http://en.cppreference.com/w/cpp/concept/PODType > >>> Is the following ok? >>> >>> struct thread_resume default_action { null_ptid }; >> >> ISTR that in C++11 you'll need the double "{{" levels, like: >> >> thread_resume default_action {{null_ptid}}; >> >> and that C++14 removed that requirement (brace elision). >> But I haven't confirmed. Whatever works with -std=c++11. > > It seems to work with a single pair of braces with c++11. I'll still > check that it does what we want at runtime, but I'd be surprised if it > didn't do the right thing. Sorry, yes, it's not necessary -- I somehow confused myself into thinking that the current double "{{" was because the ptid field was inside a structure that itself is inside the thread_resume structure. struct thread_resume { struct something_else { ptid_t thread; but "something_else" doesn't really exist... If it existed, then the double {{ would be necessary in C++11 to initialize the sub field, but not in C++. See brace elision here: http://en.cppreference.com/w/cpp/language/aggregate_initialization But now that I try, I can't make g++ nor clang++ error in c++11 with those constructs. Maybe other compilers would, though. In any case, the workaround would be trivial if we needed it -- just add the equals sign. >> >> >> +static_assert (std::is_pod::value, ""); >> + >> +static_assert (ptid_t(1).pid () == 1, ""); > > Wow, nice. So all the tests are probably going to be static. > > Just to be clear, do you suggest that we make a test that ensures ptid_t > is a POD, or you wrote that one just to show me it works? I We don't > really care if it is, it's just that the current situation (it being > used in another POD) requires it. Yes, I think we should put that in the unit test with a comment so that if someone tries to add something that would make it non-pod, gdb won't even compile. If/when we get to the point where we can/want to make it non-pod, we can remove the assertion then. Thanks, Pedro Alves