[Development] Meaning of Q_PRIMITIVE_TYPE?

[lars.knoll at nokia.com]

On 3/28/12 7:06 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>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.

Not sure it's worth differentiating here, and we're actually using
Q_PRIMITIVE_TYPE today for types that aren't real primitives. I'd simply
continue using Q_PRIMITIVE_TYPE as we did, ie. for classes matching the 4
conditions above.

Cheers,
Lars


>
>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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development