Multiple FIFO queues for QByteArray

[VRonin]

I did not understand exactly your need but the FIFO container is QQueue

[McLion]

@VRonin

Why ever I did look at various other classes but not QQueue ... no clue, must have been blind somehow ... thanks a lot !

McL

[McLion]

@VRonin

Hmmm .. How would I arrange QQueue for a 2-dimensonal storage for 16 queues?

[VRonin]

std::array< QQueue<MyType> , 16>

[McLion]

@VRonin said in [Solved] Multiple FIFO queues for qByteArray:

std::array< QQueue<MyType> , 16>

This goes on the stack, right.
How about the heap?
Anyhow, I got a warning for upcoming C++ release when including <array>.

[VRonin]

QScopedPointer< QQueue<MyType>, QScopedPointerArrayDeleter > myQueue (new QQueue<MyType> [16]);

@McLion said in [Solved] Multiple FIFO queues for qByteArray:

Anyhow, I got a warning for upcoming C++ release when including <array>.

<array> is C++11 standard

[McLion]

@VRonin
Thanks ... never heard about. After 15+ years of plain C I have a lot to learn with Qt / C++.

This works, I mean at least it compiles:

QScopedPointer< QQueue<QByteArray>, QScopedPointerArrayDeleter<QQueue<QByteArray> > > myQueue (new QQueue<QByteArray>[16]);

This too:

myQueue = new QQueue<QByteArray>[16];

Am I correct that - except for the deleting of the object and protection from memory leaks - this ends up in the same?
Thanks for your great support.

[VRonin]

Yes, you are correct, the QScopedPointer does nothing but call delete [] when it goes out of scope

[kshegunov]

I'd go the ol' and simple way:

typedef QQueue<QByteArray> QByteArrayQueue; // Can be skipped, I just like typedefing
QVector<QByteArrayQueue> myQueueVector(16);

[VRonin]

Has to be noted, however, that both QQueue and QByteArray store the values internally on the heap so there is little gain in using QScopedPointer< QQueue<QByteArray>, QScopedPointerArrayDeleter<QQueue<QByteArray> > > myQueue (new QQueue<QByteArray>[16]); you should allocate a container (in the broad sense, so including QByteArray and QString) on the heap only if you need to manage its life-cycle, there is no risk of stack overflow

[McLion]

@VRonin
Thanks for the additional notes.
Lifetime does not need to be managed in this case - the object is created/initialized in the main constructor and is used as long as the application is alive.

[VRonin]

In this case I'd declare it as std::array< QQueue<MyType> , 16>

[kshegunov]

@VRonin. I'm dying to hear why std::array (and enforcing c++11) is better than a plain C-style array?

[VRonin]

From Effective Modern C++ by Scott Meyers

Of course, as a modern C++ developer, you’d naturally prefer a std::array to a built-in array

the 2 main things: bound checks and not losing the size once you pass it to a function. But I think in the end it's just a matter of taste so I would not argue any is better

[kshegunov]

I'd argue against the first, as the compiler puts the stack smashing dummies just to prevent that, as for the second I'd tend to agree. Probably the "best" thing is that you get a bit more type-safety from preventing implicit decay to T * const, but I daresay that's to be weighed against the increased binary size, and c++11 already (almost) throws type-safety out the window with the partial type inferral (i.e. auto).