[Development] Changing container privates again

[Thiago Macieira]

On segunda-feira, 11 de junho de 2012 16.00.58, João Abecasis wrote:
> Thiago Macieira wrote:
> >> Following Olivier's suggestion I think it might be beneficial to have
> >> alloc
> >> unconditionally in the base class, even if it is not being used at times.
> >> If nothing else, it saves padding. Additionally, deleter function and
> >> token
> >> would be more generally useful if they can be used with the alloc member.
> > 
> > Yes, if we move the alloc member to the main struct, then it will simply
> > occupy the space currently used for padding. The total overhead for an
> > allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is
> > 16- byte aligned, this means our data is always 8 bytes off.
> > 
> > In my opinion, that's actually worse than having a larger header.
> 
> But that's what we currently have and wouldn't change with you suggestion
> above, right?

We currently have 24 bytes. With my changes, it goes to 32 bytes, which is the 
second most ideal value. The ideal one would be 16 bytes.

> Would it be worth to set the minimum alignment for the data as 16-bytes, at
> the expense of padding we explicitly add in QArrayData::allocate? (Since
> this decision can be done inside that function it would have no impact on
> ABI)

QArrayData::allocate can take that decision. In fact, that was in my plans for 
some future improvement.

But that means we'll use 32 bytes anyway for all allocations, in any platform.

-- 
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/20120611/fb225245/attachment.sig>