[Development] On deprecated APIs

[Diego Iastrubni]

Maybe the wording is wrong... how about "not recommended" instead of
"deprecated"?

I would also like to have an option to be able to compile a "qforeach"
block without the compiler spitting at me (/me takes off the java developer
hat).

On Wed, Aug 31, 2016 at 12:27 PM, Ulf Hermann <ulf.hermann at qt.io> wrote:

>
> This is a debate convenience vs performance;
>>
>> * Q_FOREACH will never detach, hence it is convenient.
>> * A for-loop can be (a very little more) optimized, as long as you work
>> on const containers or use qAsCont (and many will forget about that...
>> which
>> is *not* convenient)
>>
>
> ... especially as there is no qAsConst() for containers returned from
> functions. Those have to be saved in a local variable first, which makes
> the code not only less convenient but also uglier.
>
> I understand that we should teach people to avoid premature pessimzation,
> but at some point the pessimization might not actually be premature
> anymore. Q_FOREACH always makes a copy. This means you cannot mess up the
> logic if you change the code to modify the container in the loop body. You
> might actively decide to take a small performance hit for the convenience
> of not having to take care of this every time you change a loop body.
>
> The rules on when a Q_FOREACH detaches an implicitly shared container are
> also comparably simple. If you take a non-const reference as "iterator",
> then it detaches. If the reference is const or if you iterate by value, it
> won't detach. The rules in the "ranged for" case are more complicated and
> the user might actively trade a small performance hit for the ability to
> see the detaching behavior on first glance.
>
> Those are valid tradeoffs to be considered by the users and we should not
> impose either solution on them. So, I think there is still a place for
> Q_FOREACH in user code and we should not deprecate it in the first place. I
> agree that it's a good idea not to use it in Qt code.
>
> regards,
> Ulf
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160901/a5be550f/attachment.html>