[Development] Meaning of Q_PRIMITIVE_TYPE?

Thiago Macieira thiago.macieira at intel.com
Wed Mar 28 19:06:46 CEST 2012


On quarta-feira, 28 de março de 2012 15.37.46, Marc Mutz wrote:
> So I'd like to propose to extend the scope of Q_PRIMITIVE_TYPE to cover such
> non-POD classes that are nevertheless close enough to PODs.
> 
> That means:
> 1a. memset(0, &t, sizeof(T)) constructs a valid object, and that object is
>    equal to T(), if T has a default constructor.

That crashes, but I'm sure you meant well :-)

> -alternatively-
> 1b Any bit pattern represents a valid object (one that the dtor can be
> called on).
> 2. memcpy() creates a valid independent copy of the object
> 3. The dtor doesn't need to be run.
> 
> With 1a+2+3, primitiveness is a strict superset of PODness.
> 
> If Jędrzej is right, though, and the intent was for primitive types to not
> require initialisation, ie. the 1b alternative is used, PODness is no longer
> sufficient for primitiveness. And cups_option_t must be downgraded to
> movable.
> 
> Looking at existing usage, I think 1a+2+3 comes closest to what everyone
> thinks primitive types mean, so I'd like to update the docs accordingly.
> 
> Opinions?

Note that #2 is the difference between those simple types and the regular, 
movable types. QString is movable, but a memcpy does not create a new 
independent object. With that, the traits that I think are interesting to us 
are:

 - trivial default constructor ( = can be initialised by memset)
 - trivially copyable ( = memcpy creates independent object)
   [note: implies the next two]
 - movable ( = memcpy can be performed if the old object is discarded) - not a 
C++11 definition
 - trivial destructor ( = no destructor need be run)

We currently only care about two combinations:

 - Q_PRIMITIVE_TYPE = all of them
 - Q_MOVABLE_TYPE = just the trivially-movable trait

Note that when all four traits are grouped together, C++11 defines them as 
"trivial type".

The only thing I ask is that we keep Q_PRIMITIVE_TYPE for *real* primitive 
types and create a new macro, say Q_TRIVIAL_TYPE, for everything that matches 
the constraints but is not an actual primitive (fundamental). I don't know if 
we'll ever need the difference, but I'd rather we had it proper if it doesn't 
cost us much.

The closest definition that C++11 has for our Q_PRIMITIVE_TYPE is either 
"scalar type" (arithmetic, enums, pointers) or "fundamental type" (arithmetic, 
void).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120328/92287085/attachment.sig>


More information about the Development mailing list