[Qt-interest] Qt Containers (or: why I must use STL)

[Thiago Macieira]

Em Segunda-feira 12. Outubro 2009, às 23.36.43, Stephen Bryant escreveu:
> Hello everybody!
> 
> Am I the only person to have run into this?
> 
> If I add items to a container, there is no way to tell if it failed.

Simple: it didn't fail.

In any case, std::bad_alloc will get thrown if the allocation fails. This 
because operator new throws, nothing to do with Qt. In version 4.6, we're just 
handling it better.

> Given that Qt doesn't throw exceptions, and the methods return void,
> does anybody know how to do this?  I tried resizing up and up to see
> what happens, and the whole program hung.
> 
> Actually, it's worse than that: the reserve() and resize() methods
> take a signed int.  Signed?  That's just plain silly!
> On x86_64, int is still only 4 bytes, so despite masses
> of memory, I can never have a byte array larger than 2GB.

You mean 2 billion elements. In a QList, that's at least 16 GB of memory, for 
the array alone.

> I know how I'd like to fix it, but I suspect it may not be possible
> without breaking binary compatibility - at least on 32-bit.  Where
> we now have methods such as this:
> 
>     void QVector::resize ( int size );
> 
> I would add this (and mark the other as deprecated):
> 
>     bool QVector::resize ( const size_t size );
> 
> 
> I didn't enter a bug report for this.  I found one already: 132094
> (QVector crashes when allocation fails).  It was rejected with the
> following reason: Qt doesn't handle out-of-memory scenarios cleanly.
> 
> Is that a joke?  It doesn't handle them at all!  That in itself is
> quite a major bug.

It's not if it's not designed to. To put it plainly: ensure that your 
applications have always enough memory. Add more memory to your device if 
you're running out of it, instead of trying to resolve an out-of-memory 
situation. This includes virtual memory.

Even if we get Qt containers to handle that properly, you're probably going to 
crash in other Qt classes that are less forgiving, including the entire GUI 
part.

We looked at how much effort it would be to get full out-of-memory support in 
Qt (including GUI, but excluding WebKit). And we decided we have better things 
to do with our time. We're looking into getting the containers to not 
completely crash your application when they run out of memory. This should be 
working in Qt 4.6 now, so please try it.

But we still cannot change the size of the types. The choice for "int" was 
deliberate, because it makes the API so much simpler. Using size_t (which is 
unsigned, so it usually creates a lot of warnings in the user code) would only 
lead to more complexity.

In any case, a QList of 2 billion elements is probably a poor design choice. 
If you do want to load that many elements into memory, you need at the very 
least 16 GB of RAM, or twice that much if you ever try to append. If you do 
have that many elements, I recommend you find a more suitable container for 
handling them.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091013/dececca1/attachment.bin