Re: [PATCH v2] Class-ify ptid_t

[Simon Marchi <simon.marchi@polymtl.ca>]

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::<anonymous 
union>::<constructor>()’

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.