[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Mathias Hasselmann mathias at taschenorakel.de
Fri Feb 20 00:17:00 CET 2015

Am 19.02.2015 um 20:47 schrieb Matthew Woehlke:
> On 2015-02-19 14:28, Thiago Macieira wrote:
>> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>>> That on a non-const shared container
>>> for (auto i : container)
>>> will detach it. That's why having rules instead of saying "just use
>>> it", I guess...
>> And who says it's not what you wanted?
>> for (auto &i : container) {
>> 	if (i.startsWith("foo"))
>> 		i = bar;
>> }
> Correct me if I'm wrong, but:
>    auto c = expensive();
>    // assume 'c' is shared and a deep copy of c would be really expensive
>    foreach (auto const& item, c) { ... } // does not deep copy
>    for (auto const& item : c) { ... } // *does* deep copy; ouch!
> I think the point here is that it's easy to incur deep copies using
> range-based for when there is no need to do so. There really "needs" to
> be a simple and concise way to stop that from happening.

Use std::cref() if not sure about your container's constness.

     for (auto const& item : std::cref(c)) { ... }

But yes, I'd also prefer the C++ consortium would have opted for an 
immutable range loop. "Optimize the common case, not the rare case". 
Well, and for the code I usually write mutable range loops are a rare 
exception. Also since we got the auto keyword mutable loops are 
convenient to type now:

     for (auto it = begin(c); it != end(c); ++i) { ... }

Not much longer than a range loop statement. But well, we won't change 
that anymore, and at least I have no idea how to avoid that ugly 
"std::cref()". Thinking now in the the direction of just teaching QML 
about C++ standard containers and avoiding the Qt containers then. But 
that also are crazy thoughts.


More information about the Development mailing list