Juliean said:
It doesn't add anything of value

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.

For people who are new to your code, it is very valuable to have the types spelled out for you; it is a lot less time spent inferring things and spelling out the type makes the learning process easier since you can just click it and hit F12 to go to the class definition and freely continue your learning experience. Obstructions to the learning experience add up and it’s unfair to discount the value of explicit types just because you won’t have to go through that learning experience. If I am trying to fix a bug in an algorithm I didn’t create, it is extremely helpful to easily see at a glance the signs and number of bits in each type so that I can more easily recognize potential discrepancies and spend more time focusing on the algorithm rather than maintaining a mental database of information that should have already been clearly spelled out.

It is incorrect to “never use auto,” but it’s probably more incorrect to “freely use auto.” auto should be used sparingly and only when it actually improves readability of the code, which is mostly when it can be used to replace long type names such as STL iterators or when a variable might change types between different builds and would require some #ifdef clutter otherwise. These are tangible decreases in clutter that justify the obfuscation introduced by auto. “Entity” or “float” or “uint32_t” aren’t enough clutter to justify the obfuscation.


L. Spiro

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