Shared libraries [LWN.net]

Shared libraries

Posted Nov 26, 2025 16:25 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: Shared libraries by intelfx
Parent article: APT Rust requirement raises questions

Qt is a "kitchen sink" library which tries to offer everything you might need, so it's hard to compare, maybe a Rust Qt-like would insist on offering all these container types Rust already provides for example, just as Qt feels the need to supply QList (the growable array type) QStack (the same type, with a more stack flavoured API) and QQueue (the same type again AFAIK but now used to back a ring buffer abstraction presented as a FIFO Queue)

C++ doesn't provide very good container types, but it does provide a reasonably good growable array type, with the expected amortized constant time growth, the basic reservation feature - and QList isn't actually better. So the fact QList was provided anyway suggests the same mindset would apply in Rust for a library in that mould.

But on the other hand, a library which didn't insist on offering its own version of things you already have might actually reduce the redundancy and the extra marshalling overhead from the duplication, so that might actually be a net win in size terms.

to post comments

Shared libraries

Posted Nov 26, 2025 17:19 UTC (Wed) by excors (subscriber, #95769) [Link]

> C++ doesn't provide very good container types, but it does provide a reasonably good growable array type, with the expected amortized constant time growth, the basic reservation feature - and QList isn't actually better. So the fact QList was provided anyway suggests the same mindset would apply in Rust for a library in that mould.

Back in 1998 they explained: (https://github.com/KDE/qt1/blob/25d30943816da9c28cded9ac7...)

> Qt's containers are much more portable than the STL is. When we started writing Qt, STL was far away in the future, and when we released Qt 1.0, no widely-used compilers could compile the STL. For a library such as Qt, it is of course very important to compile on the widest possible variety of compilers.

They also justified it by having different space/time tradeoffs to STL containers (and still make that argument in today's documentation); but if the STL had been widely available with decent-quality implementations when they started, I imagine they would have simply used that and put up with its other limitations. And anyone starting today in Rust would simply use Rust's std containers.