17 hours ago, Gnollrunner said:

Certainly I agree one should try to use up to date documentation.

You cannot appreciate the differences between bad obsolete language features and new and much better options introduced in newer C++ standards without extensive knowledge of their context and their purpose, and without sufficient programming experience to judge what is good or bad for your task.

This intermediate level of proficiency is better reached without learning and then unlearning the bad approaches, therefore the only appropriate advice for a beginner is the general principle that newer standard revisions are better and you should aggressively avoid older ones in order to learn good C++.

8 minutes ago, LorenzoGatti said:

You cannot appreciate the differences between bad obsolete language features and new and much better options introduced in newer C++ standards without extensive knowledge of their context and their purpose, and without sufficient programming experience to judge what is good or bad for your task.

This intermediate level of proficiency is better reached without learning and then unlearning the bad approaches, therefore the only appropriate advice for a beginner is the general principle that newer standard revisions are better and you should aggressively avoid older ones in order to learn good C++.

I've programmed in C++ since the late 80s ...... Now again, what specific "language features" are you referring to?  Can we pin this down a bit?

13 minutes ago, Gnollrunner said:

I've programmed in C++ since the late 80s ...... Now again, what specific "language features" are you referring to?  Can we pin this down a bit?

Don't know which specific features @LorenzoGatti meant, but the current standard offers a lot of benefits. I won't go so far to say, that there are really obsolete language features, but there are certainly a lot of features that are not that important anymore. And some of these features, like raw pointers, can get you into trouble really fast if you don't know what exactly you are doing.

Current standard allows you to write code that is syntactically easier to understand. Think of the new 'for each' loop notation or the using keyword instead of typedef. The std::function is much easier to use than the weird function pointer syntax. If you start with templates, 'constexpr' will remove so much code bloat. The auto keyword will also help to make the code more readable, which is so important for beginners. No more:

std::map<int,std::vector<MyClassWithAVeryLongNameWhichIsAlsoATemplate<bool>>>::iterator = myMap.begin();

Though I have to admit, that excessive use of auto is also not such a good idea.

Then you have static_cast, dynamic_cast, etc instead of C-style casts. There are a lot of articles, why you should avoid c-style casts. I always forget why exactly but it convinced me, So just google it ?

Another nice C++17 feature to reduce code bloat is structured bindings.

As I said in the beginning, I don't see any real obsolete language feature. But in my point of view,  the current standard and tutorials/books that teach it will make learning C++ much easier and less error-prone.

Greetings

45 minutes ago, Gnollrunner said:

I've programmed in C++ since the late 80s ...... Now again, what specific "language features" are you referring to?  Can we pin this down a bit?

As a general category, vastly improved ways to do something important, in some cases new (e.g. lambda functions, templates of anything over anything), in some cases evolutionary (e.g. better standard library pieces), in some cases neater replacements of old ways (e.g. reduction of unnecessary copies).

From a higher level point of view, some of these features help with avoiding the messy naive inheritance hierarchies we got used to in the late 80s by replacing them with templates, object composition and anonymous objects.

But this is only my point of view, other people could have a phobia for templates or a fetish for initializers and constructors.

Beginner and hobbyist here ?

I started ~2years ago with C++ and of course went through phases when i used "smelly code" or did things the "not so right way". I do still. From what i know of the language one can solve problems in many different ways, just like one can describe things in a natural language in different ways, and, guys, i tell you compared to that, a puny formal language is a piece of cake ?

If i am not mistaken and correct me if i am, "modern" refers to C++11 and later. I doubt that a newcomer is interested in the features C++14 and 17 offers in the beginning of her/his striving (i am not), because they are much too high level to care about and grasp. As knowledge grows and necessity comes, one can inform oneself about it because it is impossible to avoid the discussions that sway back and forth. For example all the concurrency features of 11 and their corrections, improvements and amendments in 14 and 17. One doesn't need (but can use) that magic if necessity arises (it will when developing games etc.) and there are more than enough sources available for making oneself clever on the matter.

C++ is a bit like playing golf, i feel. There are so many ways of doing it wrong and so few of doing it right. And it is heresy to just grab the racket and beat the ball elsewhere ?

31 minutes ago, Green_Baron said:

If i am not mistaken and correct me if i am, "modern" refers to C++11 and later. I doubt that a newcomer is interested in the features C++14 and 17 offers in the beginning of her/his striving (i am not), because they are much too high level to care about and grasp.

I think you are wrong here. There are certainly a lot of very specialized changes, that you will probably never need. But some features are so easy to understand and will help you to avoid a lot of pitfalls. The problem is, that most tutorials/books are outdated and do not adjust towards the new standard. I mean what is easier to read/understand:

 for (std::map<int, float>::iterator it = myMap.begin(); it != myMap.end(); ++it)
        std::cout << it->first << ", " << it->second << std::endl;

or the version with ranged based for loop (C++11) and structured bindings (C++17):

for (auto& [key, value] : myMap)
    std::cout << key << ", " << value << std::endl;

The second version is shorter, doesn't need the '->' operator and uses meaningful variable names instead of 'first' and 'second'

I can understand, that a beginner has no motivation to go through a lot of reviews of a new standard and try to find all the things that are interesting for him. Most of the stuff he won't understand anyway. Even I don't get the point of many specialized changes. But if you find beginner tutorials for C++ that use the new standards to keep things simple, it will certainly make things much easier. YMMV

Greetings

23 minutes ago, DerTroll said:

The second version is shorter,

It absolutely is.

But for a beginner also illegible, because he'd have to dig through uint64_t pages on the STL, iterators, lambda functions, combined with the base knowledge on maps and pointers one needs to understand iterators and the whole organisation of the STL to understand that.

For a seasoned programmer this is ok, though i personally avoid auto because it costs too much time to look up what exactly that auto was i came with here and which datatype the second of my current iterator is ... etc. For me it is shorter and clearer if i actually type a line or two, but i am not the brightest light anyway.

Be it as it may, a beginner cares about syntax, variables, assignments, control structures, scope, then functions, the stack, then structs/unions, classes, methods, functors, operators, overloading, before they get to the higher concepts of inheritance, polymorphism after which they can start with the STL and its built in verbosities ?

OP has expressed the wish to learn C++, i support that ?

30 minutes ago, Green_Baron said:

But for a beginner also illegible, because he'd have to dig through uint64_t pages on the STL, iterators, lambda functions, combined with the base knowledge on maps and pointers one needs to understand iterators and the whole organisation of the STL to understand that.

Well, I think that depends on how it is taught. You don't need to know how an engine works to be capable of driving a car. So, you can use STL containers, without knowing too many details. Everything you need to know in the beginning is, how you create a vector/map/whatever, fill it with data and how to access that data. Who cares what a template is. All you need to know is to put some pointy brackets behind the vector and put a type between them. Later on, you can still learn the details and why they are important. Sure, you can mess up with vectors too, but much less than with raw pointers.

36 minutes ago, Green_Baron said:

For me it is shorter and clearer if i actually type a line or two, but i am not the brightest light anyway.

Its a matter of how you learn and understand stuff. People learn things differently. So I won't say using the current Standard will make learning C++ easier. I just want to point out the benefits. In the end, everybody has to find its own way

43 minutes ago, Green_Baron said:

OP has expressed the wish to learn C++, i support that ?

Me too.

Greetings

1 hour ago, DerTroll said:

Well, I think that depends on how it is taught. You don't need to know how an engine works to be capable of driving a car. So, you can use STL containers, without knowing too many details.

.... until you hit a performance issue or run into a problem that the standard library doesn't solve well. Then if you don't  know how to write a container or write you own template you are going to suffer.  IMO this is the main reason we are seeing this new fear of C++ (and yes I've seen it referred to as "fear" many times now) .  People come from the C#, Java, etc world, and are promptly told that they don't need to learn the old stuff. Then they get in a real project where performance matters and are quickly in over their head.  I note that this wasn't a major issue in the past when programmers learned C++ after knowing C, FORTRAN or other compiled languages.

A good example of where the standard library isn't necessarily optimal is std::shared_ptr. The pointers are typically TWICE the size of a raw pointer and for the vast major of uses they don't have to be.  You can easily write a reference counting system with a normal sized pointer. The space penalty can be huge for pointer heavy data structures, and I haven't even started talking about the control block which contains 2 reference counts (one for weak pointers) whether you need both of them or not.

I find the idea that knowledge is dangerous and should be hidden from programmers as a bit silly.  In your analogy a program user should be the driver.  What you're talking about is a guy taking an off the shelf engine and building a car around it.  In that scenario, it's going to be useful to have some understanding about how that engine works, what it can do and what are it's limitations.

4 minutes ago, Gnollrunner said:

until you hit a performance issue or run into a problem that the standard library doesn't solve well. Then if you don't  know how to write a container or write you own template you are going to suffer.

That's why I said, that the details can be learned later. I should have written "should be learned later". My intention was not to say, that it is not necessary to know the basics in general. it is just not necessary to know how everything works to start using it. You should absolutely learn how the stuff works under the hood, the question is just "when?". I think it is better to teach people the safer way of doing things and let them learn the details later instead of giving them all the basic knowledge and then say "now you better forget that". But that's probably personal taste.

11 minutes ago, Gnollrunner said:

A good example of where the standard library isn't necessarily optimal is std::shared_ptr. The pointers are typically TWICE the size of a raw pointer and for the vast major of uses they don't have to be.  You can easily write a reference counting system with a normal sized pointer. The space penalty can be huge for pointer heavy data structures, and I haven't even started talking about the control block which contains 2 reference counts (one for weak pointers) whether you need both of them or not. 

I am also not a fan of shared_ptr, but size issues and the mentioned problems are not exactly something beginners worry about, right?

15 minutes ago, Gnollrunner said:

I find the idea that knowledge is dangerous and should be hidden from programmers as a bit silly.  In your analogy a program user should be the driver.  What you're talking about is a guy taking an off the shelf engine and building a car around it.  In that scenario, it's going to be useful to have some understanding about how that engine works, what it can do and what are it's limitations. 

Again, I don't say knowledge should be hidden. Just saying it might be beneficial to change the order how it is taught to avoid troubles on the way. We can probably lose ourselves in analogies here, but I think you understand what I mean.

Greetings