Generally, the goal of auto is to create a variable whose purpose is to store a value of the type you have: you called a function, got a constant reference, but to store that you need a concrete value. Generally, the goal of decltype is to compute a type based on other code whose type you don't already know: a simple canonical example is to make a function that does something and transparently returns the result "as if" it were the original code. These are two drastically different use cases and, given the semantics of the various qualifiers, it makes sense to strip them for one and not for the other, lending to two different syntaxes. If you find yourself needing to transparently store the result of an expression, in C++14 you can use "decltype(auto) ;P".

I too have started learning C++11 recently after having never really had success picking up the language in the past.

Coming from C I found C++ to be really difficult when I tried to pick it up a few years ago. I have since learnt Python,Ruby and C# and now I am having alot more success. So I really do second your opinion that learning something like Java (in my case C#) really helps a ton.

I also highly recommend checking out the books recommended here: http://isocpp.org/get-started I am currently reading C++ Primer. :)

C++ is mostly an extension of C (there are some subtle differences like changes in the type system), so I also recommend C before C++; understanding how classes and methods are implemented (which would be the natural way to do it in C anyway) gives you better knowledge of practical, pragmatic use of OOP.

As you mention, the layering of C++ is another thing that can guide the approach to learning the language: begin with the simple concepts that C++ added, like classes with methods, and then move on to inheritance, virtual methods, overloading/overriding, operator overloading, exceptions, and then templates, making sure you understand the previous ones before proceeding to the next extension. It's a big language, with many features, not all of which you'll need to use for any one application.

> C++ is mostly an extension of C (there are some subtle differences like changes in the type system), so I also recommend C before C++

Never ever do this in 2014. It is the path of writing unsecure code.

Modern C++ has better, more secure, approaches how to write code.

Leave C like coding to legacy code.

> It is the path of writing unsecure code.

Why? If anything you will learn more about the types of bugs that lead to security issues, and thus gain a better understanding of how to avoid them.

I feel like "security" is the new "think of the children" phrase these days.

- Prefer STL data types (vector, string...) over the native ones

- Use references for modifiable parameters. No need to check for null

- Templates, enum classes, const/constexpr, inline calls instead of preprocessor macros

- Use of RAII and smart pointers over manual memory management

> I feel like "security" is the new "think of the children" phrase these days.

It was nothing new. It was present since the early days in the form of languages like Mesa(1970), Modula-2 (1978), among others.

Just that developers got to forget about them when UNIX got out of the universities into the enterprise. Nowadays we pay for it as we discover how important it is to have secure software.

edit: typo (import => important )

> Nowadays we pay for it as we discover how important it is to have secure software.

I'm going to give a very controversial perspective here: Things like jailbreaks and homebrew on consoles are possible because of certain "security flaws" that are more common in languages like C and C++. If everyone used "safer" languages, wouldn't these become much rarer? If it weren't for this "insecurity", would our computing devices and software be even more locked-down and restricted against us and more control be put in the hands of large corporate entities or governments? Making software more secure against malicious attackers also makes it more secure against those fighting for freedom and control. The world is not quite so black-and-white...

> Things like jailbreaks and homebrew on consoles are possible because of certain "security flaws" that are more common in languages like C and C++.

Using C++ as if it were C but s/malloc/new/ and s/free/delete/ is certainly a good way to get security vulns. But as pjmlp mentioned, that isn't how you should be using C++ nowadays.

I never did any jailbreak or homebreak in my devices. I rather have memory safe languages.

To put it in perspective, I code since the days C was UNIX only so I had the pleasure to know better designed languages for system programming, that sadly went out of fashion as UNIX spread into the enterprise.

> If anything you will learn more about the types of bugs that lead to security issues

Usually you will learn this lesson the hard way.

>..I also recommend C before C++..

I'm going to agree with pjmlp and advise against this. It will lead you to things like relying on char*'s instead of std::string because it works, it's what you know and plenty of examples on the web do so.

> C++ is mostly an extension of C

This is absolutely not the case. C++ is a huge monolith of a language that happens to have a fairly large intersection with C.

Understanding technical things like the stack, heap, how new types would be laid out, etc. are all wonderful things to know for C++, that much is true. So if learning C is conducive to learning about those topics then by all means, make it a prereq.

But please don't use language that would give the impression that C++ in 2014 is sort of "C with Classes".