According to Microsoft, using the auto keyword, as well as lambdas can make "cleaner, tighter and easier to read"(abbreviated of course) code. I am not in any industry, but merely a lowly hobbyist. So can someone explain to me the general reasons why this is whats being pushed by Microsoft and if it is being adopted by others, why I am wrong in my disagreement with these statements?

If you remove the standard c++ library, are lambdas not merely just a "fancy" way to scope a block of code? Are anonymous functions really THAT COOL?

And how is auto easier to read? You are implying and hiding the type unless you explicitly and physically look at what it is received by?

Not starting flame war, rather an educational opportunity for my self and others.

If you remove the standard c++ library, are lambdas not merely just a "fancy" way to scope a block of code? Are anonymous functions really THAT COOL?

You're implying that only the standard library uses functors. That's far from the case. You can write your own generic algorithms. ;)
You're also apparently forgetting that C++ lambdas can capture (becoming closures), which means that you can create things like event handlers without the verbiage of creating a class to represent that concept.

And how is auto easier to read? You are implying and hiding the type unless you explicitly and physically look at what it is received by?

A lot of the time we don't actually care what the exact type is so long as the compiler enforces it. auto is a way to cut down on the general verboseness of heavily templated code, among other things. Which of these is clearer?

[source]
for (container_type<foo<int>, bar<char*>>::iterator itor = std::begin(collection); itor != std::end(collection); ++itor) {}

for (auto itor = std::begin(collection); itor != std::end(collection); ++itor) {}
[/source]

According to Microsoft, using the auto keyword, as well as lambdas can make "cleaner, tighter and easier to read"(abbreviated of course) code. I am not in any industry, but merely a lowly hobbyist. So can someone explain to me the general reasons why this is whats being pushed by Microsoft and if it is being adopted by others, why I am wrong in my disagreement with these statements?

If you remove the standard c++ library, are lambdas not merely just a "fancy" way to scope a block of code? Are anonymous functions really THAT COOL?

And how is auto easier to read? You are implying and hiding the type unless you explicitly and physically look at what it is received by?

Not starting flame war, rather an educational opportunity for my self and others.

On the large Microsoft really wants to empower a large number of software engineers through higher level technology. One might view this whole idea as a poor one when considering this is sort of the purpose of the old .NET stuff. Come ten years later we have two major ways to write code that MS enjoys: C# and the newer more abstraction heavy "modern" C++. This might just be a newer generation of engineers not learning from old mistakes, or it might be that the new high level facilities really can empower tons of engineers to do be more productive.

However there's another argument against the whole "empower the many" option: empower just a few. More experience older game industry vets usually heavily align with the idea that it's more important to have an extremely strong/experienced developer as opposed to a work force of C# coders. This alignment usually revolves around ideas like abstractions have an inherent cost, writing good code is ridiculously hard, adding more people is expensive to facilitate communication, etc.

My personal opinion on auto is that it's only useful if you're using templates. So now the question might be, is it worth it to use templates? Immediately I can see this question starts to get pretty involved, and would probably require some specific examples of real work to justify one way or another. So as long as someone tried something out and shipped a product with it I would care about their opinion. Microsoft certainly ships a lot of products, but I don't really enjoy many of them, so me specifically would not really agree with their process (like auto/lambda).

Randy Gaul, I have no clue why you spent that whole post in the context of Microsoft. The features talked about have nothing to do with them (except they, like quiet a few other people, have a C++ compiler). They are C++11 features. Pretty old ones by now, we already have C++14 and C++17 around the corner. Just because the OP stumbled on them in something written by Microsoft does not mean it's reasonable to look at all the angles Microsoft might have with them. You could as well ask what Microsoft wants with for-loops because they mentioned them in an introductory article about C++ somewhere.

As a matter of fact Microsoft's own compilers have been hanging behind on C++11 features for a long time when others like gcc or clang already had complete or near-complete implementations. I hear they have recently managed to catch up but I could not yet try out the newer compilers in a realistic setting. An evil person might even say that Microsoft only talks about those features now-ish because only very recently they have compilers implementing them properly (although that would be a bit unfair because even though a lot of things were broken/incomplete for a long time, both lambdas and auto worked decently even back in 2012).

Now, discarding that wholly unnecessary Microsoft talk: both features are pretty much core for me. Sure, lambdas could be implemented using a simple class functor. But for small stuff they are much less verbose, for slightly more complicated stuff (needing to capture things) they completely eliminate unnecessary and error-prone boilerplate.

auto is mostly useful in the context of templates (and if you do not use them I seriously question why you even bother with C++) but they are something useful/less verbose in other situations (quickest example: storing a lambda).

Edit: and I have never seen someone do everything with autos the way Matias Goldberg exaggerates, nor seriously suggest that would be a good idea. I'd want some actual quotes on that.

auto and lambdas can be abused and overused just like many programming features, and when something is shiny and new, people are more likely to abuse them.

But don't let their abuses hide the fact that they are actually very useful.

They are especially handy for one-liner predicates to pass to algorithms. In such situations, either the one-liner is something you want to repeatedly use, and should be separated and "standardized" in your codebase (like std::less, for example, or my own case_insensitive_hash), or, if just used in a single place, shouldn't be seperated from the code that actually uses it.

Here's a real example from my code:

//Frees all the images whose shared-count has reached zero.
//Call this after loading an area, to free all the images that are no longer needed.
void AnimationRetriever::FreeAllUnused()
{
    //Remove all the shared_ptrs that are shared by one or less sharers.
    //Since the map's shared ptrs themselves count as a sharer, they are the 'one' sharecount.
    //We keep the shared pointers in the map for precisely this reason - we want to leave an
    //additional sharer keeping the object alive incase the next loaded area wants to use it.
    MapRemoveValues(this->loadedAnimations, [](const AnimationSPtr &sPtr){ return (sPtr.use_count() <= 1); });
}

It wouldn't make sense to separate this lambda into its own function.

Now if I actually needed this behavior alot, I would make it its own function and pass in a parameter and a member func to call

(like if_mem_func_returns(&(std::shared_ptr::use_count), std::less_equal, 1) ), but since that's actually harder to read, I'd only do that if I found myself using this behavior alot.

Lambdas are also useful to clean up repetitive code from functions.

Here's a slightly messy real example:

(for context, the enclosing function is queuing for rendering the dotted rectangle around selections, with the squares on the corners and sides for stretching and resizing the selection)

    //================================================
    //Draw the grabpoints:

    auto drawGrabPoint = [&](const cPointF &center, bool colorationButton)
    {
        using namespace Engine::Graphics;

        cRectF positionRect = cRectF::CreateFromCenter(center, CornerGrabpointSize);
        positionRect.Round();

        const cRectF &OrangeSubrect = (colorationButton? CornerGrabpointSubRect_Orange_Coloration : CornerGrabpointSubRect_Orange);
        const cRectF &BlueSubrect   = (colorationButton? CornerGrabpointSubRect_Blue_Coloration : CornerGrabpointSubRect_Blue);

        const cRectF &texCoords = (positionRect.Padded(1).Contains(this->lastMousePosInWorld) ? BlueSubrect //Hovered.
                                  : this->stretching ? CornerGrabpointSubRect_Red //Skewing.
                                  : OrangeSubrect); //Normal.

        SetBasicTextureData(quadBatch, quadBatch.GetNextIndex(), positionRect, 0.0f, texCoords, this->guiTexture.GetDetails().textureSize, cColor::Full);
    };

    //Corners:
    drawGrabPoint(decal.corners.topLeft,     false);
    drawGrabPoint(decal.corners.topRight,    false);
    drawGrabPoint(decal.corners.bottomRight, false);
    drawGrabPoint(decal.corners.bottomLeft,  false);

    //Sides:
    drawGrabPoint(cPointF::PointBetween(decal.corners.topLeft,     decal.corners.topRight),    false);
    drawGrabPoint(cPointF::PointBetween(decal.corners.topRight,    decal.corners.bottomRight), false);
    drawGrabPoint(cPointF::PointBetween(decal.corners.bottomRight, decal.corners.bottomLeft),  false);
    drawGrabPoint(cPointF::PointBetween(decal.corners.bottomLeft,  decal.corners.topLeft),     false);

    //================================================

(note that any mess is from my code within the lambda, not the usage of the lambda itself. The lambda makes the code clearer)

If the lambda was larger, I'd separate it into a standalone function called something like priv_drawGrabPoint(...), which would also have to take several additional parameters that the lambda was capturing for me.

Previously, I had to make every example of this time be a stand-alone "implementation" function, even when it was just a few lines of code, which unnecessarily separates related code from being right next to each other.

foreach( auto x : m_foos ) {}

Looks ok, right? Well turns out m_foos is std::vector<Foo> m_foos; The loop will perform a hard copy Foo in every iteration. [...snip...]

foreach( auto &x : m_foos ) { }

And now x is a reference, rather than a hardcopy.

But that's not an auto issue. That's a misuse of variables in-general issue.
If you did:

for( Foo x : m_foos )

...the exact same flaw would occur.

Further, I would suggest by default one should use const-reference, and only go to non-const reference or value (or r-value) is the code needs it (for example, if it's just integers).
If you use good coding practices, then "auto x : m_foos" stands out just as badly as "Foo x : m_foos".