Re: [PATCH v2] Class-ify ptid_t

[Pedro Alves <palves@redhat.com>]

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