[Interest] QT API wrapper around std:: containers?
felixover at gmail.com
Fri Jan 30 09:41:06 CET 2015
well, i guess i would 'fix' that by using either qint64 or quint64, after
all that's why i do it. :)
The container in question holds about ~10K elements on average and for most
use cases. But now a user designed his data in such a way that the
container has to go past the limit for a short time. Which really isnt much
of an issue if you have the memory.
Of course me now telling the guy "we dont like how your format your data"
isnt going to fly so well with him. And the limit just isnt necessary.
2015-01-30 9:14 GMT+01:00 André Somers <andre at familiesomers.nl>:
> Felix morack schreef op 29-1-2015 om 21:05:
> > Hi,
> > In light of the size limitations of Qt containers, a collegue
> > suggested writing an API wrapper around a std:: container. His idea
> > was to template-derive from a std::vector or std::map and implement
> > the Qt API as a wrapper around the std:: API.
> > Has this been attempted before?
> I think you'll run into problems pretty quickly, if you want to keep Qt
> API available. How, for instance, are you going to wrap the int
> indexOf(const T& value, int from) function? What will you return in case
> the value is not found?
> The look of much stl code hurts my eyes with all these underscores,
> namespaces and other unneeded items, but technically a lot of that code
> is very well designed. Qt containers support much of the stl API, so you
> can move towards using STL equivalents gradualy already. Just use stl
> algoritms to find items, and you soon won't be needing your indexOf
> function anymore. At that point, you can just replace your Qt container
> with an SQL equivalent.
> And indeed: if you really need 2^31 elements in your containers, you
> probably need a different container than a Qt provided one...
> Interest mailing list
> Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest