hi. as i like to advance in c++ as a game developer I figure out that its a language the more you swim, the more you drown.

there are many features that are included in std and game many new features like rvalue references, move semantics or forward and…

is it very important for a cpp developer to learn all of them?

moeen k said:
is it very important for a cpp developer to learn all of them?

Its definately benefical. I wouldn't want to work in C++ pre 11, and lots of features from 14 upwards are also highly applicable in terms of allowing me to write code faster, cleaner and safer IMHO. There's always the occasional thing you don't really need most of the time. But you should at least try to keep up with the major features for your own benefit.

C++ can take a lifetime to master. The more you know, the more you realize you don't know. However, with dedication you can reach an advanced level.

It is also a moving target, as new features come out for C++ every few years, but it is important to learn some of the new stuff as it can really help with more complex projects.

I highly doubt you can learn “all about” any specific topic, except perhaps the most elementary of things.

C++ is constantly evolving and new features get added about every three years. I would definitely consider modern C++ features (C++11 onwards) and the STL to be essential for any programmer working with C++. Anything added since then (C++14, 17 or 20 features) has been added to make the code cleaner, safer, or address some kind of potential pitfall. std::format (added in C++20) is my favorite example of making formatted output commands more concise. Smart pointers (added in C++11, improved in subsequent iterations) avoid some pitfalls associated with classic C-style pointers. In general, the more recent a feature is, the less likely you're going to find it in many projects. At the same time, though, it's pretty rare to find pre-C++11 code in most current projects, except possibly some beginners' projects, which sometimes use basic C++ that is mostly interoperable with C if you change all the classes to structs.

If you're programming purely in C++ (i.e. not using a “dialect” of C++, such as in the Unreal Engine), I'd give a broad list of features you should be familiar with as object orientation, templatization, STL, pointers, and dynamic memory management. Taking a magic number from language-learning, get to a point where you can understand 80 to 90% of code written by an average coder (as in, neither a beginner, nor the Einstein of C++ coding) using these features and can make up for the rest with a language reference (just like you'd use a dictionary when you come across an unfamiliar word in a language you know). The STL is vast, and I may lower the figure to 50-60%, because it involves constructs that you may not require depending on your field.

In any case, you should aim to be at a level where the documentation is the only reference you need when you don't understand some aspect of the language (you'll obviously have to use other references if there's an algorithm you don't understand, for instance).

moeen k said:
know all of C++ features? … is it very important for a cpp developer to learn all of them?

Knowing ALL of C++ is probably impossible, even people on the standards committee make discoveries. The previous version of the standard was 1448 pages, and a new version with many sets of features is even larger.

When Nicolai Josuttis wrote his tutorial and reference book about the C++ standard library, even though he was on the language committee and was one of the global experts he had commentary about discoveries he made while composing the book, including discovering some defects and potential improvements. Herb Sutter who has been chair of the language committee almost the entire time said he was still continuously learning new things about the language.

Language lawyers study the language and find creative ways to do things. I'm not a language lawyer but one of the most expert at my current studio. Even though I've been studying the standards documents since C++98 first came out sometimes I still discover new and surprising elements. Over the years they include learning surprising things about some of the containers when working on some standards-respecting container types, and way back in '02 helping out with a defect report that was rejected. (The solution for the standard was to have the next version simply state “it is unspecified”).

Nobody is expected to know ALL of c++. You will be expected to be familiar with it, and to look up what you need as you go.

moeen k said:
new features like rvalue references, move semantics or forward and…

In the work environment you will be expected to learn a bit about how new features work. You will slowly be exposed to them over time, and your code will grow to adopt the features.

You probably won't be expected to know about all the new features right away, but as the code grows and more features are used you'll be expected to pick them up by study on your own, talking with other developers, or by context.

The fact that you know those exist is a good start. Keep learning whatever you can.

moeen k said:
many features that are included in std … is it very important for a cpp developer to learn all of them?

The standard library (as meant by std) isn't C++ and C++ isn't the standard library. This said, you can use the standard library most popular features or all the features if you like but this is unrelated to C++. C++ is the language and specifications, the standard library is just a framework to make things easier!

One could absolutely live without the standard library or write your own standard library (like EA did). Especially in games there are pros and cons about it. Using anything std involves a risk, a risk of not using it properly and a risk of things done in the background that you can't (easily) control like memory allocation.

Most features in the standard library are pure C/C++ code and could be replaced/reproduced, like data container types and delegates. Some features are wrapper classes over OS specific APIs, like file streams, threads or the atomic data types. However, some features belong to compiler magic you must use the standard library in order to convince the compiler to do what it is supposed to do. An example of that is async/await.

So the answer is it depends. TL;DR if you want to just make some programs with C++ and don't care about performance, you're good to go with the standard library. If you care about control/performance over convenience, then you can also avoid the standard library and instead implement your features using platform dependant APIs

I would say no. C++ features are not nearly as important is knowing algorithms and data structures. Modern C++ is mostly the addition of the standard library. There are some new things and some of them are even handy like move semantics. On the other hand sometimes modern C++ can blind you to things that you would know if you learned C++ by going up thought the ranks of learning C, old C++ and Modern C++ in that order.

Talk is cheap so I'll give you some examples. Let's take something basic like std::string. It's …. well …… OK.. But it's not necessarily ideal for everything. It often comes with SSO (small sting optimization) which means your minimum sting size ends up being something like 32 byte as opposed to 8. That's true even if it's a null string. What's worse is there is also a different kind of string called a COW string (Copy on Write) which shares data between strings, but because of some quark of the standard library it's not longer possible to use it with std::string. Now, you can always write your own string class or get a COW string online somewhere, but if you don't know enough of the ins and outs, you won't know when you need it. BTW, in my opinion COW strings are better most of the time.

Another thing I dislike is std::shared_ptr. It's just awful as near as I can tell, for most of the things you really need a reference counting pointer for. It's main problem is that it's 2X the size of a regular pointer. But it also has an extra weak counter whether you need weak pointers or not and there is no way to turn of the thread safety if you don't need it. As a result it's notoriously slow. Again you can use your own smart pointers, and might opt to do so IF you know the tradeoffs.

The general problem with the standard library is it's a black box and it can be implemented differently by different vendors. There is actually no standard, standard library. They are all supposed to work the same but that doesn't mean the performance is going to be the same. In general I use it for stuff that I really can't do portably any other way. Threading is a good example. However I usually write my own containers. First I don't end up with confusing bugs that I have to look though a vendors spaghetti code to figure out. And second, if I need a feature I just add it. I've seen discussions on the internet about how to implement something using the standard library where I could have written the solution in less time than people were arguing about it.

That's not to say everything is bad. If you need a vector std::vector is not bad. std::array is OK to as will as some other classes. However you should know enough to realize when it's not the best option or at least when using it is costing your significantly. C++ is really a mess these days. It's still usable but try not to use features just for the sake of using them, or someone told you they were cool. Understand why you are using something.

Do not use the auto keyword. You’re only obfuscating your code when you use it.

Gnollrunner said:
I would say no. C++ features are not nearly as important is knowing algorithms and data structures. Modern C++ is mostly the addition of the standard library. There are some new things and some of them are even handy like move semantics. On the other hand sometimes modern C++ can blind you to things that you would know if you learned C++ by going up thought the ranks of learning C, old C++ and Modern C++ in that order.

I completely disagree. The difference, for example between:

const std::vector<int>::iterator end = elements.end();
for (std::vector<int>::iterator itr = elements.begin(); itr != elements.end(); ++itr)
{
	std::cout << *itr;
}

and

for (const auto element : elements)
{
	std::cout << element;
}

for example, is absolutely game-changing. Sure, not every feature between c++98 and c++23 is that mind-boggling, but between lambdas, string_view, concepts, variadic templates etc… are all things that have much more impact on your overall productivity then just knowing about vector and list and when to use which.

taby said:
Do not use the auto keyword. You’re only obfuscating your code when you use it.

I also completely disagree on this. In 95% of places where you write the type, is doesn't matter. Especially when dealing with iterators or other complex templates, typing the fully qualified name is a huge waste of space, and can even decrease readability. I'm personally a huge fan of almost always auto, but I guess you can overdo it - but saying “do not use auto” is absolutely not warranted. For example, whats the point of having the type here:

void collisionResponse(std::span<Entity*> entities)
{
	//for (Entity* pEntity : entities)
	for (auto* pEntity : entities)
	{
		pEntity->DoSomething();
	}
}

It doesn't add anything of value - you literally have the type of the container one line above, the name is already explanatory enough; if somebody doesn't know what an entity is in the context of the code reading the type won't matter (and if he does, he'll likely know mostly based on the variable-name). I'd be willing to compromise that using “auto” might obfuscate the code when its used where the actual type cannot be inferred from the surrounding source (which should be rather rare) - and that only for the sake of being able to read the code in source-control, because IDEs will already fill in the missing information while coding anyways.