Autocompletion of auto type variable using QT Creator 4.2.

[Shiina]

Hi.

I use QT Creator 4.2 on microsoft windows with compiler of Visual Studio 2015 community.

My problem is autocompletion of auto type variable.

For example.

auto s1 = std:string("s1");
  s1.   // NG.  Can't complete.

Of course, in case of

   std::string s2("s2");
   s2.  // OK. Can complete.

Is there some necessary configuration on QT Creator to set for completion of auto variable?

Or, Can't QT Creator complete auto type variables.
If so, is there any plan of implement the function on QT Creator roadmap.

EDIT (sierdzio): added code tags

[Shiina]

@sierdzio Thank you.
I tried clang code model plugin and made it!
You're my hero. :-D

@kshegunov Your answer is nonsence for my question.
Because c++ "have" auto type variable.
You should beat ISO C++ committee and users of dynamic typing languages all of the world. :-P

I love c++ because it "DON'T'" foist a specific programming style. Some languages DO.

The clang code model plugin is great. It complete the code like below(c++14).

auto plus = [](auto a, auto b) {
    return a + b;
};

auto a = plus(1, 2);  // 3
auto s1 = plus(QString("1"), QString("2"));  // "12"
s1.   //  Here. QT Creator with the plugin can complete it. It recognize variable s1 is QString!

I prefer this style to using generic in case of simpler functions.
The c++ has drastically changing.

[sierdzio]

Try enabling the clang code model plugin, it should be more intelligent than the default one.

Although I am pretty sure the default code model should handle auto, so maybe you've hit some bug in 4.2.

[kshegunov]

Or as I always preach, don't use auto at all. What would be the purpose of hiding the type anyway, to make a more cryptic code? Don't forget someone will probably read that at some point, and as it happens it might be just you!

[sierdzio]

@kshegunov said in Autocompletion of auto type variable using QT Creator 4.2.:

Or as I always preach, don't use auto at all.

Well, that's debatable of course, for some people auto is a good thing, others regard it as unnecessary. As long as the team agrees to a standard I think both approaches are fine.

It does, though, have some important benefits:

• less error prone (for example, auto will ensure that you don't implicitly loose precision when mixing ints and floats): int a = someFloatValue; auto b = someFloatValue;
• usually less dumb typing (SomeVeryLongName *ptr = new SomeVeryLongName())
• less work to do when refactoring code
• less typing for long types (containers)
• etc.

Recommended watch: https://youtu.be/xnqTKD8uD64?t=29m4s (actually the whole video is great, but I link only to part about auto).

[kshegunov]

@sierdzio said in Autocompletion of auto type variable using QT Creator 4.2.:

less error prone (for example, auto will ensure that you don't implicitly loose precision when mixing ints and floats)

This I don't consider less error prone, sorry.

auto a = 0;
unsigned short b = 5;

if (a > b)
    ; // La-la signed unsigned mismatch

Plus it implies integral promotion to the widest type involved behind the scenes. One of the big critiques about C++ is that it's too implicit, so auto not only doesn't improve on that, it makes it even worse.
And same argument for:

usually less dumb typing (SomeVeryLongName *ptr = new SomeVeryLongName())

Calling:

auto p = someFunctionReturnsSomething();
auto y = p.x();

implies you have to know what exact type is the first function returning so you again have to know the API by heart to know what p.x() returns. It obfuscates the code, instead of making explicit. The above example could just return a QPoint and then it's clear what .x() means:

QPoint p = someFunctionReturnsSomething();
qint32 y = p.x();  // We know we are working with a point, x() can't be anything but the x coordinate.

less work to do when refactoring code
less typing for long types (containers)

I'll grant you these, however a local typedef works just as well for long types (like container iterators) and you lose nothing but a line of writing.
It might be useful for prototyping where long expressions are involved (as lambda's types) but I really don't think it's a good idea to go overboard ... you might just drown, so to speak ...

@sierdzio said in Autocompletion of auto type variable using QT Creator 4.2.:

Recommended watch

Seen Sutter, read the AAA article. I don't personally like the guy, but regardless I don't agree with most of his arguments.

Kind regards.

[sierdzio]

@kshegunov said in Autocompletion of auto type variable using QT Creator 4.2.:

Calling:
auto p = someFunctionReturnsSomething();
auto y = p.x();

implies you have to know what exact type is the first function returning so you again have to know the API by heart to know what p.x() returns

Easy to work around: agree with others in team not to use "auto" in this case. I purposefully used example with "new" to show a case where it really is a dumb repetition.

I'm not saying to use it everywhere, that would be unpleasant. Anyway, luckily nobody is forcing us to use any specific convention, each project can agree on what suits them best.

[Shiina]

@sierdzio Thank you.
I tried clang code model plugin and made it!
You're my hero. :-D

@kshegunov Your answer is nonsence for my question.
Because c++ "have" auto type variable.
You should beat ISO C++ committee and users of dynamic typing languages all of the world. :-P

I love c++ because it "DON'T'" foist a specific programming style. Some languages DO.

The clang code model plugin is great. It complete the code like below(c++14).

auto plus = [](auto a, auto b) {
    return a + b;
};

auto a = plus(1, 2);  // 3
auto s1 = plus(QString("1"), QString("2"));  // "12"
s1.   //  Here. QT Creator with the plugin can complete it. It recognize variable s1 is QString!

I prefer this style to using generic in case of simpler functions.
The c++ has drastically changing.

[kshegunov]

@Shiina said in Autocompletion of auto type variable using QT Creator 4.2.:

Your answer is nonsence for my question.

Yes, I got carried away, sorry for hijacking your thread.