From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39667 invoked by alias); 7 Apr 2017 03:21:05 -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 18319 invoked by uid 89); 7 Apr 2017 03:16:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=life, late X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 03:16:33 +0000 Received: by simark.ca (Postfix, from userid 33) id 705451E80F; Thu, 6 Apr 2017 23:16:33 -0400 (EDT) To: Pedro Alves Subject: Re: [PATCH v2] Class-ify ptid_t X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 07 Apr 2017 03:21:00 -0000 From: Simon Marchi Cc: Simon Marchi , gdb-patches@sourceware.org In-Reply-To: References: <20170406190328.21103-1-simon.marchi@ericsson.com> <78ec4cd7-8a6e-d757-cb1f-de7e3bb52aab@redhat.com> <01ede052c2a7f8717e338e3e4de20a41@polymtl.ca> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00155.txt.bz2 On 2017-04-06 21:56, Pedro Alves wrote: >> 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. Err sorry, I got confused. The error I saw initially was about the target_waitstatus, where the ptid_t is in an union: /home/simark/src/binutils-gdb/gdb/target/waitstatus.h:104:8: note: ‘target_waitstatus::target_waitstatus()’ is implicitly deleted because the default definition would be ill-formed: struct target_waitstatus ^~~~~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/gdb/target/waitstatus.h:104:8: error: use of deleted function ‘target_waitstatus::::()’ If you make a simple default constructor, like I tried in the beginning: ptid_t () {} you'll see this error when building target.o. I wrongfully attributed this error to the fact that target_waitstatus didn't have a constructor of its own, but I now see it doesn't make sense. It must've been late :). >> 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? Oops, s/now/no/. What I meant is that if you use malloc for an object of a type you shouldn't (because it's not trivial), nothing will warn you. The is_pod check protects us from that, since it will tell us if the class ever becomes unsafe to malloc.