From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83073 invoked by alias); 7 Apr 2017 01:56:06 -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 83019 invoked by uid 89); 7 Apr 2017 01:56:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=life X-HELO: mail-wr0-f177.google.com Received: from mail-wr0-f177.google.com (HELO mail-wr0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 01:56:03 +0000 Received: by mail-wr0-f177.google.com with SMTP id t20so87075882wra.1 for ; Thu, 06 Apr 2017 18:56:04 -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=IdAzDJMyJUkkBmq7iN9Kv3bKG9KjcS/nV7JEJYoCzOo=; b=tVQCbQtMFYfrzgY/2Oj7kb1lGnYAcGupKH53e4pboO71cS5f/wgDNZj/orf3ykomes 1lE56yR9kv8TD9oBmPUoPJioPdYIGlA85MVcdUVfxBTMyc7Xyt/q3d9zN7uwUF4aYnIq gYCux7txP7OjfTPH9MB30VtyIlj+SV2cfpqoov5l5rQHtNfP/+AJaB4ORl22NnyOaWuh kkrTjTvVfMDKQ2pltBrGtp0YSZRXgAMUm9XKDqAHFGU7RhU9C0FWphwe90O8i+bSBrDE +mVnj13lwABl0JAbRMWALTJ/U2yzq9gEg2qVTy/g0LLTIfv+I/0lil4nRO3p39/7ZB3n FLnw== X-Gm-Message-State: AFeK/H1UewzF9YhAGymcSWZdUacXWszbBQ4Ocuws5/aZ1tFq2+DkFk86HB5JZUl3wdk+A/eW X-Received: by 10.223.163.28 with SMTP id c28mr30744674wrb.186.1491530162350; Thu, 06 Apr 2017 18:56:02 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id t16sm4117747wra.44.2017.04.06.18.56.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 18:56:01 -0700 (PDT) Subject: Re: [PATCH v2] Class-ify ptid_t To: Simon Marchi References: <20170406190328.21103-1-simon.marchi@ericsson.com> <78ec4cd7-8a6e-d757-cb1f-de7e3bb52aab@redhat.com> <01ede052c2a7f8717e338e3e4de20a41@polymtl.ca> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 07 Apr 2017 01:56: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: <01ede052c2a7f8717e338e3e4de20a41@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00153.txt.bz2 On 04/07/2017 01:04 AM, Simon Marchi wrote: >> Hmm, I think this comment too lax. There _is_ a reason this type >> must remain POD for the time being. So I think that's what we >> should say here: >> >> /* Check that the ptid_t class is POD. >> >> This is a requirement for a long as we have ptids embedded in >> structures allocated with malloc. */ > > Ah, makes sense. I was only thinking about the instances where ptid_t > is embedded in structures allocated statically. In those cases, > compilation would fail anyway, which is why I didn't really see the > point of that test. Actually, non-PODs in structures allocated statically is perfectly fine. The compiler arranges for the objects to have their constructors called. That's why we can e.g., have global std::vector objects or function local static std::string objects (both non-PODs), etc. So we could e.g., have a default ptid_t ctor that initializes the pid/lwpid/tid fields to zeros instead of leaving them undefined. Except, if we did that, then the ctor would no longer be trivial, and so the type would no longer be POD, meaning we couldn't create a ptid with malloc and use it straight away. We'd have to either call the ctor manually with placement new after malloc to bring to object to life, and call the dtor manually too (but that's off course cumbersome), or we'd have to use normal new/delete instead, which is the natural thing to do, but we're a bit far away from doing that everywhere. > But of course, it's important for malloc'ed > structures as well, for which we get now error/warning. Hmm, I'm not quite picturing what error/warning we now get? Thanks, Pedro Alves