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

Stephen Bryant steve at bawue.de
Tue Oct 13 15:08:54 CEST 2009


Hi,

Thanks for the response.

While I understand about bad_alloc exceptions for 'new', the Qt code I'm
looking at seems explicitly not to use this, eg: reserve() and resize().
Is this different in 4.6?

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

Elements?  OK, but billion?  I'm sure I meant thousand million!!  :-)

Anyhow, I'm definitely not for storing large numbers of elements in
contiguous memory unless absolutely necessary.  However, consider
processing large amounts of raw data from sensors, or audio or video
etc.  This is really just a byte array, and the largest I can get from
Qt is 2GB.

> 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 sounds somewhat chicken-and-egg.  I almost never have any control
over the amount of free memory available on a system.  I would like to
be able to safely use what is there, and cleanly detect when a limit is
reached.

Moving the wall doesn't really solve the problem of running into it.  We
need to be able to see where we're going.

For certain types of data processing, using less memory still works, and
the whole thing just takes longer.  Moreover, the size of such data buffers
can dwarf the other program data, so getting (for example) only 8GB
contiguous instead of 12 or whatever doesn't automatically mean that the
rest of the program is in danger of running out.

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

I'm afraid you've lost me on this one.  How is 'int' simpler than 'size_t'?
Why are there warnings?  STL manages to have container::size_type defined
as size_t, and I'm not seeing warnings for that on any of the platforms
I'm building on.  Is this limited to certain systems, perhaps?

I wasn't expecting this type to be changed in the near future at all, but
perhaps it could be reviewed for Qt5?

I'll certainly look more closely at the 4.6 code.  I do not have any hatred
of STL containers, as some seem to.  It just seems silly to use Qt and not
to be able to use its containers.

Steve



More information about the Qt-interest-old mailing list