[Qt-creator] Using C++11 in Creator's source

[Daniel Teske]

On Tuesday 18 Mar 2014 09:44:17 Christian Kandeler wrote:
> On 03/05/2014 11:12 AM, Poenitz Andre wrote:
> > Ziller Eike wrote:
> >> One rule for using “auto” that I’d like to establish, is to use it only
> >> “when the type is obvious when reading the code”. Of course what that
> >> exactly means should be discussed and shown in some examples, and then
> >> it’s still up for interpretation. E.g.:
> >> 
> >> Yes:
> >> 
> >> auto f = new FooBar;
> >> auto a = new A;
> >> auto myAction = menu->addAction(…);
> >> auto it = list.const_iterator();
> >> 
> >> No:
> >> 
> >> auto i = 4; // the difference between “4;” and “4.;” is subtile with big
> >> consequences> 
> > What is obvious for some might unfortunately not be so obvious for others.
> > 
> >>From the list of "Yes" cases I only fully agree with "auto it =
> >>list.const_iterator();">>
> > I'd actually like to restrict the use of auto to cases where it
> > "significantly" reduces typing and line noise (say, identifiers longer
> > than x chars, and to cases where it doesn't change meaning.
> 
> On the other hand, patches that change types in function signatures will
> potentially get much smaller if "auto" is used extensively. For
> instance, if you take a look at the "QString -> Core::Id" or "QString ->
> Utils::FileName" patches, you will notice that quite a number of hunks
> would disappear entirely.
But that's NOT a good thing. After all the type changed, the behavior changed, 
and you need to look at all those places to consider the implications. 
Utils::FIleName is a mostly drop in replacement for QString, but it behaves 
differently.

> In general, it seems to me that using "auto" is sensible when assigning
> the result of a function call, as the type is already specified.

The ultimate aim of our coding style is to make code maintainable, by being 
readable.

If you need to lookup the return values of functions, to understand code then 
that makes the code less readable to me. The types of variables are important, 
and thus shouldn't be hidden. 

daniel