Marc Mutz wrote:
> My porting guide for Q_FOREACH -> C++11 ranged for has created the
> expected outcry from users.
Well, at least I object to deprecating Q_FOREACH to begin with, even if you
don't remove it. It's just the safer (no risk of accidental detaches, as
long as you use Qt containers)
On Wed, Aug 31, 2016 at 09:38:03PM +0200, Marc Mutz wrote:
> Hi André,
>
> On Wednesday 31 August 2016 21:04:27 André Pönitz wrote:
> > They are not completely independent, but a 'Q_FOREACH' ban in Qt
> > proper does not have to imply its removal for users. If it is
> > not useful in your view, yo
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 wrote:
>
> Th
Hi André,
On Wednesday 31 August 2016 21:04:27 André Pönitz wrote:
> They are not completely independent, but a 'Q_FOREACH' ban in Qt
> proper does not have to imply its removal for users. If it is
> not useful in your view, you can mention it in the docs. Breaking
> formerly compilable code for n
On Wednesday 31 August 2016 21:38:03 Marc Mutz wrote:
> So this proposal is for a way to lift that fear, so people who don't want
> to don't feel that they need to enable -Wdeprecated, turning it into its
> former meaning: API we have deprecated, not removed.
>From OALD:
deprecate something (f
On Wed, Aug 31, 2016 at 09:38:21AM +0200, Marc Mutz wrote:
> My porting guide for Q_FOREACH -> C++11 ranged for has created the expected
> outcry from users.
Expectedly so.
And since you seem to be surprised: There are a few people that
have just given up on commenting each and every mailing lis
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
Hi Andre,
On Wednesday 31 August 2016 10:04:55 André Somers wrote:
> While I understand the idea, I think it is very risky. I think it will
> be hard to explain to users, and even harder to defend against
> complaints and negative sentiments from users when the functionality
> _does_ break. Not ma
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)
Philippe
On Wed, 31 Aug 20
Op 31/08/2016 om 09:38 schreef Marc Mutz:
Hi,
My porting guide for Q_FOREACH -> C++11 ranged for has created the expected
outcry from users.
I think some of the FUD comes from the fact that deprecation in 5.x usually
means that the API is gone in Qt 6.0.
I'd therefore like to propose a new c
Hi,
My porting guide for Q_FOREACH -> C++11 ranged for has created the expected
outcry from users.
I think some of the FUD comes from the fact that deprecation in 5.x usually
means that the API is gone in Qt 6.0.
I'd therefore like to propose a new contract with our users:
The Qt Project:
- c
11 matches
Mail list logo
