Re: [Development] QList

[Marc Mutz]

On Tuesday 21 March 2017 01:53:46 Kevin Kofler wrote:
> Marc Mutz wrote:
> > On Monday 20 March 2017 23:48:14 Kevin Kofler wrote:
> >> Advantages:
> >> 
> >> - code that needs QArrayList because it assumes stability of references
> >> 
> >>   could move to it right now, including the examples you keep bringing
> >>   up every so often. So it would allow fixing bugs now rather than in
> >>   Qt 6.
> > 
> > What example?
> 
> The ones you kept claiming I volunteered to fix. (I did not.)

Ah, QToolBoxPrivate::PageList?

You think you need QArrayList-as-a-class for that?

The answer is no: https://codereview.qt-project.org/188941

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Thiago Macieira]

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

Re: [Development] QList

[Kevin Kofler]

Marc Mutz wrote:

> On Monday 20 March 2017 23:48:14 Kevin Kofler wrote:
>> Advantages:
>> 
>> - code that needs QArrayList because it assumes stability of references
>>   could move to it right now, including the examples you keep bringing up
>>   every so often. So it would allow fixing bugs now rather than in Qt 6.
> 
> What example?

The ones you kept claiming I volunteered to fix. (I did not.)

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Kevin Kofler]

Martin Smith wrote:
> Aside: I'm from that bygone era long before Qt, when a "list" in computer
> programming always meant linked list. A sequence of contiguous data
> entries was an array. There were no exceptions. So even now, after using
> QList for more than a decade, I still forget that it's not a linked list.

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.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 23:48:14 Kevin Kofler wrote:
> Advantages:
> 
> - code that needs QArrayList because it assumes stability of references
>   could move to it right now, including the examples you keep bringing up
>   every so often. So it would allow fixing bugs now rather than in Qt 6.

What example?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[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
boilerplate in every project.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Saturday 18 March 2017 10:51:06 Marc Mutz wrote:
> 4. Provide QArrayList for code that needs stability of references
> (stability statically checked in Qt 5, enforced in Qt 6).

There's disagreement over this last part. I have opted to provide a 
constrained type alias QArrayList that can only be used to alias QLists that 
already use QListData::IndirectLayout (= pointers to heap-allocated objects).

The intent was to allow QArrayList use in existing API. E.g., and I'm not sure 
I'm proposing this, QList could be renamed to QArrayList 
because it currently is. And some users may have come to depend on the 
stability-of-references feature provided by inefficient QLists.

A type alias makes this trivial, because it introduces neither SC nor BC. It's 
simply a way to document, and statically check, that that particular QList has 
IndirectLayout.

The other option would be to copy QList, strip out the optimisation that makes 
it use layouts other than IndirectLayout and call the result QArrayList.

Disadvantages:

- migration of QLists used in APIs has to wait until Qt 6
- two almost identical code bases that are very likely to get out of sync,
  accidentally or intentionally, before one of them gets ditched in Qt 6
- duplicate documentation to write, maintain, explain difference, ...
  With the type alias, we just need to document the alias.

So, updated and refined tail of QList exit strategy would be:

4. Provide a type alias, QArrayList, for QList, constrained on actually
   QListData::IndirectLayout QLists. Use it to mark QList uses that either
   a. are (includes QVariant, QModelIndex, QImage, QPixmap, ...)
   b. should conceptually be (excludes QVariant, QModelIndex, ...)
   array lists (ie. arrays of pointers to heap-allocated objects) in a BC and
   SC way.

In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the 
names):

5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it always
   use IndirectLayout.
6. Provide a deprecated type alias Q6List that resolves to either Q6Vector or
   Q6ArrayList, depending on similar conditions Q5List used before.
7. Replace all Q6List uses in API with either Q6ArrayList or Q6Vector. 

Advantages:

- only one QList implementation to maintain and document in both Qt 5 and 6.
- adjustable SC:

Because this introduces a SiC/SC knob that's interesting to turn:

If Q6List uses the exact same conditions as Q5List, Q6List would 
have the same layout as Q5List, making 'QList' SC. But 
Q6List would map to Q6ArrayList while the Qt API very 
probably will have migrated to Q6Vector, making 'QList' 
SiC.

If we, say, dropped the isLarge trait from the condition, then some 
Q6List would switch memory layout, breaking stability of references 
for some UserTypes, compared to Q5List, making 'QList' SiC. But 
Q6List would map to Q6Vector, making 'QList', 
QList etc. SC.

Not sure where that knob will end up, but it's nice that it's there.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Wishes for C++ standard or compilers

[Thiago Macieira]

Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu:
> == Containers ==
> 
> And then there's what to do with the containers. Here's where Marc's opinion
> and mine differ considerably. Aside from the need to maintain source
> compatibility, I feel like we should keep our containers and keep implicit
> sharing (same solution as for QString). We know COW can be a pessimisation
> for performance-sentive code, but the question is whether it is so for
> regular developers who don't know how to write performance-sensitive code.
> If developers will make mistakes, can we reduce the impact?

Here's another wish that I remembered: destructive move a.k.a. relocation.

The destructive move is a special case of move in which the source is also 
detroyed in the process, as opposed to the regular move in which its contents 
get moved but the destructor is still called and the object is still in a 
valid (but unspecified) state.

Then we have an even more special case of destructive move: trivial 
destructive move (trivial relocation), which is just a memcpy. A type with 
trivial move constructor and trivial destructor is trivially relocatable too, 
since the trivial destructor does nothing and the trivial move constructor is 
memcpy. However, the trick is to implement the relocation for non-trivial 
types.

Note that this needs the discussion on the lifetime of trivial types to be 
finished.

-- 
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

[Lars Knoll]

> On 20 Mar 2017, at 19:04, Marc Mutz  wrote:
> 
> On Monday 20 March 2017 16:10:53 Lars Knoll wrote:
>> This means we have to be careful with any changes that could break large
>> amounts of source code. So QList will have to exist as a type in Qt 6 with
>> an API that is as source compatible to the one in Qt 5 as we can make it,
>> while we need to still try to deprecate it for new code and offer better
>> alternatives.
> 
> "Deprecate for new code"? What does that mean, exactly?

Pretty much the same as just 'deprecate' ;-)

We don't use it ourselves anymore in our API (and have hopefully removed in as 
much as possible in our implementations). Existing user code using the class 
should continue to work as much as possible (maybe with somewhat different 
performance characteristics though). Compiler warnings when using it should be 
there, but people will need an option to turn them off so they don't drown in 
them.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Konstantin Tokarev]

20.03.2017, 19:40, "Scott Aron Bloom" :
> Now, myself, and a few others are sitting on Qt 5.5 because of the issues 
> with the web browser change in 5.6... but that's another issue

You should upgrade to QtWebKit TP5 [1], binary builds are available for Qt 5.8 
for all supported desktop platforms

[1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of std::function in Qt API

[Thiago Macieira]

Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián 
Nicanor Pérez Meyer escreveu:
> In the (2) case it will mean that we distro packagers will be forced to
> change Qt's SONAME. Yeah, the whole of it.

Why? We're not changing our ABI. To be clear: we're not proposing replacing 
what we have right now with std::function, but adding it to new places as the 
needs arise.

The point however is that if libstdc++ does break its ABI, then you'll have to 
rebuild half the world anyway. The few libraries and applications that did use 
Qt and were not affected would be the minority. Telling them apart could be a 
higher cost than just rebuilding -- remember, ALL C++ code links to libstdc++, 
regardless of whether it was subject to the ABI break or not.

And if libstdc++ changes its soname, then you HAVE to rebuild Qt and 
everything, anyway.

> Oh, and if some non-other Qt api is exposed it should also become part of
> the SONAME.

Again, why? We've exposed C and Xlib API for years and have never had "X11" in 
the name (or "xcb" now). Tell me of other libraries that follow this naming 
scheme, because I haven't heard of them.

But note I want to limit which API we're allowed to expose.

> So if we are going to only expose libstdc++'s API weshould really consider
> making it part of the SONAME. After all we discussed some time ago that the
> libstdc++ lib doesn't breaks BC so frequently.

No, we shouldn't because it's the frigging C++ *Standard* *Library.* EVERY 
single C++ application links to it, if you as much as used "new" in your code.

I've said this before: there's a way to split libstdc++ into two, so that the 
library providing the base functionality (new/delete, typeinfo, 
std::exception, cxxabi) is not the same library as the one providing the 
higher-level functionality. That would allow sharing the base things that all 
C++ applications and libraries need from the higher level classes, including 
that of other implementations like libc++.

Yet no Linux distribution does that. For 4 years many have provided libc++ 
without opting to this solution. That tells me they are not interested in 
providing binary compatibility between libstdc++ and other C++ standard 
library implementations. As a consequence, if they are not, why should we be?

-- 
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

[Ville Voutilainen]

On 20 March 2017 at 20:55, Marc Mutz  wrote:
> On Monday 20 March 2017 19:11:47 Ville Voutilainen wrote:
>> However, I think it's still better to
>> keep the name in the APIs and change
>> the meaning of the name. That's far from ideal, but it still provides
>> a better compatibility story than
>> eradicating the name from APIs, and we can still take reasonable steps
>> towards eventually eradicating
>> the name.
>
> You want to keep the name used in the API to eventually eradicate the name?
> Can you explain how the first helps with the latter?


By changing the implementation under that name and turning the name
into an alias,
encouraging users to migrate from that name to the name of the real
facility, deprecating the legacy name,
and then eventually removing the legacy name; in that order. I suppose
others have described
plans to some extent similar.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 19:11:47 Ville Voutilainen wrote:
> However, I think it's still better to
> keep the name in the APIs and change
> the meaning of the name. That's far from ideal, but it still provides
> a better compatibility story than
> eradicating the name from APIs, and we can still take reasonable steps
> towards eventually eradicating
> the name.

You want to keep the name used in the API to eventually eradicate the name? 
Can you explain how the first helps with the latter?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Ville Voutilainen]

On 20 March 2017 at 19:51, Marc Mutz  wrote:
>> Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm
>> not entirely convinced
>> it broke "an awful lot of lines of code", and it indeed specifically
>> did not and does not break very
>> vast swaths of existing code, because *every* function call still
>> behaves as they did before,
>> although certain pointer conversions don't. It certainly doesn't
>> produce a fear that
>> it would break "the whole world".
>
> I was just pulling your leg :)

That doesn't make the analogy more correct. :P

> Though it certainly broke a lot of Qt code and we're still recovering:
>
>   5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer)
>   c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete)

It can certainly break function wrappers.

>> > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt
>> > 6. You can define your own MyQListOrQVector type alias. Or you can
>> > #ifdef. It's up to you.
>>
>> That's great, but before I have migrated all my code to any of those,
>> it's simply better
>> to change QList to be a QVector, fix the cases that require reference
>> stability (which you're
>> already doing in some places) to use a different type, deprecate
>> direct uses of QList
>> and *then* _eventually_ remove QList altogether, rather than doing it
>> without any grace
>> period.
>
> When I said "Kill QList in Qt 6", I mean eradicate it from our APIs. The name,
> too. Whether the QList class lives on to support legacy code is a different
> question. As long as it's deprecated, and maybe moved to a Qt5Support module
> (that name will have raised some hairs now :), I'm fine with that.


Right; I have been laboring under the misconception that you want to
completely remove the type,
not just remove it from APIs. However, I think it's still better to
keep the name in the APIs and change
the meaning of the name. That's far from ideal, but it still provides
a better compatibility story than
eradicating the name from APIs, and we can still take reasonable steps
towards eventually eradicating
the name.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Thiago Macieira]

Em segunda-feira, 20 de março de 2017, às 10:51:49 PDT, Marc Mutz escreveu:
> Though it certainly broke a lot of Qt code and we're still recovering:
> 
>   5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer)
>   c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete)
> 
> it looks like every class that provides new-style connect syntax should be
> affected. Yes, we're to blame to not have centered this functionality in a
> qInvoke() template before, and maybe it's time to do that, but I certainly
> do not remember such a large SiC in C++ ever before. Well, in the last 17
> years.

Would not have been an issue if we were using std::function, though.

Then again, it might have been an issue if we *were* using std::function from 
a C++ standard library that did not update to noexcept with a C++ compiler 
that did (such as when using Clang on Linux with libstdc++). Since this error 
would have shown up in the user's code, we would have washed our hands and 
told the user "upgrade your C++ standard library, downgrade your compiler or 
stop using C++17".

-- 
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

[Marc Mutz]

On Monday 20 March 2017 16:10:53 Lars Knoll wrote:
> This means we have to be careful with any changes that could break large
> amounts of source code. So QList will have to exist as a type in Qt 6 with
> an API that is as source compatible to the one in Qt 5 as we can make it,
> while we need to still try to deprecate it for new code and offer better
> alternatives.

"Deprecate for new code"? What does that mean, exactly?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 15:38:28 Ville Voutilainen wrote:
> On 20 March 2017 at 16:19, Marc Mutz  wrote:
> >> And if I want to run the same code with Qt 5 and Qt 6? I don't want to
> >> modernize it,
> >> since that may change or break what it does on Qt 5, and I also don't
> >> want to modernize code
> >> as part of my build in a dynamic fashion, because that costs time and
> >> can cause version control problems. If we want Qt to be a library that
> >> caters to various different
> >> user scenarios, we should first stop assuming that one-way
> >> modernization tools are
> >> a realistic solution to compatibility problems.
> > 
> > That from someone that just broke an awful lot of lines of C++ code by
> > making noexcept be part of the function type :P
> 
> Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm
> not entirely convinced
> it broke "an awful lot of lines of code", and it indeed specifically
> did not and does not break very
> vast swaths of existing code, because *every* function call still
> behaves as they did before,
> although certain pointer conversions don't. It certainly doesn't
> produce a fear that
> it would break "the whole world".

I was just pulling your leg :)

Though it certainly broke a lot of Qt code and we're still recovering:

  5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer)
  c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete)

it looks like every class that provides new-style connect syntax should be 
affected. Yes, we're to blame to not have centered this functionality in a 
qInvoke() template before, and maybe it's time to do that, but I certainly do 
not remember such a large SiC in C++ ever before. Well, in the last 17 years.

> > Well, seriously. My answer is the same: Time has only one direction. Qt
> > source and binary compatibility only has one direction. If you want to
> > use Qt in a way it was not intended to be used, then you need to pay the
> > prize, and not ask the community to do so for you.
> > 
> > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt
> > 6. You can define your own MyQListOrQVector type alias. Or you can
> > #ifdef. It's up to you.
> 
> That's great, but before I have migrated all my code to any of those,
> it's simply better
> to change QList to be a QVector, fix the cases that require reference
> stability (which you're
> already doing in some places) to use a different type, deprecate
> direct uses of QList
> and *then* _eventually_ remove QList altogether, rather than doing it
> without any grace
> period.

When I said "Kill QList in Qt 6", I mean eradicate it from our APIs. The name, 
too. Whether the QList class lives on to support legacy code is a different 
question. As long as it's deprecated, and maybe moved to a Qt5Support module 
(that name will have raised some hairs now :), I'm fine with that.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

Hi other-Mark,

On Monday 20 March 2017 17:14:30 Mark Gaiser wrote:
> I'm fine with replacing QList usages with QVector in codebases i
> maintain, but even with the latest Qt version, that isn't always
> possible or convenient.
> For instance, at this very moment i want a QVector with all keys from
> a given map (QMap) but Qt itself doesn't provide a
> direct way of doing that.

What's a "direct way"? Don't assume there's a member function for everything 
you'd ever want to do with a container. Such folly has led to QList::toSet(), 
which, in turn has led to

   // needed for QList::toSet() to compile
   uint qHash(const QItemSelectionRange &, uint = 0) { return 0; }

> The keys method on the map returns a QList.
> QList has a "toVector" method which gives me the QVector i want.
> 
> It works, yes. But it's really indirect.

  template 
  QVector keys(const QHash ) {
  QVector result;
  result.reserve(hash.size());
  for (auto it = hash.begin(), end = hash.end(), it != end; ++it)
  result.append(it.key());
  return result;
  }
  // ... same for QMap ...
  template 
  QVector keys(const std::unordered_map ) {
  QVector result;
  result.reserve(hash.size());
  for (const auto  : hash)
  result.append(p.first);
  return result;
  }

You write these functions once, put them in your util.h, and are done with it. 
It's the same for STL: 
https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h

That file evolved through half a dozen projects.

> The key kinda has to be unique in a map (and hash) so it would be
> perfectly fine for it to be a QVector, but it isn't.
> Is there a technical reason for it or is it just because of Qt's history?

Just because of Qt's history of preferring QList for everything.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Frank Hemer]

On Monday 20 March 2017 16:40:07 Scott Aron Bloom wrote:
> -Original Message-
> From: Development
> [mailto:development-bounces+scott=towel42@qt-project.org] On Behalf Of
> Konrad Rosenbaum Sent: Monday, March 20, 2017 07:57
> To: development@qt-project.org
> Subject: Re: [Development] QList
> 
> On Mon, March 20, 2017 15:19, Marc Mutz wrote:
> > Well, seriously. My answer is the same: Time has only one direction.
> > Qt source and binary compatibility only has one direction. If you want
> > to use Qt in a way it was not intended to be used, then you need to
> > pay the prize, and not ask the community to do so for you.
> > 
> > You can pay by porting to QVector. Or auto. That will work in Qt 5 and
> > Qt 6.
> > You can define your own MyQListOrQVector type alias. Or you can #ifdef.
> > It's
> > up to you.
> 
> Marc, please do not underestimate the impact of laziness! Whether we admit
> it or not: most of us became computer scientists because we're lazy - we
> want to let the machine work for us! ;-)
> 
> Everybody else at least works for for someone who is quite tight-fisted with
> the budget.
> 
> In other words: if Qt 6 forces me to do any significant amount of porting,
> then I'll stay with Qt 5. I was able to port my biggest Qt 4 application to
> Qt 5 because I could promise my client it'd be done in a couple of days and
> he'd gain lots of features too.
> 
> If I have to replace every single occurrence of QList with QVector or auto
> for it to continue working with Qt 6, then I will not get a budget for
> that.
> 
> The community will pay for my laziness by having to support an outdated
> framework for much longer. Lazy people are great at externalizing... :-P
> ==
> +1
> 
> I had customers on Qt3 for 2 years after Qt4 came out for this reason alone,
> the cost of moving to Qt4 was too large for them to justify the expense.
> 
> When it came to 4 to 5, it was minimal, in fact none of my customers "held
> on to 4" because of the migration path, however, many simply waited for a
> reason.
> 
> Now, myself, and a few others are sitting on Qt 5.5 because of the issues
> with the web browser change in 5.6... but that's another issue

+1

And QtScript being the next 'another' issue on the horizon ...

Frank
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Mark Gaiser]

On Sat, Mar 18, 2017 at 10:51 AM, Marc Mutz  wrote:
> On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote:
>> There's been a fair amount of talk about QList's future, so I'm curious:
>>
>> 1) What are the problems with QList?
>
> See Konstantin's reply. For me, the performance issue is pretty strong
> already, but that stability of references into QLists may depend on such
> subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been
> called for the type is also a big correctness issue.
>
>> 2) What do we plan to do about those problems?
>
> Kill QList in Qt 6.
>
>> 3) How do we expect to migrate code that uses it?
>
> Possibly provide a QArrayList that _always_ uses the heap, and thus _always_
> provides stability of references. There's some code that actually depends on
> stability of references (QToolBox, e.g.).
>
> Try to minimize use in new code. That hasn't worked out as planned. Look at
> the dates of my two contributions Konstantin linked to, then look at the API
> reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar
> Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such
> things.
>
> This experience, over several years, has thaught me that we need a technical
> solution. And so we started to specialize QList as an empty class.
> So far, this is the only workable solution I have found, and believe me, I am
> very determined.
>
> I think we should do this for all new (non-polymorphic) classes.
>
> And since we now depend on enough C++11, replacing QList with QVector in
> generic code is trivial: either use auto, or when you can't, use
> QListOrVector, introduced here: https://codereview.qt-project.org/188858
>
> So, here's my proposal for a QList exit strategy:
>
> In Qt 5:
>
> 1. Replace QList in generic code by QListOrVector, tell users to hold QLists
>they get from Qt API only in type-deduced variables.
> 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I
>don't think toSet() should be either on QList nor QVector, because it
>creates nonsense like qHash(QItemSelectionRange) (please, please, look it
>up :)
> 3. Disable QList for all new QFoo value types (by specializing QList as
>an empty class).
> 4. Provide QArrayList for code that needs stability of references (stability
>statically checked in Qt 5, enforced in Qt 6).
>
> In Qt 6:
>
> 5. Replace all QList uses left with ... what ? QVector? std::vector?
>-> separate discussion
> 6. Kill QList or keep it as a deprecated class.
>
> Thanks,
> Marc

Hi Marc,

I'm fine with replacing QList usages with QVector in codebases i
maintain, but even with the latest Qt version, that isn't always
possible or convenient.
For instance, at this very moment i want a QVector with all keys from
a given map (QMap) but Qt itself doesn't provide a
direct way of doing that.

The keys method on the map returns a QList.
QList has a "toVector" method which gives me the QVector i want.

It works, yes. But it's really indirect.

The key kinda has to be unique in a map (and hash) so it would be
perfectly fine for it to be a QVector, but it isn't.
Is there a technical reason for it or is it just because of Qt's history?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Lars Knoll]

> On 20 Mar 2017, at 15:56, Konrad Rosenbaum  wrote:
> 
> On Mon, March 20, 2017 15:19, Marc Mutz wrote:
>> Well, seriously. My answer is the same: Time has only one direction. Qt
>> source
>> and binary compatibility only has one direction. If you want to use Qt in
>> a
>> way it was not intended to be used, then you need to pay the prize, and
>> not
>> ask the community to do so for you.
>> 
>> You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt
>> 6.
>> You can define your own MyQListOrQVector type alias. Or you can #ifdef.
>> It's
>> up to you.
> 
> Marc, please do not underestimate the impact of laziness! Whether we admit
> it or not: most of us became computer scientists because we're lazy - we
> want to let the machine work for us! ;-)
> 
> Everybody else at least works for for someone who is quite tight-fisted
> with the budget.
> 
> In other words: if Qt 6 forces me to do any significant amount of porting,
> then I'll stay with Qt 5. I was able to port my biggest Qt 4 application
> to Qt 5 because I could promise my client it'd be done in a couple of days
> and he'd gain lots of features too.
> 
> If I have to replace every single occurrence of QList with QVector or auto
> for it to continue working with Qt 6, then I will not get a budget for
> that.
> 
> The community will pay for my laziness by having to support an outdated
> framework for much longer. Lazy people are great at externalizing... :-P

I fully agree with you here Konrad. I've seen the pain our customers had to go 
through when moving from Qt 3 to Qt 4, and I do not want to repeat this. We 
need to make moving to Qt 6 as painless as possible for our users, otherwise 
we'll have many people stuck in 5.x for a very long time. And that's very 
costly for both us and our users.

This means we have to be careful with any changes that could break large 
amounts of source code. So QList will have to exist as a type in Qt 6 with an 
API that is as source compatible to the one in Qt 5 as we can make it, while we 
need to still try to deprecate it for new code and offer better alternatives.

We'll need to try it out, but so far making QList an alias to QVector sounds 
like the most likely approach we could take.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 14:52:36 Ville Voutilainen wrote:
> On 20 March 2017 at 15:52, Marc Mutz  wrote:
> > So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or
> > pay the normal price and port, possibly with an automated tool a la
> > clang- modermize.
> 
> And if I want to run the same code with Qt 5 and Qt 6? I don't want to
> modernize it,
> since that may change or break what it does on Qt 5, and I also don't
> want to modernize code
> as part of my build in a dynamic fashion, because that costs time and can
> cause version control problems. If we want Qt to be a library that caters
> to various different
> user scenarios, we should first stop assuming that one-way
> modernization tools are
> a realistic solution to compatibility problems.

That from someone that just broke an awful lot of lines of C++ code by making 
noexcept be part of the function type :P

Well, seriously. My answer is the same: Time has only one direction. Qt source 
and binary compatibility only has one direction. If you want to use Qt in a 
way it was not intended to be used, then you need to pay the prize, and not 
ask the community to do so for you.

You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt 6. 
You can define your own MyQListOrQVector type alias. Or you can #ifdef. It's 
up to you.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Philippe]

Concerning sizeof(QVector) == 8

Alone, this is of course neglictable in a process space. But this allows
to use QVector inexpensively as a member variable in objects that are
instantiated many thousands of times (and in scenarios when this member
is often unused).

Yes I am aware of the QVector internals. As an old DSP and real-time
graphics programmer, I came to know a lot about performances. I even
have my own vector classes.
This means, I also know when I can get relaxed on the performance matter,
and rather select convenience and readability.

And I thanks Qt (so far), to provide me that convenience.

Philippe

> > And when size matters, have this in mind:
> > 
> > sizeof(std::vector) == 32
> > sizeof(QVector) == 8
> > sizeof(QList) == 8
> 
> To provide a more helpful response than Marc's: I assume that you are
> aware that the Qt types just contain a pointer to a thing which contains
> the actual data (unlike std::vector), right?
> 
> That is, QVector is actually (snipped from source):
> template 
> class QVector
> {
> typedef QTypedArrayData Data;
> Data *d;
> }
> 
> Where QTypedArrayData is a QArrayData, which is:
> struct Q_CORE_EXPORT QArrayData
> {
> QtPrivate::RefCount ref;
> int size;
> uint alloc : 31;
> uint capacityReserved : 1;
> qptrdiff offset;
> }
> 
> If I'm adding it up right, this gives me a total cost of 32 bytes on my
> system. Although the real cost is actually higher I'd guess, due to the
> two being allocated in separate pieces (given that malloc usually has
> some kind of book-keeping overhead).
> 
> Robin
> 
> -- 
>   Robin Burchell
>   ro...@crimson.no
> ___
> 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

Re: [Development] QList

[Ville Voutilainen]

On 20 March 2017 at 15:52, Marc Mutz  wrote:
> So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or pay
> the normal price and port, possibly with an automated tool a la clang-
> modermize.


And if I want to run the same code with Qt 5 and Qt 6? I don't want to
modernize it,
since that may change or break what it does on Qt 5, and I also don't
want to modernize code
as part of my build in a dynamic fashion, because that costs time and can cause
version control problems. If we want Qt to be a library that caters to
various different
user scenarios, we should first stop assuming that one-way
modernization tools are
a realistic solution to compatibility problems.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 14:25:56 Martin Smith wrote:
> >It's not the application developer's task to avoid the death by a
> >thousands Qt
> >
> >paper cuts. It's Qt's job.
> 
> Ok, but I'm the customer, and I am always right. I want my application that
> uses QList to continue to run in Qt 6 with QList just like it did in Qt 5.
> If it speeds up or slows down or uses more memory or less, I don't care as
> long as it still passes my old requirements.
> 
> 
> What is your solution?

I have answered that question five years ago[1]:

If your interests are against the common good, you should pay the prize, not 
expect it to be communitised.

So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or pay 
the normal price and port, possibly with an automated tool a la clang-
modermize.

[1] https://marcmutz.wordpress.com/2011/09/20/c98-support-costs-extra/

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Martin Smith]

>It's not the application developer's task to avoid the death by a thousands Qt

>paper cuts. It's Qt's job.


Ok, but I'm the customer, and I am always right. I want my application that 
uses QList to continue to run in Qt 6 with QList just like it did in Qt 5. If 
it speeds up or slows down or uses more memory or less, I don't care as long as 
it still passes my old requirements.


What is your solution?


martin


From: Development  on 
behalf of Marc Mutz 
Sent: Monday, March 20, 2017 2:13:30 PM
To: development@qt-project.org
Subject: Re: [Development] QList

On Monday 20 March 2017 13:42:09 Martin Smith wrote:
> >Qt must have acceptable performance for end user applications to be able
> >to have acceptable performance at all - whether or not it is a priority
> >to those developers.
>
> I write an application that has two performance requirements:
>
> 1. It must complete execution in 1 minute.
>
> 2. It must not run out of memory.

Sorry for highjacking your mail, I know this is hardly related, but seeing
"application" here, I need to repeat the following:

We're talking about Qt here. Qt is not an application. Qt is a library.
Different users use it differently. You cannot predict what will be the
bottleneck for any given user, thus you have to optimise everything. We don't
have the man-power to optimise everything, so we must settle for _not
pessimising_ anything. But Qt in the past has pessimised way too much, be it
Q_FOREACH, QList, CoW, ... We need to stop pessimising the common
tasks to optimize uncommon ones.

If someone copies a std::vector with a million elements by value in a tight
loop, any profiler in the world will be able to pinpoint that hotspot, and the
developer is happy, because the fix is easy.

OTOH, no profiler in the world will ever pinpoint to the developer the
slowdown caused by using QVector or QList in normal usage patterns. As a
result of Qt's sloppiness, your application is 2x slower than it could be,
with no indication as to why. You need to have good luck and a very powerful
(and expensive) profiler to have a chance to find that QVector performs worse
than std::vector in general. Worse, you can't do anything about it, because
replacing one QVector with std::vector has neglible effect. With luck, if you
replaced all you'd get a 20% speedup (I'm totally making these numbers up),
which disqualifies this work for an application developer as having
deminishing return of investment.

It's not the application developer's task to avoid the death by a thousands Qt
paper cuts. It's Qt's job.

Our job.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
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

Re: [Development] QList

[Martin Smith]

>Qt must have acceptable performance for end user applications to be able to 
>have
>acceptable performance at all - whether or not it is a priority to those 
>developers.


I write an application that has two performance requirements:

1. It must complete execution in 1 minute.

2. It must not run out of memory.


If I use QList in my application instead of QVector, and it still passes both 
requirements tests, then whether QList is as bad as Marc says it is (I have no 
reason to doubt him) makes no difference.


If you replace QList with QVector and rename it QList and my application still 
passes both tests, then not only will I not complain, I won't know about it 
unless I reread the documentation.


So if we can make that guarantee, then let's just make the switch.


Aside: I'm from that bygone era long before Qt, when a "list" in computer 
programming always meant linked list. A sequence of contiguous data entries was 
an array. There were no exceptions. So even now, after using QList for more 
than a decade, I still forget that it's not a linked list.


martin


From: Development  on 
behalf of Robin Burchell 
Sent: Monday, March 20, 2017 1:13:23 PM
To: development@qt-project.org
Subject: Re: [Development] QList

Hi Philippe,

On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote:
> >>Even our API guidelines stipulate that you should make common things easy 
> >>and
> >>not-so-common things possible. Sharing is _not_ common and it need not be as
> >> easy as common tasks. I
>
> Maybe for you, but in my works, sharing _is_ common, convenient and safe.
> And overal usage of COW is one of the concept that makes Qt stand apart.
> From my POV, COW largely pay off its minimal performance cost.
> When performance is a high priority, _an uncommon case_, then using
> alternate containers is always possible and we don't need Qt for this.

I don't know your background, but let's assume you are primarily a user
of Qt (thus: an application developer of some kind), you may consider
performance to be unimportant, or important only in isolated areas of
your application.

Consider, however, the point of view from many of the people on this
list: as Qt uses itself in its own implementation, Qt must have
acceptable performance for end user applications to be able to have
acceptable performance at all - whether or not it is a priority to those
developers.

A few concrete examples of where data types matter a lot: signal
connections (involves storing a bunch of data), QObject (particularly
QObject::children, as already mentioned), event handling from the
operating system (or the application itself: the event posting mechanism
in QCoreApplication)...

> And when size matters, have this in mind:
>
> sizeof(std::vector) == 32
> sizeof(QVector) == 8
> sizeof(QList) == 8

To provide a more helpful response than Marc's: I assume that you are
aware that the Qt types just contain a pointer to a thing which contains
the actual data (unlike std::vector), right?

That is, QVector is actually (snipped from source):
template 
class QVector
{
typedef QTypedArrayData Data;
Data *d;
}

Where QTypedArrayData is a QArrayData, which is:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
int size;
uint alloc : 31;
uint capacityReserved : 1;
qptrdiff offset;
}

If I'm adding it up right, this gives me a total cost of 32 bytes on my
system. Although the real cost is actually higher I'd guess, due to the
two being allocated in separate pieces (given that malloc usually has
some kind of book-keeping overhead).

Robin

--
  Robin Burchell
  ro...@crimson.no
___
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

Re: [Development] QList

[Ville Voutilainen]

On 20 March 2017 at 14:13, Robin Burchell  wrote:
>> And when size matters, have this in mind:
>>
>> sizeof(std::vector) == 32
>> sizeof(QVector) == 8
>> sizeof(QList) == 8
>
> To provide a more helpful response than Marc's: I assume that you are
> aware that the Qt types just contain a pointer to a thing which contains
> the actual data (unlike std::vector), right?

libstdc++ vector is 24, it seems as if msvc's vector is just padded to
an alignment boundary(*). I don't
see anything particularly alarming in that size.

(*) it might be remotely possible that it fails to remove storage for
an empty allocator, but I kinda doubt that.

> That is, QVector is actually (snipped from source):
> template 
> class QVector
> {
> typedef QTypedArrayData Data;
> Data *d;
> }
>
> Where QTypedArrayData is a QArrayData, which is:
> struct Q_CORE_EXPORT QArrayData
> {
> QtPrivate::RefCount ref;
> int size;
> uint alloc : 31;
> uint capacityReserved : 1;
> qptrdiff offset;
> }
>
> If I'm adding it up right, this gives me a total cost of 32 bytes on my
> system. Although the real cost is actually higher I'd guess, due to the
> two being allocated in separate pieces (given that malloc usually has
> some kind of book-keeping overhead).


Yep.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Robin Burchell]

Hi Philippe,

On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote:
> >>Even our API guidelines stipulate that you should make common things easy 
> >>and 
> >>not-so-common things possible. Sharing is _not_ common and it need not be 
> >>as 
> >> easy as common tasks. I
> 
> Maybe for you, but in my works, sharing _is_ common, convenient and safe.
> And overal usage of COW is one of the concept that makes Qt stand apart.
> From my POV, COW largely pay off its minimal performance cost.
> When performance is a high priority, _an uncommon case_, then using
> alternate containers is always possible and we don't need Qt for this.

I don't know your background, but let's assume you are primarily a user
of Qt (thus: an application developer of some kind), you may consider
performance to be unimportant, or important only in isolated areas of
your application.

Consider, however, the point of view from many of the people on this
list: as Qt uses itself in its own implementation, Qt must have
acceptable performance for end user applications to be able to have
acceptable performance at all - whether or not it is a priority to those
developers.

A few concrete examples of where data types matter a lot: signal
connections (involves storing a bunch of data), QObject (particularly
QObject::children, as already mentioned), event handling from the
operating system (or the application itself: the event posting mechanism
in QCoreApplication)...

> And when size matters, have this in mind:
> 
> sizeof(std::vector) == 32
> sizeof(QVector) == 8
> sizeof(QList) == 8

To provide a more helpful response than Marc's: I assume that you are
aware that the Qt types just contain a pointer to a thing which contains
the actual data (unlike std::vector), right?

That is, QVector is actually (snipped from source):
template 
class QVector
{
typedef QTypedArrayData Data;
Data *d;
}

Where QTypedArrayData is a QArrayData, which is:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
int size;
uint alloc : 31;
uint capacityReserved : 1;
qptrdiff offset;
}

If I'm adding it up right, this gives me a total cost of 32 bytes on my
system. Although the real cost is actually higher I'd guess, due to the
two being allocated in separate pieces (given that malloc usually has
some kind of book-keeping overhead).

Robin

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Wishes for C++ standard or compilers

[Stottlemyer, Brett (B.S.)]

On 3/20/17, 7:02 AM, "Development on behalf of Olivier Goffart" 
 wrote:
>
>It's true that you cannot serialize a type if you don't have some 
> persistent 
>identifier such as the name.

This has probably been covered, but it may be worth mentioning.  The examples 
Konrad used were in-process.  Qt Remote Objects works between processes and 
between devices, so the id for registered (user) types becomes unreliable.  The 
id is determined by the order the types are registered, so the name is needed 
by Qt Remote Objects too.

Regards,
Brett
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Wishes for C++ standard or compilers

[Olivier Goffart]

On Montag, 20. März 2017 11:27:44 CET Konrad Rosenbaum wrote:
> Hi,
> 
> On Mon, March 20, 2017 08:20, Olivier Goffart wrote:
> > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
> >> The name is necessary for compatiblity iwth other languages.
> > 
> > Can you elaborate?
> > In QtScript or QtQml, the name is only used for error message, or for
> > compatibility before the QMetaObject was in the QMetaType.
> > Types that can be used directly needs to be registered with functions such
> > as
> > qmlRegisterMetaType
> > 
> > I see many use in QtDBus but I suppose if it falls in the category of
> > types
> > used for signals and slot which could be registered by moc.
> 
> There are more bindings than just QtScript and QML.
> 
> Any dynamic binding that does not want to force the user to register
> again(!) every single type that could possibly appear somewhere in the API
> needs to know the name. At least if it wants to be compatible with itself
> between versions and platforms. Type IDs can change in between versions of
> a program or even if only an underlying library is updated.
> 
> For example: I'm currently writing a utility that taps into a Qt program
> without modifying the program itself and allows to inspect objects and
> properties (something technically similar to GammaRay). In order to
> serialize and deserialize the properties of objects I need to be able to
> reliably determine the type of those properties on both sides and be able
> to reconstruct them, or at least to be able to determine whether I need to
> fall back to a string representation. For user types the name is much more
> reliable than the ID.
> 
> In other projects I've used the MetaType system to expose type names of
> data stored in a QVariant to Tcl based scripts, a formula parser with
> dynamic typing, a template rendering system, or debugger utilities.
> 
> The common theme among those was that I did not know what types my utility
> would face at the time I wrote the utility accessing QVariant. And those
> utilities usually work rather invisible to the libraries originating the
> types used in them and vice versa.
> 
> In short: being able to get both an ID and a name for a type stored in
> QVariant makes a lot of magic possible that would otherwise require major
> blobs of glue code or it would otherwise simply be so inconvenient to use
> that it wouldn't be worth bothering.

Yes you are right, the name is still nice to have for serialization.
For QObject properties, moc can (and already does for some types)  register 
the type name.

It's true that you cannot serialize a type if you don't have some persistent 
identifier such as the name.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Sunday, March 19, 2017 8:01 PM
> To: development@qt-project.org
> Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-
> 59586)?
> 
> The rules are that only Qt Company people can import 3rdparty code, so I
> know I am not responsible.

I don't think this is the case. Every contributor can upload patches with new 
third party code, as long as this is properly documented.

Only maintainers are allowed to approve them though, and if you want to add new 
third party code to the Qt libraries, tools or plugins you need an approval by 
Lars.

Not formally approved yet, but QUIP-4 explicitly states the rules:

https://codereview.qt-project.org/#/c/177201/

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 09:40:53 Lars Knoll wrote:
>  4. Provide QArrayList for code that needs stability of references
>  (stability
>  
>    statically checked in Qt 5, enforced in Qt 6).
> >>>
> >>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking
> >>> changes; to what extent, I would like to know.
> >
> > Actually, we can get started in (4) right now. This will allow porting
> > now.
> 
> That’s probably a good idea. It would help to have that class in 5.10 or
> latest 5.11.

https://codereview.qt-project.org/188938

I've made it a type-alias so we can rewrite code without breaking source or 
binary compatibility. It still checks that a QList so redeclared is actually 
one with an indirect memory layout.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Marc Mutz]

On Monday 20 March 2017 09:28:33 Philippe wrote:
> And when size matters, have this in mind:
> 
> sizeof(std::vector) == 32
> sizeof(QVector) == 8
> sizeof(QList) == 8
>
>  (VC++ 64bit)

ROTFL. Thanks, you made my day.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] applications dropping keyboard input

[René J . V . Bertin]

Hi,

I forgot to mention something that provide another reason why I think the shell 
itself cannot be the part that drops input: copy/paste still works. 

That is, I can use whatever subterfuge I want to put a terminal command on the 
clipboard; if I paste it into a "deaf" terminal window or tab and the command 
has a newline append it will be executed by the shell running in that window or 
tab. The same was true for the deaf KDevelop window: input from the clipboard 
still appeared. Of course I had to use the Paste menu action in both cases.


I did consider the possibility that something in the shell or the 
readline/libedit libraries it uses put a relevant component of the event 
handling loop in an unforeseen state, which also would explain why keyboard 
input doesn't even appear in the window (most of the time it does if the shell 
has simply "disconnected").
For a long time I thought that must be in Konsole. Except that I never found 
anything in its event handling code that seemed like it could explain my 
symptom.

As you know I also have a functional XCB QPA plugin on my Mac and have actually 
been using Konsole 5 under X11 as my main terminal emulator for months now. 
Works really nicely. Of course that XCB QPA plugin is used with a Qt install 
otherwise built for Cocoa, and basically all KF5 software is built that way too 
so binaries lack all X11 specific code not provided by the QPA (or the 
KWindowSystem framework).

R.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Lars Knoll]

> On 18 Mar 2017, at 19:15, Thiago Macieira  wrote:
> 
> Em sábado, 18 de março de 2017, às 10:37:15 PDT, Marc Mutz escreveu:
>> Ville,
>> 
>> A word of warning: when it comes to QList, there's a very vocal minority
>> that claims that either QList works perfectly well or else ain't so bad.
>> But afaict, there's consensus between the people who actually count (sorry
>> to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is
>> currently was a mistake and needs to go in Qt 6. The only difference in
>> opinion is how to cushion the fall.
>> 
>> Lars, Thiago: it would be nice if you could confirm (or deny, in case I
>> misinterpreted) the above as soon as you can. Otherwise this thread will
>> derail massively again.
> 
> I think we're in agreement.

Yes, we agree that QList as it is today is nothing we want in Qt 6. But we 
can’t simply remove it neither, as it would break way too much user code out 
there.
> 
> During Qt 5 development, I began the process of rewriting QList so it 
> suffered 
> less from the problems it suffers, but I ran out of time and it was also an 
> impossible task given the requirement to support C++98 at the time (no 
> ). The objective was to make QList a hybrid: a real vector with 
> no overhead for types smaller than 32 bytes, a pointer list otherwise.
> 
> But as time went by, I don't think that hybrid approach is valid. A vector is 
> simply much better. For Qt 6, I'd like QVector and QList to be the same type 
> -- possibly even interchangeable, so that code that began using QVector in 
> Qt 5 will be able to "return" QList.

+1 on this. They are pretty much API compatible, so this should be rather 
straightforward. 

This does cause a change in runtime behaviour for people storing very large 
objects in the container that we will need to document carefully. But it will 
IMO work very nicely for 95% of it’s uses, and even give some performance 
benefits in those cases.
> 
>>> In other words, introduce generic code where there wasn't generic code
>>> before - users writing
>>> non-generic code calling non-templates that return QLists will need to
>>> use deduction or a metaprogramming tool.
>> 
>> 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".
> 
> I don't agree with the poisoning. See my comment in the QStringView review. I 
> agree we should teach users to port away from QList, but not hat it's such a 
> terrible class that they have to port right now, before using new 
> functionality. 

Agree with Thiago. If we do turn QList into QVector, there is IMO no need to 
poison things right now. Simply replacing all our uses for Qt 6 and maybe 
deprecating QList then should be enough.
> 
 4. Provide QArrayList for code that needs stability of references
 (stability
 
   statically checked in Qt 5, enforced in Qt 6).
>>> 
>>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking
>>> changes; to what extent, I would like to know.
> 
> Actually, we can get started in (4) right now. This will allow porting now.

That’s probably a good idea. It would help to have that class in 5.10 or latest 
5.11.
> 
>> (2) is possibly breaking, yes. We should intercept by deprecating
>> QList::toSet() and re-adding it as a free function.
> 
> Isn't that simply std::copy?
> 
>> (3) is breaking nothing for existing code, since it only applies to new
>> types. New types don't magically show up in your source code. You have to
>> introduce them yourself. As for existing generic code, it's a
>> source-incompatibility that is accepted, because it can be fixed by using
>> auto variables. Or you don't use the new type at all. I mean, we're not
>> talking about QString here. With very few exceptions, any type we're adding
>> now will not get widespread use before Qt 6, anyway. One exception
>> hopefully being QStringView.
> 
> It's abou the message it brings. Doing that is telling people to port right 
> away, not when they have the time to do it properly.
> 
>> Indeed, if it was easy, it would have been done long ago. But it's
>> nonetheless absolutely necessary. Q6String will not fit into a QList
>> anymore. QVariant and QModelIndex already don't. And given the extensive
>> use of QVariant in QML/Qt's property system, I don't think anyone can be
>> happy about the per-element memory allocation in QVariantList.
> 
> Aye.

Yep, we all agree on this :)

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Philippe]

>>Even our API guidelines stipulate that you should make common things easy and 
>>not-so-common things possible. Sharing is _not_ common and it need not be as 
>> easy as common tasks. I

Maybe for you, but in my works, sharing _is_ common, convenient and safe.
And overal usage of COW is one of the concept that makes Qt stand apart.
>From my POV, COW largely pay off its minimal performance cost.
When performance is a high priority, _an uncommon case_, then using
alternate containers is always possible and we don't need Qt for this.

And when size matters, have this in mind:

sizeof(std::vector) == 32
sizeof(QVector) == 8
sizeof(QList) == 8

 (VC++ 64bit)

Philippe

On Mon, 20 Mar 2017 09:09:57 +0100
Marc Mutz  wrote:

> On Sunday 19 March 2017 19:48:36 Thiago Macieira wrote:
> > On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote:
> > > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote:
> > > > QVector someFunction()  // out-of-line
> > > > {
> > > > 
> > > > QtExclusive::QVector vector;
> > > > [ operate and populate vector ]
> > > > return vector;  // automatic move
> > > > 
> > > > }
> > > > 
> > > > in user code:
> > > > QtExclusive::QVector vector = someFunction();   //
> > > > 
> > > > automatic move [ mutate some more ]
> > > 
> > > Breaks (N)RVO.
> > 
> > How?
> 
> Returned Type != (Declared) Return Type != Expected Type (by caller)
> 
> For NRVO, all three must be identical, for RVO the last two.
> 
> > > And since the code outside has no clue about whether the code inside the
> > > function creates a shared or unshared QVector, the compiler will again
> > > have to emit the whole QVector copy constructor/detach code (as dead
> > > code) at the call site. You promised this would be gone in Qt 6 because
> > > of the removal of the unsharable state.
> > 
> > QtExclusive::QVector's move constructor for QVector always needs to emit
> > copying code, since it doesn't know whether the data is shared or not.
> > There's no way around that.
> >
> > QVector's move constructor for QtExclusive::QVector simply adopts the data
> > and starts reference-counting.
> 
> Sure, I understand that. It's the misuse of QVector when exclusive QVector 
> was 
> needed that is the problem:
> 
> > You could argue that a function that always returns an unshared vector
> > could return QtExclusive::QVector.
> 
> Exactly that.
> 
> > But we should not allow that in our API
> > any more that we allow returning references.
> 
> Yes, that was my fear.
> 
> The exclusive split sounded like a good idea, like unique_ptr vs. shared_ptr, 
> one that could actually win me over to support keeping any form of Qt 
> container at all, long-term. Until right now.
> 
> If you would propose to make QVector exclusive, maybe with SOO, and provide 
> QSharedVector, but to default to QVector in API, you would probably have me 
> on 
> board.
> 
> It's a fallacy to think that there's a lot of need to return a shared 
> collection from APIs. Either you create the collection on request, then an 
> exclusive collection would be preferable, as returning it from a function is 
> free[1], or you "return" internal state, in which case returning some form of 
> view (incl. the case of simply adding begin()/end()) would be the way to go 
> (cf. https://codereview.qt-project.org/150658).
> 
> Even if your pov is that you should always return an owning collection in 
> these cases, and that it therefore has to be a shared one, existing Qt code 
> (QObject::children()) shows that even CoW is too slow in these cases 
> (children() returns by const-&). If QObject was iterable as a container of 
> QObject*, that would both be more convenient as well as faster).
> 
> [1] yes, _is_. Ville may correct me if I'm wrong, but afaiu, C++17 makes
>  (N)RVO mandatory. Sorry, GCC, you'll have to finally do something about your
>  broken NRVO.
> 
> > > > Why not std::vector? Because of the ability to put it back into shared
> > > > mode,
> > > 
> > > std::shared_ptr
> > 
> > One level of indirection too many. We've been over this.
> 
> iow: you'd rather pay some large overhead every time than pay a larger one 
> only in cases where it's needed. And this is where we fundamentally disagree.
> 
> Even our API guidelines stipulate that you should make common things easy and 
> not-so-common things possible. Sharing is _not_ common and it need not be as 
> easy as common tasks. Iteration, builing a container from scratch, returning 
> by NRVO from a function, these are common things. And CoW pessimises such 
> common things - not only performance-wise, but also conceptually: std::vector 
> doesn't need qAsConst when used with ranged for loops, std::vector doesn't 
> invalidate iterators when copied from...
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL 

Re: [Development] QList

[Marc Mutz]

On Sunday 19 March 2017 19:48:36 Thiago Macieira wrote:
> On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote:
> > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote:
> > > QVector someFunction()  // out-of-line
> > > {
> > > 
> > > QtExclusive::QVector vector;
> > > [ operate and populate vector ]
> > > return vector;  // automatic move
> > > 
> > > }
> > > 
> > > in user code:
> > > QtExclusive::QVector vector = someFunction();   //
> > > 
> > > automatic move [ mutate some more ]
> > 
> > Breaks (N)RVO.
> 
> How?

Returned Type != (Declared) Return Type != Expected Type (by caller)

For NRVO, all three must be identical, for RVO the last two.

> > And since the code outside has no clue about whether the code inside the
> > function creates a shared or unshared QVector, the compiler will again
> > have to emit the whole QVector copy constructor/detach code (as dead
> > code) at the call site. You promised this would be gone in Qt 6 because
> > of the removal of the unsharable state.
> 
> QtExclusive::QVector's move constructor for QVector always needs to emit
> copying code, since it doesn't know whether the data is shared or not.
> There's no way around that.
>
> QVector's move constructor for QtExclusive::QVector simply adopts the data
> and starts reference-counting.

Sure, I understand that. It's the misuse of QVector when exclusive QVector was 
needed that is the problem:

> You could argue that a function that always returns an unshared vector
> could return QtExclusive::QVector.

Exactly that.

> But we should not allow that in our API
> any more that we allow returning references.

Yes, that was my fear.

The exclusive split sounded like a good idea, like unique_ptr vs. shared_ptr, 
one that could actually win me over to support keeping any form of Qt 
container at all, long-term. Until right now.

If you would propose to make QVector exclusive, maybe with SOO, and provide 
QSharedVector, but to default to QVector in API, you would probably have me on 
board.

It's a fallacy to think that there's a lot of need to return a shared 
collection from APIs. Either you create the collection on request, then an 
exclusive collection would be preferable, as returning it from a function is 
free[1], or you "return" internal state, in which case returning some form of 
view (incl. the case of simply adding begin()/end()) would be the way to go 
(cf. https://codereview.qt-project.org/150658).

Even if your pov is that you should always return an owning collection in 
these cases, and that it therefore has to be a shared one, existing Qt code 
(QObject::children()) shows that even CoW is too slow in these cases 
(children() returns by const-&). If QObject was iterable as a container of 
QObject*, that would both be more convenient as well as faster).

[1] yes, _is_. Ville may correct me if I'm wrong, but afaiu, C++17 makes
 (N)RVO mandatory. Sorry, GCC, you'll have to finally do something about your
 broken NRVO.

> > > Why not std::vector? Because of the ability to put it back into shared
> > > mode,
> > 
> > std::shared_ptr
> 
> One level of indirection too many. We've been over this.

iow: you'd rather pay some large overhead every time than pay a larger one 
only in cases where it's needed. And this is where we fundamentally disagree.

Even our API guidelines stipulate that you should make common things easy and 
not-so-common things possible. Sharing is _not_ common and it need not be as 
easy as common tasks. Iteration, builing a container from scratch, returning 
by NRVO from a function, these are common things. And CoW pessimises such 
common things - not only performance-wise, but also conceptually: std::vector 
doesn't need qAsConst when used with ranged for loops, std::vector doesn't 
invalidate iterators when copied from...

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Wishes for C++ standard or compilers

[Olivier Goffart]

On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
> On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote:
> > But because QMetaType was historically made for QueuedConnection, it needs
> > the name, and so needs to be declared or registered with
> > Q_DECLARE_METATYPE/ qRegisterMetaType.  But the truth is that we could get
> > rid of both already with what C++98. moc could generate the code that
> > register the name for the signal arguments (it already does for some type,
> > but that could be extended to all types).  QMetaTypeid::name() would not
> > work for every type but that's not so important.
> 
> The name is necessary for compatiblity iwth other languages.

Can you elaborate?
In QtScript or QtQml, the name is only used for error message, or for 
compatibility before the QMetaObject was in the QMetaType.
Types that can be used directly needs to be registered with functions such as 
qmlRegisterMetaType 

I see many use in QtDBus but I suppose if it falls in the category of types 
used for signals and slot which could be registered by moc.

-- 
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