Juliean said:

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:

What exactly that I wrote are you disagreeing with?

L. Spiro said:
From whose perspective? The original author who already has context for the code or the people who maintain it starting as blank slates? You’re just saying that type explicitness is of little value to you because you aren’t going to encounter situations where you have to infer the type or to learn about the type by hitting F12 on it.

In my particular example, it was from the perspective of having the containing type just a few lines above, which IMHO makes infering the type pretty straightforward. The choice of span<Entity*> was on purpose - if it were the case of an example like this:

void doSomethingWithEntity(EntityManager& entities)
{
	auto* pEntity = entities.GetEntity(0);
}

Then I'm totally with you on the reasons and cases for where it adds noticable obfuscation. I was mainly trying to counter the “never use auto". My own personal habits on auto are usually much more liberal (as you correctly assessed, I have the luxurity of not having to deal with the problems of people working with entirely unfamiliar codebases in my own project), which is why in work I also restrict my use of auto/var a little bit. So from an objective standpoint, I can totally agree to a middle-ground of “sometimes auto”.

Juliean said:

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

I'm on @taby ‘s side, don’t use auto in C++ as same as var in C#. You're not writing Javascript so stay always in a clear manner about your types, even if it means you need to write more code than when using auto/var. It makes the code more readable at least and no, you don't always have an intellisence service on your side which you simply need to hover the variable and see it's type. Think of open source, think of GitHub. Explicit type usage makes our all live easier when reading someone else's code

taby said:

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

I generally don't use auto either. However in a few rare circumstances I found that it did save me a template parameter in places.

Juliean said:
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.

It's game changing in a sense of take a step back and forth:

// C: 
for (size_t i=0; i<elements.size(); i++) elements[i].Do();
// C++:
// I'm too lazy to type code snippet using iterators. It just sucks.
// modern:
for (auto &element : elements) element.Do();

The modern way is not so much less to type than the old school one, and because i mostly need the index for other things in the loop, i still use the first one most of the time.
So i don't see a real game changer here, although i agree to your point of better productivity using other modern features.

But i also agree to Gnollrunners point. It's most important to learn algorithms, data structures, just ability to solve problems. So this should come first, and utilizing all language features is optional to get there.
If we focus on language or paradigms early, which is a complex matter on its own, it may well happen learning the more important things becomes obfuscated and just harder for no benefit.

Just want to chime in on using auto since most people seem to be against it. I've heard the argument for other languages as well. Type inference is very common in modern strongly-typed languages like Haskell, Rust and Kotlin. Those are for me the three most ergonomic languages I've tried and that is in part (albeit a small part out of many) due to type inference. In those languages it's not always the best option to use type inference but most of the time I've found that it simplifies code. Type inference is simply abstracting away unimportant details in my view.

So with that basis I would say it is good to use auto as well. But I think an issue with C++ is that types can become obfuscated. For example, I'm going through a tutorial on some OpenGL stuff right now and it's using glad.c. That middle-layer makes the function signatures very hard to know since the right one doesn't pop up when hovering over the type signature. I think this is common in C++, that the IDE has trouble finding the right definitions for types. I would say this is a C++ and tooling issue more than an issue with type inference. I still think it should be used as often as makes sense though.

Edit: Just want to clarify why I'm talking about function type signatures. I believe if you define some type with type inference and then it's sent to a function, if the parameters of the function are clearly shown when you hover over it, using type inference is very ergonomical. This also assumes that functions are kept short enough so it's easy to see both the variable definition and the function that is called. So no 500-lines-of-code functions.

Thanks for chiming in!

C++ is a vast native programming language, the main reason for the sheer size of the language is that the most important thing for the standard committee [WG21] (the people that decides what to put in the language) is backwards compatibility.

So every improvement its an alternative to an existing feature ( new options of doing same things but better, in most cases ) or a completely new feature; in both cases the target is for the old code to compile on the new the compiler. So C++ 11 code compiles on C++ 14,17,21 compilers. This goes way back to the early versions of C++ (maybe with minor changes to the code here and there in some cases).

You can go and learn the language it self (only the language) but that will take you a small part of the way. C++ requires the programmer not only to know and understand the language (the tools) but the domain to (the craft), very well.

In my opinion a good C++ programmer knows the language well enough and has deep understanding of the target domain (the domain he's/she's working in). Most of the domains you can work in requires knowledge of other domains to, some more some less. Eg.

Game programming requires domain knowledge of :

• system programming
• graphics programming
• network programming
• sound programming
• advanced data structures
• advanced algorithms
• hardware knowledge (eg. how your code can take advantage of the memory cache system to improve performance)
• data oriented design
• and a lot more.

Auto is an important addition to cpp and you should learn to use it effectively. Auto is used for automatic type inference obviously, but is also used with templating in lambdas and also structured binding. lambda templating, structured binding, type inference and improved readability in the case of templated or namespaced types. Code that doesn’t use auto is simply primitive c++. Come into the future