Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Hi, Il 22/10/18 21:40, André Pönitz ha scritto: Which just shows it's working as intended. I have (a) no example that triggers obviously bad behaviour and (b) a bad gut feeling nevertheless. What bad behaviour are we referring to here? The problem is that a 'move' could be a 'swap' in practice, with the to-be-destroyed object held 'for a while', effectively turning C++'s rather deterministic destruction behaviour into something resembling garbage collection. I wouldn't be surprised if one can cause real problems with 'random' destruction orders on non-memory resources, like files. Simple memory might be safe(r), as releasing order does typically not matter. Oh, it absolutely does. That's why in Qt we implement move assignment in terms of pure swap if and only if the only resource that a container holds is memory (e.g. QString, QByteArray). For all other cases (e.g. QVector) we implement move assignment as move-and-swap, to be sure that resources are deterministically destroyed when the move happens. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On Sun, Oct 21, 2018 at 04:15:58PM +0200, Elvis Stansvik wrote: > In order to try out the unsafe usage you suggested in your other mail, > and also another unsafe usage pointed out in an SO question > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > I made the following test program. > > The output when running is: > > [estan@newton move-to-const-test]$ ./move-to-const-test > without moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627200 > Foo begin 0x7fffdb627200 > Foo end 0x7fffdb627200 > Foo destr 0x7fffdb627200 > FooPrivate destr > > with moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627208 > Foo move constr 0x7fffdb627210 > Foo destr 0x7fffdb627208 > Foo begin const 0x7fffdb627210 > Foo end const 0x7fffdb627210 > Foo destr 0x7fffdb627210 > FooPrivate destr > [estan@newton move-to-const-test]$ > > Which just shows it's working as intended. I have (a) no example that triggers obviously bad behaviour and (b) a bad gut feeling nevertheless. The problem is that a 'move' could be a 'swap' in practice, with the to-be-destroyed object held 'for a while', effectively turning C++'s rather deterministic destruction behaviour into something resembling garbage collection. I wouldn't be surprised if one can cause real problems with 'random' destruction orders on non-memory resources, like files. Simple memory might be safe(r), as releasing order does typically not matter. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-inlining members allowed?
On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: >>> one more question - is it ok to un-inline a function? For example I >>> want to move QListWidgetItem::isSelected() to the cpp file so I can >>> properly mark QListWidget::isItemSelected() as deprecated but I'm >>> unsure if this is allowed. Please be sure to summarise the change in a [ChangeLog][Potentially Source-Incompatible Changes] in your commit message; see [QUIP 6] * [QUIP 6] https://quips-qt-io.herokuapp.com/quip-0006.html Thiago Macieira (21 October 2018 22:12) replied: >> De-inlining is binary and source compatible, so long as you accept >> that the old code that did inline the function continues to do what it >> used o do. and (independently) Allan Sandfeld Jensen (22 October 2018 09:55) replied: > That should work, though it seems unnecessary. In any case you will > need to disable the warnings around the code using the deprecated API. This appears to be an instance of [QUIP 6]'s Examples section saying: Issues not listed here should be discussed on the mailing-list and then added here. Unless someone else (e.g. Allan or Thiago) beats me to it (I'm busy with a 3rd-party review ...), I guess I'll try to summarise the above as another example; apparently this is in Category A. If someone else gets there first, please add me as a reviewer, so I know when to update the published version. (hmm ... I think an update may be in order anyway.) Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecated functions / procedure of removal in Qt6?
Il 22/10/18 07:05, Christian Ehrlicher ha scritto: Ok, I'll go on with adding Q_DECL_DEPRECATED + QT_VERSION < QT_VERSION_CHECK(6, 0, 0) in the places where only the documentation states that this function is deprecated then. Otherwise they might get forgotten again :) Q_DEPRECATED_SINCE should be enough in this case -- as in Qt 6 we can just bump it to "5.99" and kill all the deprecated code in one go, effectively achieving the same thing one does with QT_VERSION_CHECK. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-inlining members allowed?
On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: > Hi, > > one more question - is it ok to un-inline a function? For example I want > to move QListWidgetItem::isSelected() to the cpp file so I can properly > mark QListWidget::isItemSelected() as deprecated but I'm unsure if this > is allowed. > That should work, though it seems unnecessary. In any case you will need to disable the warnings around the code using the deprecated API. 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecated functions / procedure of removal in Qt6?
Den mån 22 okt. 2018 kl 00:14 skrev Giuseppe D'Angelo via Development
:
>
> Hi,
>
> Il 21/10/18 19:59, Christian Ehrlicher ha scritto:
> > there are a lot of deprecated functions in qtbase which are only marked
> > as deprecated/obsolete in the documentation but don't have a
> > Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era.
> > What's the 'correct' way to make sure they can be removed with Qt6? Must
> > they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the
> > documentation enough?
>
> The documentation comment is enough for us to justify the removal -- in
> other words, "formally", we have informed the user to move away, and the
> rule is that we can drop deprecated functions any time we want to break
> source compatibility.
>
>
> However, it's nowhere enough to
>
> 1) make users _aware_ of the fact that they're using deprecated APIs;
> 2) make us _remember_ to remove those functions when we have the chance
> (like in Qt 6).
>
> Thus, adding deprecation warnings is definitely the right thing to do:
> users get the deprecation warnings (*), and we have an easy way to find
> and drop all those functions.
>
> The other ways to achieve 2) at the moment are:
>
> * If possible, all the code to be killed in Qt 6 should already be
> protected via
>
> > #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
>
>
> * Add some comment in the source code like
>
> // ### Qt 6: remove this
>
>
> Both ways are more general and apply to functions we can't just
> deprecate or remove (f.i., marking an overload to be merged with another
> one via a default argument, getting rid of useless special member
> function declarations, and the like).
>
> Of course, simply leaving a comment requires us to remember find those
> usages and act on those, and the code is still full of such TODOs for Qt
> 5...
>
>
> (*) I don't like that the deprecation warnings are opt-in and not
> opt-out. People deserve to know as soon as possible that they're using
> deprecated functionality, rather than have a gigantic unpleasant
> surprise ("you're using lots of deprecated stuff that got removed!")
> when Qt 6 comes.
+1 for opt-out from a user.
I had forgotten to add this to the build of our application. Will be
interesting to see what it'll turn up :p
Elvis
>
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> 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
