The mouseover thing has been the case since the inception of auto. Mousing over any variable in VS should show its fully deduced type.

Only in IDEs that support it.

If the only way to know the true type of things is to play peek-a-boo with the variable as it hovers over the mouse which works only in editors that have access to the full source tree, that's a problem. What happens if you need to edit a file and you don't have all the source conveniently available so it is improperly deduced? What if you are editing code in a tool that doesn't support the feature?

There are plenty of times I will pull up Notepad++ or similar text editors to quickly edit source code, and if I run across a function that uses autos for nearly everything I am going to be far less productive than if I could see the actual type.

As for where to use it... For types that are difficult to put together or long to type, like iterators to containers with template parameters, that is generally a good reason. Lambdas obviously require them in several situations. But typing "auto" instead of "int" is worse than just lazy because it is an extra character. It is a longer word AND it obfuscates the type.

There are plenty of times I will pull up Notepad++ or similar text editors to quickly edit source code, and if I run across a function that uses autos for nearly everything I am going to be far less productive than if I could see the actual type.

I agree... auto hides the meaning of the code. I'll avoid it generally.

The choices shouldn't be:

• Avoid it almost everywhere
  or
• Use it almost everywhere

The smart thing is to learn when to use it, and use it in those situations, but not in other situations where using could problems.

Almost everything in C++ has "don't use it" situations and "use it here" situations.

But less-experienced programmers often simplify that to, "Never use X!" or "Use X everywhere!" rather than, you know, actually learning. :wink:

I agree learning when to use it should be the end goal, but I can also imagine that you park it for some time, until you have a firmer grasp of the other new things.

Python was my first language that was reference-based, and it was mighty scary, so many new things at the same time. I decided to ignore sharing of data at first, and recomputed the new value for each variable from scratch every single time. While it cost performance, there were so many other things I needed to wrap my head around at the time, it made sense to me to postpone handling sharing as well.

As I got more confident in all the other concepts of the language, I started experimenting with less full recomputing (that is, use references in the code). Moved a bit too far, and reverted a step to eventually end up at the point where I am now, which seems to agree with how many other Python coders work.

Here's how to generate a pseudorandom double. Much easier than including the Mersenne Twister header and cpp file.

#include <random>
#include <iostream>
 
using std::random_device;
using std::mt19937;
using std::uniform_real_distribution;
 
using std::cout;
using std::endl;
 
int main()
{
    random_device rd;
    mt19937 gen(rd());
    uniform_real_distribution<double> dis(0, 1);
    for (int n = 0; n < 10; ++n) {
        cout << dis(gen) << ' ';
    }
    cout << endl;
}

Does anyone know how to seed the pseudorandom number generator?

First Google hit for 'std::mt19937' is this: http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine

On there is a link to the seed function: http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine/seed

First Google hit for 'std::mt19937' is this: http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine

On there is a link to the seed function: http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine/seed

Thanks Kylotan!!

A lot of the C++11 syntax wouldn't compile on my Mac (using clang++) unless I add the -std=c++11 -stdlib=libc++ command line options. Glad to have figured that one out. Some code only works if I use g++.