Ziller Eike wrote:
> On Mar 4, 2014, at 2:09 PM, Daniel Teske <[email protected]> wrote:
>
> > Hi,
> >
> > since we have branched 3.1 from master, master no longer needs to support
> > OS X
> > 10.6. As such I propose, that we open up master for those C++11 features
> > that
> > are supported by VS 2010, g++ 4.5 and clang 3.1.
> >
> > I think it's too early to require a newer version of Visual Studio, though
> > requiring those 3 compilers gives us both *auto* and *lambda*.
> >
> > I suspect that in practice the minimum g++ or clang version will be higher,
> > since practically no one uses those versions any more.
> >
> > We need to extend the coding rules for auto and lambda. Suggestions are
> > welcome for that.
>
> 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.
Simple types ('int', 'bool', 'double' ... should never be 'auto'd', and I am
tempted to
include "simple Qt value types" like 'QString' in this section.
For the pointer cases, we should spend a thought or two on possibly requiring
auto *f = new FooBar;
to keep the visual clue that this is a pointer that might (or might not) need
some
cleanup.
It would be nice if <F2> on 'auto' would jump to the definition of the 'real'
type.
I'd also like to get some time to collect experience with the new toys before
major existing hunks of code are converted.
Andre'
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
