[Qt5-feedback] Real 64 Bit support ?

[Stephen Bryant]

Hi,

I'm slightly late to this thread, but I wanted to chime in.
Sorry to pick on André, but he made some of the best points worth responding 
to!

I find the choice of a signed integer for the Qt container size_type often 
quite frustrating.


André Pönitz wrote:
> Having _different_ sizes (32/64 bit) depending on architecture spoils
> cross-platform data exchange using e.g. QDataStream.

Having _different_ endian-ness depending on architecture spoils cross-platform 
data exchange, yet somehow we managed to get over it - normally by agreeing 
what we will send before we send it.

> Having 31 bit for sizes is definitely "good enough" for all kinds of
> "mainstream" use cases.

I think you're wrong: the largest contiguous sequence of bytes that Qt will 
currently give me is limited to 2^31 - that's only 2GB.

Of course there are non-Qt classes, hacks (eg: vector of quint64), or other 
'multiple buffer' solutions, but why do that?  It's not clean.


> And to pre-empt the "int vs uint" debate. I don't have a strong opinion
> here. On the "pro" side we have less typing, a safe way for "interating
> downwards", the latter with the potential to safe a register when looping,
> and a way to specify an "invalid" index (-1 is used for that in the Qt API
> commonly). Also changing it would _silently_ break code that relies on
> "index < 0" conditions.

> On the "contra" side, it reduces "address space" by a factor of two, and
> it's different from what the Standard Library does.

STL and most other stuff, it seems to me.  We already have to code this way 
when using size_t.  I should also note that STL uses size_t as its size_type.

By the way, it already 'silently' broke any code that came from STL to what 
initially appeared to be a compatible interface.  Given that Qt4 -> 5  will be 
introducing plenty of other interface changes, I don't see a change here as 
problematic.  It would be covered in the docs, and compiler switches can 
enable warnings for unsafe comparisons.

It seems silly to me that half of the possible index values can't ever 
actually be valid.  It would make much more sense to have the data type match 
what it can actually be used for.



André Pönitz wrote:
> Right now we can push in a QVector on one side and pull it out on the other
> side without problem, and without caring who the other side is. That is
> _very_ convenient, especially when the "other side" is some file on some
> file server that is accessed by machines with different architectures.

My opinion is that effective use of local memory has to take precedence over 
ease of network data transfer.


Yves Bailly wrote:
> Data exchange implies serializing things in a very controlled way, isn't
> it? I avoid sending a mere "int" through a QDataStream, I always cast it
> to a known-size type
[...]
> I would treat "size_t" just the same way, so no data exchange problem.

I believe this is the only correct way of doing it.  As the whole endian thing 
demonstrated, the format of data when transferred must be separated from the 
in-memory format.  How data is marshalled is a separate subject.


I would very much like to see size_t as the size_type in Qt5.  It makes the 
best use of what is available on the local platform.


Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110516/7805325b/attachment-0001.bin