Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
(Adding back the mailing list)
Den lör 20 okt. 2018 kl 23:54 skrev Elvis Stansvik :
>
> Den lör 20 okt. 2018 kl 23:50 skrev Giuseppe D'Angelo
> :
> >
> > Il 20/10/18 19:37, Elvis Stansvik ha scritto:
> > > If the C++ wizards considered this but were hesitant, then I think
> > > it's right that Qt is hesitant as well. I hadn't really considered
> > > potential life-time issues, so I guess what we're doing might possibly
> > > be unsafe (?).
> >
> > Probably in the sense that the function you pasted can be applied like this:
> >
> > QVector v;
> > for (auto : qMoveAsConst(v)) ~~~; // compiles with an lvalue!
> > use(v); // unspecified behavior
>
> Ah yes, it may be that the standards folks simply didn't want this
> because of foot-shooting potential like this.
Another potential foot-shooter I found on an SO question
(https://stackoverflow.com/a/39051612/252857):
for (auto const & : as_const(getQString())) // whoops!
{
}
Elvis
>
> >
> >
> > > What's GCE? Some optimization? (Google "c++ gce" didn't give me anything).
> >
> > Guaranteed Copy Elision:
> >
> > > https://en.cppreference.com/w/cpp/language/copy_elision
>
> Thanks!
>
> 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
Re: [Development] Coin production update: Import note for users of testresults
Thank you Aapo! Simon > On 20. Oct 2018, at 12:45, Aapo Keskimölö wrote: > > It seems that some users will want to keep the old task links working so we > have decided to cancel this production update and do a new one after the > backwards compatibility is in place. > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö > >> On 19 Oct 2018, at 14.02, Aapo Keskimölö wrote: >> >> To all our Developers, >> >> Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST >> 2018. See attached change log for related patches. >> >> IMPORTANT NOTES: >> - This update will contain changes in our CI storage meaning that we will >> need to rebuild all cached binaries. I will take the service offline while >> artifacts are being re-create and restore the service after most of them >> have been finished. >> - The integrations in testresults coin page will look somewhat strange after >> this change since we are moving to a new era of building products in Coin >> and we have decided to decouple platform related code from our Coin source >> code base and legacy support will not be provided. The log links posted in >> gerrit should continue working as before. If you REALLY need to have the >> integration workitems display fixed, please, reply to this email and I will >> reconsider providing legacy support. The commit resulting in this behavior >> is a4280c7f61822a336f88bcec91c571bcebd94e97. >> >> Have a great weekend, >> Aapo Keskimölö >> > ___ > 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] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development
:
>
> Il 20/10/18 14:43, Elvis Stansvik ha scritto:
> > In our application we added a helper like
> >
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
> >
> > that we use for these cases. It just moves the argument to a const
> > value and returns it. With that we can do for (auto foo :
> > moveToConst(returnsQtContainer()) { ... }.
> >
> > Since it's such a common pattern to want to iterate a returned Qt
> > container, what would you think of having such a helper
> > (qMoveToConst?) in Qt?
>
> Possibly... Note however that such a thing was already proposed for
> qAsConst itself, and shut down to avoid having qAsConst diverge from
> std::as_const (and I approve of not having Qt-specific behaviours). I
> can't find the relevant discussion on the mailing list right now.
>
>
> For reference, std::as_const's original authors had doubts about the
> lifetime issues around this, saying that more investigations were needed:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
>
>
> After a LEWG meeting it was reworded like this:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
>
>
> I'm not entirely sure of what prompted the change for as_const -- if
> just a safety net while waiting for more investigation, or if something
> more profound was raised.
>
>
> I can easily imagine however a scenario where moveToConst() can lead to
> worse code than the current solution.
>
> Current solution:
>
> // GCE may get applied, 0 moves
> const QVector v = getVector();
> for (auto : v) ~~~
>
> vs.
>
> // Always 2 moves
> for (auto : qMoveToConst(getVector()) ~~~
>
>
> And if the type is not even cheap to move (e.g. QVLA, std::array),
> qMoveToConst becomes a really unpleasant surprise.
>
> How about asking LEWG about their reasoning too?
>
Thanks a lot for the pointers and back story Giuseppe. I definitely
think it's good that qAsConst mirrors what std::as_const did, so
wouldn't want it expanded.
If the C++ wizards considered this but were hesitant, then I think
it's right that Qt is hesitant as well. I hadn't really considered
potential life-time issues, so I guess what we're doing might possibly
be unsafe (?).
What's GCE? Some optimization? (Google "c++ gce" didn't give me anything).
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
Re: [Development] Coin go version has been updated
I’m also interested in what you thought had fixed the issues, as they clearly state they remove the compatibility with the old distros? And what features do we need from the new go-lang versions? -T From: Development On Behalf Of Aapo Keskimölö Sent: lauantai 20. lokakuuta 2018 15.37 To: development@qt-project.org Cc: Coin Team Subject: Re: [Development] Coin go version has been updated It seems that the mac machines are still having the same issue with this go version:/ I have reverted the go version coin master back to 1.8.3. Kind regards/Ystävällisin terveisin, Aapo Keskimölö On 20 Oct 2018, at 13.51, Aapo Keskimölö mailto:aapo.keskim...@qt.io>> wrote: Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö ___ 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?
Il 20/10/18 14:43, Elvis Stansvik ha scritto:
In our application we added a helper like
template
const T moveToConst(T &)
{
return std::move(t);
}
that we use for these cases. It just moves the argument to a const
value and returns it. With that we can do for (auto foo :
moveToConst(returnsQtContainer()) { ... }.
Since it's such a common pattern to want to iterate a returned Qt
container, what would you think of having such a helper
(qMoveToConst?) in Qt?
Possibly... Note however that such a thing was already proposed for
qAsConst itself, and shut down to avoid having qAsConst diverge from
std::as_const (and I approve of not having Qt-specific behaviours). I
can't find the relevant discussion on the mailing list right now.
For reference, std::as_const's original authors had doubts about the
lifetime issues around this, saying that more investigations were needed:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
After a LEWG meeting it was reworded like this:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
I'm not entirely sure of what prompted the change for as_const -- if
just a safety net while waiting for more investigation, or if something
more profound was raised.
I can easily imagine however a scenario where moveToConst() can lead to
worse code than the current solution.
Current solution:
// GCE may get applied, 0 moves
const QVector v = getVector();
for (auto : v) ~~~
vs.
// Always 2 moves
for (auto : qMoveToConst(getVector()) ~~~
And if the type is not even cheap to move (e.g. QVLA, std::array),
qMoveToConst becomes a really unpleasant surprise.
How about asking LEWG about their reasoning too?
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
[Development] qMoveToConst helper for rvalue references to movable Qt containers?
Hi all (first post),
In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
who are not on C++17 yet, which is convenient for iterating over Qt
containers using range-based for loops without causing a detach.
For good reasons there's no version of qAsConst that takes an rvalue
reference, so you can't do e.g. for (auto foo :
qAsConst(returnsQtContainer()) { ... }. Instead you must do const
auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
In our application we added a helper like
template
const T moveToConst(T &)
{
return std::move(t);
}
that we use for these cases. It just moves the argument to a const
value and returns it. With that we can do for (auto foo :
moveToConst(returnsQtContainer()) { ... }.
Since it's such a common pattern to want to iterate a returned Qt
container, what would you think of having such a helper
(qMoveToConst?) in Qt?
Cheers,
Elvis
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coin go version has been updated
It seems that the mac machines are still having the same issue with this go version:/ I have reverted the go version coin master back to 1.8.3. Kind regards/Ystävällisin terveisin, Aapo Keskimölö On 20 Oct 2018, at 13.51, Aapo Keskimölö mailto:aapo.keskim...@qt.io>> wrote: Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Coin go version has been updated
Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coin production update: Import note for users of testresults
It seems that some users will want to keep the old task links working so we have decided to cancel this production update and do a new one after the backwards compatibility is in place. Kind regards/Ystävällisin terveisin, Aapo Keskimölö > On 19 Oct 2018, at 14.02, Aapo Keskimölö wrote: > > To all our Developers, > > Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST > 2018. See attached change log for related patches. > > IMPORTANT NOTES: > - This update will contain changes in our CI storage meaning that we will > need to rebuild all cached binaries. I will take the service offline while > artifacts are being re-create and restore the service after most of them have > been finished. > - The integrations in testresults coin page will look somewhat strange after > this change since we are moving to a new era of building products in Coin and > we have decided to decouple platform related code from our Coin source code > base and legacy support will not be provided. The log links posted in gerrit > should continue working as before. If you REALLY need to have the integration > workitems display fixed, please, reply to this email and I will reconsider > providing legacy support. The commit resulting in this behavior is > a4280c7f61822a336f88bcec91c571bcebd94e97. > > Have a great weekend, > Aapo Keskimölö > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
