[Development] QList

[Marc Mutz]

On Saturday 18 March 2017 20:05:59 Ville Voutilainen wrote:
> On 18 March 2017 at 19:37, Marc Mutz <marc.mutz at kdab.com> wrote:
> > > No, that is false. You can keep using QList for now everywhere you used
> > it so far, in non-generic code. Nothing changes for existing types. And
> > for new types, the compiler will make sure that you don't get away with
> > QList. We do recommened to use auto to receive QLists to avoid having to
> > port these code lines manually come Qt 6. I do not consider auto
> > variables "generic code".
> 
> Right. I, however, do consider them generic code. :)

You're free to call a chicken a pig for your own entertainment, but in the 
interest of understanding what everyone says, please stick to established 
definitions. Generic code is generally understood to be code that uses generic 
programming, which in turn is defined as

  [...] an approach to software decomposition whereby fundamental requirements
  on types are abstracted from across concrete examples of algorithms and data
  structures and formalised as concepts, analogously to the abstraction of
  algebraic theories in abstract algebra.

(Wikipedia, citing Stepanov/Musser). So neither

   auto i = int{0};

nor

    QHash<int, QStringView> hash = ...;
    auto values = hash.values();

are examples of generic code.

> Ok. I think the first thing we need is the QList replacement, whatever
> it is. I think the poisoning
> ideas can follow that, if at all.

That, at least, is simple: QVector is currectly the only viable choice. What 
to do with QVector in Qt 6 is in open debate.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts