As I'm sure it's many other people's case, I started learning C++ as part of one of my university courses (8 years ago already 🤯), and to be honest, it did get quite overwhelming at times! However, it was also astonishing and encouraging to see how many things one could do with it, so I ended up enjoying the class.
I used the language throughout my degree to solve various tasks, but it wasn't until my graduate life that I started making a heavy usage of it, mostly to write data analysis programs (which most of the time make use of ROOT) and Geant4 applications for the simulation of experimental setups.
However, I started noticing how I relied too much on stuff I had learnt long ago - and maybe not as rigorously as I should have - as a result of which my code always ended up full of patches, workarounds, bad style, ... in short, I was producing unmaintenable and very difficult to reuse or extend code.
So, I made up my mind and since a few months ago I'm focusing on reinforcing the concepts I already knew, learning new ones, applying new syntax and good practices, etc. and I figured out it would be a good idea to document part of that process here! I'll be posting some short articles as part of this series explaining what I learn along the way, and hopefully inspire some people and/or spark some nice discussions!
How does that sound? If you don't want to miss any of the articles, make sure to follow me!
Top comments (8)
Hey!
Modern C++ (== C++11 and greater) is clearly much more powerful and easy than old-school C++ (== C++03 and lower).
2 main things IMO?
autoand lambdas. Use them! A lot!I have written a few articles about C++20 if you are interested ;)
Indeed! I'll be talking about
autoon my next post :D And although I haven't found good uses for lambdas in my programs yet, I plan to talk about them at some point tooAnd thanks for dropping by! I'll definitely check your articles about C++20 :O
autos? I rarely use themFor any particular reason? I find them very convenient
I guess I just like explicit stuff. But the only time I use them are for iterators
There is one famous article by Herb Sutter about
autoand I highly recommend reading it: herbsutter.com/2013/08/12/gotw-94-...Scott Meyer dedicates a chapter of _Effective Modern C++ to
auto.Sutter's article is really good, but I have a few points about it.
1. Ensures variables will always be initialized
If you can remember to use auto, then you can remember to initialize variables as well :)
2. Auto helps to write code against interfaces, not implementations / We already ignore actual types all the time
Well, it's not the type that I care about, but rather how to use that type. For the
append_unqiuefunction, I don't care about the specific type, but I still care about the type. I need a container that works with those methods and helper functions.Another example:
But for things like iterators or lambdas, then I would agree, auto is better:
3. It guarantees that you will continue to use the correct exact type under maintenance as the code changes, and the variable’s type automatically tracks other functions’ and expressions’ types unless you explicitly said otherwise.
That's actually a good point I haven't considered before.
So really the only point is #3, but other than that, I don't see a practical reason to use auto.
Point 1 : you can remember to initialize values without
auto, but you can't forget to initialize them with it. That's quite not the same.OK, I have to admit: I almost never use
auto v = short{3}😆Furthermore, tools like clang-tidy warn me when a variable isn't initialized.
Point 2 : if your code is so long that you can't even remember what is
gridand why you are trying to iterate over it, then not usingautoseems quite a poor way to improve the overall function ;)I used to think the same as you are doing now, I (sort of) forced myself to use
autoat the beginning, and now I find code more readable in a case like this one. Also, I made a parallel betweenautoin C++ and Python, where (somehow) everything isauto. It's just a different way of thinking from traditional C++ or C.