Re: [Development] QList
Em terça-feira, 21 de março de 2017, às 22:49:42 PDT, André Somers escreveu: > QVector keys; > keys.reserve(theHash.size()); > std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys)); > > Sure, it is longer than > auto keys = theHash.keys(); The whole issue here is the "sure it is longer". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Em domingo, 19 de março de 2017, às 11:44:44 PDT, Thiago Macieira escreveu: > On sábado, 18 de março de 2017 14:33:32 PDT Marc Mutz wrote: > > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > > class QStringView - has all the const functions > > > class QString : public QStringView - adds the mutating functions > > > class QtExclusive::QString : public QString > > > > No inheritance. These things have no is-a relationship whatsoever. > > Right, I came to the same conclusion in the shower after posting this and > then forgot to post once I was out. Ok, here's another shower idea. Instead of the above, we use a seldom used technique: private inheritance. class QStringView class QString : private QStringView class QtExclusive::QString : private QString Both QString and QtExclusive::QString would do a lot of: using QStringView::indexOf; using QStringView::contains; using QStringView::startsWith; using QStringView::endsWith; plus: QString trimmed() &&; QString trimmed() const &; etc. In fact, most of the mutating functions in the exclusive class can be *exactly* the reference-counted version, as the reference count will be 1, so the detach() will do nothing. The private inheritance solves this problem: > My problem was the exclusive kind, because you could then do: > > QtExclusive::QString es; > QString &s = es; > s = somethingElse(); > // es could now be sharing, which is a violation The second line above would fail to compile. At the same time, any changes to QStringView almost auomatically propagate to the other two classes. And almost all changes to QString go to QtExclusive::QString without even having to do anything. Another thing I'd want is for QStringView to carry the pointer to the QArrayData like QString does. In the regular QStringView uses, it would be null. This has the drawback that QStringView would now be passed by implicit reference instead of by value in registers (though, as we discovered, Windows 64-bit already does this). The reason I'd want this is for two use-cases: 1) when you create a QStringView from a QString (but not from QtExclusive::QString), it would carry the original string's QArrayData pointer. That's ok because if the pointer to the data is valid, the pointer to the allocation block is too. But when if you later did: m_string = sv; the new QString would resume reference counting from the original QString, without actually creating a copy. 2) for SSO: on little-endian machines, we need the first byte to have bit 0 set. The first byte is in the base class, so QStringView needs to start with that pointer. For QStringView we could alternatively also the bit 0 in the data begin pointer, but that technique would not work for QByteArrayView. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Op 21/03/2017 om 16:55 schreef Thiago Macieira: > Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu: >> Op 20/03/2017 om 23:43 schreef Kevin Kofler: >>> Marc Mutz wrote: https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326 5ae/src/kleo/stl_util.h> >>> Thanks for proving my point that the STL APIs require tons of copy&paste >>> boilerplate in every project. >> That's not just your point, it's Stephanovs point as well. The STL is a >> starting point, a good, well-tested set of basic building blocks. Nobody >> claimed it contains any and all containers or algoritms you'd ever need. >> In fact, in its first form it contained more, but large parts of it got >> backed out before standardization. Surely you don't expect Qt to supply >> every container type and every algorithm possible? > Not all, but a good set of algorithms that are in common use. Getting all > keys > and values is common, even if sometimes you leading to bad code. > Don't we have keyBegin and keyEnd for getting the keys? (No direct equivalent for values, it seems...): QVector keys; keys.reserve(theHash.size()); std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys)); Sure, it is longer than auto keys = theHash.keys(); but it does not bind you to using a container selected by Qt to return the keys in. If you need them in a vector, you can put them in a vector. If you want them in a set, you can put them in a set. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu: > Op 20/03/2017 om 23:43 schreef Kevin Kofler: > > Marc Mutz wrote: > >> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326 > >> 5ae/src/kleo/stl_util.h> > > Thanks for proving my point that the STL APIs require tons of copy&paste > > boilerplate in every project. > > That's not just your point, it's Stephanovs point as well. The STL is a > starting point, a good, well-tested set of basic building blocks. Nobody > claimed it contains any and all containers or algoritms you'd ever need. > In fact, in its first form it contained more, but large parts of it got > backed out before standardization. Surely you don't expect Qt to supply > every container type and every algorithm possible? Not all, but a good set of algorithms that are in common use. Getting all keys and values is common, even if sometimes you leading to bad code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields
On Sonntag, 19. März 2017 09:39:57 CET Robert Iakobashvili wrote: > Hi, > Sorry for cross-posting, but maybe Qt Android maintainer is knowledgeable > about the issue below. > > Nexus-7 with Android-6 > > The same Qt app built with 5.7.1 works properly > and with 5.8.0 appears a blue pointer down the cursor at text fields > (QTextEdit, QTextLine) > > The pointer is buggy and doesn't follow the cursor properly when positioning > and re-positioning child-windows/popups. How buggy? Please report a bug on https://bugreports.qt.io I wonder if it's a bug with Android handles or with the widgets themself not reporting the proper cursor position. To be honest, i never tried widgets on a platform that have cursor handles. > How to get rid from it? Unfortunately there is no way. Maybe a input method hint should be added for it? > Were it some theme changes or something else from 5.7 to 5.8? > Thanks Yes, support for selection handle was added. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Op 20/03/2017 om 23:43 schreef Kevin Kofler: > Marc Mutz wrote: >> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h > Thanks for proving my point that the STL APIs require tons of copy&paste > boilerplate in every project. > > That's not just your point, it's Stephanovs point as well. The STL is a starting point, a good, well-tested set of basic building blocks. Nobody claimed it contains any and all containers or algoritms you'd ever need. In fact, in its first form it contained more, but large parts of it got backed out before standardization. Surely you don't expect Qt to supply every container type and every algorithm possible? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Marc Mutz wrote: > Ah, QToolBoxPrivate::PageList? > > You think you need QArrayList-as-a-class for that? > > The answer is no: https://codereview.qt-project.org/188941 So that code was already not broken. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Yes, as Thiago nicely points out there is a long history. But using QList as
the name for something that we’d nowadays would call an array for Qt 4.0 is
something that was indeed somewhat inspired by Java. We were looking a lot at
the APIs provided in other languages (Java being the closest one to C++), as we
weren’t always happy with what the C++ standard provided.
But I’d propose we don’t dig through the past too much, the decisions done then
are nothing we can change anymore ;-)
Cheers,
Lars
> On 21 Mar 2017, at 04:57, Thiago Macieira wrote:
>
> Em segunda-feira, 20 de março de 2017, às 17:45:53 PDT, Kevin Kofler escreveu:
>> This assumption was already not true with Java 1.2, released December 8,
>> 1998. That release introduced java.util.List as a generic interface to ANY
>> list, including ArrayList. QList was introduced with Qt 4, released June 28,
>> 2005. So it is unfair to blame Qt for not following the obsolete
>> terminology you mention.
>
> You're forgetting Qt before 4.0. The current QList was introduced with Qt 4,
> but previous versions had QList too.
>
> I can't find the exact release date for 1.0, but it happened some time after
> 20-May-1995 (0.90) .
>
> Qt 1.x still supported compilers without template support (they were common
> in
> the early to mid 90s). If you had templates, then QList was a #define to
> QListT, which derived from QGList ("g" for generic), which was a
> doubly-linked
> list of pointers to the item in question. It had virtuals too. That is
> actually very similar to java.util.List...
>
> Qt 1.x also had a QVector (again, also provided as macro), deriving from
> QGVector, which was a pointer vector.
>
> Confusingly, what we now call "vector" was implemented by QArray, which
> derived from QGArray. QGArray managed only the byte-level array and QArray
> did
> the necessary casting to the element type, as well as multiplications and
> divisions by the element size. Unlike QList and QVector, QArray was reference-
> counted.
>
> QByteArray was typedef'ed to QArray. QString derived from QByteArray
> but still operated on arbitrary encoding. QBitArray derived from QByteArray.
> There were also QStrList and QStrVec, which respectively derived from
> QList and QVector.
>
> Qt 2.0 was released on 25-May-1999. Aside from removing support for compilers
> that didn't support templates, QList, QVector and QArray remained the same.
> It
> introduced QValueList, a doubly-linked list of values (not pointers). Like
> QArray, it was reference-counted. QString was converted to UTF-16 and the old
> Qt 1 QString became QCString (still deriving from QByteArray). Because of the
> conversion, QStrList and QStrVec no longer worked with QString, so
> QStringList
> was introduced, a specialisation of QValueList.
>
> Qt 3.0 was released 11-Oct-2001. Qt 2's QList and QVector were renamed to
> QPtrList and QPtrVector, while QArray became QMemArray. All three headers had
> a "compat" macro that would #define the old names, to aid in porting from Qt
> 2.
> It expanded on Qt 2's QValueList and added QValueVector, with our current
> understanding of what a vector is. Like QValueList, it was reference-counted.
>
> Most of us still remember, Qt 4.0, which was packaged 24-June-2005 (date of
> the files inside the tarball). There was even a dance about it...
>
> Qt 3's QPtrList, QPtrVector (that is, Qt 1's QList and QVector) as well as
> QValueList and QValueVector became Q3PtrList, Q3PtrVector, Q3ValueList and
> Q3ValueVector. A new implementation was provided for QList, QVector and
> QByteArray, in the forms that we have today. QCString became Q3CString,
> deriving from Q3MemArray, deriving from Q3GArray. QBitArray moved to having a
> QByteArray member instead of deriving from it.
>
> Qt 5 dropped the Qt 1 code and introduced QArrayData, QTypedArrayData,
> QArrayDataPointer and QArrayDataOps, but time ran out before we could
> properly
> make use of them. QADP and QADO are unused in the main version; I'm using
> them
> in my branch in a class called QGenericArray (a base class of QVector).
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
