[Interest] (no subject)

[Prav]

Hello Thiago Macieira!

> The problem is that to choose the best option, you have to understand *how*
> they do what they do, which implies knowing the implementation details. You
> will need to read the source code for the function/class/macro.
This  is  like  selecting food from menu ... you can be unaware how to cook ... just know its final properties.
I mean there is no sense to read definition/implementation ... it is enough if it is said that container is implicitly copied in this loops and const-refernced in this.
Not so much to be aware of ... I think

For pointers problem you mentioned it would be really helpful if one can see final table with properties we get using each type qt's smart pointers
Just simple look at it and one will know what is necessary to use ... because just after reading of blog-post I became aware that smart pointers gives different attitude to sharing.
But I am still missing finalizing view for all qt's smart pointers ... sory for offtopic ... just came to me after reading your blog-post about qt's smart pointers.


Such table can give simple way of selecting iterating for containers ... it could be like:

foreach                                                 - iteration is made for container's const-copy.
ex.: foreach(const auto& item, container)      * It is fine to use it for all Qt-containers because they are implicilty shared (link) and
                                                               * It is bad for std containers because whole container is copied to variable in stack which is takes time and could make stack overflow

"forevery" (here goes selected name)        - iteration is made for container's const-reference.
ex.: "forevery"(const auto& item, container)   * It is fine to use it for all Qt-containers and std-container because no copying is made
                                                               * But ... here goes any bad things which I have not seen yet

iterator-based loop                                  - iteration is made with container itself
ex.:                                                          * Good for Qt-containers and std-container but is tedious and error-prone for writing
                                                               * Need to make variable for container if it returned from function call (like hash.keys())
for (Container::const_iterator iter=container.cbegin(); iter!=container.cend(); ++iter) {
  const Item& item=*iter;
  //...
}

C++11 loop                                           - If you are lucky to have compiler supporting this. It is not long as iterator-based loop and work for Qt and std containers
ex. for(const auto &&item : to_const(container))   * Good for Qt-containers and std-container but is tedious and error-prone for writing
or                                                                   * Need enough C++11 support from compiler side
for(auto && elem: static_cast<const decltype(container) &>(container))


Easy and clear ... from this table (if it is correct) I would decide for myself to use of "forevery" for my typical tasks but will be aware of options ... just in case.


The same life helper can be a table for qt's (and may be std) smart-pointers ... I agree with Thiago that this theme is not lighted I qt documentation.


For ex. MSVC 2010 has no enough support for C++11 loops ... but it is the last version which can be installed on Win XP
(Microsoft is such a pain in the ass for forcing developers to work on new Windows versions by adding nonsense restrictions in tools for developers ... and -100 quickly goes to Microsoft’s karma)
But this is another story


> First of all, "forevery" is too close to "foever", so we'd need another name.
You will get compile time error if mistype them
And actually the name does not matter for me ... whatever majority of people feel comfortable with. foreachref, forconstref, forloop, ... suggestions?


> Second, you're arguing that it's best for everyone, so why can't we change
> foreach?
I could not know all qt developers and all reasons why people love something and we have current foreach as the result ... so for me it is more fair for those who like current implementation to not argue for take something away from them.
Seems easier to give people possibility to select ... and those who want current for-loop can have it.
If there will be no arguments for current foreach and we can switch to const-ref way ... it is also fine for me.


> And third, if for Qt containers the benefit is less than 1 microsecond, why
> should we add it? I recommend adding it to a library that makes more use of
> the Standard Library instead.
Agree ... this is about std-containers also.
foreach is doing container copying for std containers ... const-ref way seems to work fine with both containers.
It is not only about economy on microseconds

There is also situation when someone want to test how speed will change if switch from Qt-container to some std container ... or std-like there own container. If the codebase is not small this small test
can become a real pain. Or if someone need to by requirements switch its code to use std-containers ... I think this is not a rare scenario in life.