Not quite the same: http://doc.qt.io/qt-5/qstringlist.html
filter(), join(), replaceIn(), etc.
 
I kinda wonder if Qt needs to implement filterable, joinable, etc interfaces.
 
Sent: Monday, November 28, 2016 at 1:18 PM
From: "Philip Schuchardt" <vpica...@gmail.com>
To: "Jason H" <jh...@gmx.com>, "André Somers" <an...@familiesomers.nl>
Cc: interest@qt-project.org
Subject: Re: [Interest] Qt containers deprecated with 5.0?
After reading some articles some types like QString are marked as movable and are efficiently stored in QList. They'll use about the same amount of memory as a QVector so it seems unlikely for QStringList to switch to QStringVector. Plus you can add QVector<QString> yourself with a typedef. :D  
 
On Mon, Nov 28, 2016 at 1:04 PM Jason H <jh...@gmx.com> wrote:

>
> Op 28/11/2016 om 11:27 schreef Michael Sué:
> > Hi André,
> >
> >> There is nothing wrong with using Qt containers either (with the exception of QList, which you will want to stear clear of as much as you can), as as
> >> noted, you can (and should) use the std algorithms on them just fine.
> > What's wrong with QList (as compared to other implementations of a list)?
> >
> What makes you think that QList implements a list (like other
> implementions at least)?
>
> Anyway: see the blog or one of the recorded talks from Qt conferences on
> this topic. You will want to get into the habbit of raising a red flag
> whenever you do a code review and find a QList, and start typing QVector
> instead of QList whenevery you write code yourself.

I look forward to using QStringVector
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
Phi|ip
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to