<blockquote>
Learning C++ was one of the most challenging and rewarding parts of my journey as a student. But like many others, I jumped into it without a few key things. That led to countless hours lost to confusing compilation errors (segmentation faults became my old enemy!!) and frustrating debugging sessions.
</blockquote>
Here are the five lessons I wish I had learned earlier.
<hr>
<h2>1. Understanding Pointers Takes Time (And That’s okay)</h2>
When you’re first learning pointers, you’re told this classic line:
<blockquote>
“A pointer is a variable that stores memory address of another variable”.
</blockquote>
Sure, sounds simple until the <code>*</code> and <code>&amp;</code> comes into play and makes you rethink your choices.
Try to reference a memory address that doesn’t exists.
Here’s the deal:
<ul>
<li><code>&amp;</code> is the address-of operator, it gives the memory address of a variable.</li>
<li><code>*</code> is the dereference operator, it lets you access the value stored at a memory address.</li>
</ul>
Now the tricky part is knowing when to reference and when to dereference. Most pointer-related errors happens because you:
<ul>
<li>Try to dereference a pointer that points nowhere (<code>nullptr</code>).</li>
<li>Try to reference a memory address that doesn’t exists.</li>
</ul>
<h4>The Warehouse Analogy That Helped Me</h4>
Think of your computer’s memory as a big warehouse.
<ul>
<li>Variables, objects and data are items on shelves, each with a unique address.</li>
<li>A pointer is like a warehouse worker who doesn’t carry the item, they just know where it is.</li>
</ul>
When you use <code>&amp;</code>, you’re asking:
<blockquote>
“Hey, what shelf is this item on?”
</blockquote>
And when you use <code>*</code>, you’re asking:
<blockquote>
“What’s sitting on this shelf?”
</blockquote>
Now imagine asking your warehouse worker to grab something from the shelf that’s either empty or doesn’t exist anymore. That’s exactly what happens when you dereference an invalid pointer, you get undefined behavior, or more commonly, a segmentation fault.
<hr>
<h2>2. The Standard Library Is Your Best Friend</h2>
One of the biggest mistakes I made was not understanding and learning the tools that the C++ Standard Library provided. Now we understand <code>std::vector</code>, <code>std::map</code> and maybe even <code>std::set</code>, but there is much more the STL provides, some of them are:
<ul>
<li><code>std::multimap</code>, <code>std::multiset</code>, <code>std::unordered_map</code>, <code>std::unordered_set</code></li>
<li><code>std::pair</code>, <code>std::tuple</code></li>
<li>The <code>&lt;algorithm&gt;</code> header which contains various useful functions like, <code>std::sort</code>, <code>std::transform</code>, <code>std::remove</code> etc…</li>
</ul>
The main reasons to use STL is because the methods it provides are,
<ul>
<li>Highly optimized.</li>
<li>Very Flexible.</li>
<li>Provides a much cleaner interface.</li>
<li>Saves a lot of time.</li>
</ul>
Investing time in understanding the different features of the STL, truly will save you a lot of time and energy while working with different problems.
<hr>
<h2>3. Compilation Errors Are a Learning Tool</h2>
C++ error messages are known to be notoriously complicated and daunting to read through, especially template errors. But there are actually a lot of things you can learn from those error messages and actually use them to debug the error. It all matters to looking at the right place.
You might be wondering, how can errors even be useful? And that is a valid point, how can something that didn’t go or run as expected be good or useful. But the thing is that when our program runs into an error there are couple of benefits to it especially when talking about C++,
<ul>
<li>They help spot the bug (obviously)</li>
<li>For template errors, they actually allow us to detect the template related errors which are not detected by our code editors given the generic nature of templates.</li>
<li>For segmentation faults, they allow to spot potential leaks which we are luckily able to spot, because segmentation faults are not some fixed patterns, they can happen anywhere if memory is not managed properly somewhere.</li>
</ul>
In-order to use errors messages, go all the way to the top (at the beginning) of the error message there you will see a clear stack of different files from where error is being evoked and that is really helpful to spot from which file and line did the error actually emerge.
And also some instructions are given for the reasons for why the error is happening which can be really helpful while debugging. If you will also try to read closely you will find some methods where being called internally and they failed, for example when using <code>std::unique_ptr</code> if we try to copy such a <code>std::unique_ptr</code>, then we would get some logs like calling an explicitly deleted constructor, which means we are calling a copy constructor which is not allowed in <code>std::unique_ptr</code>.
So the point is, if your fundamentals are clear about the features you use in C++, the errors will start to make some sense. But still C++ errors are not the most intuitive things to look at, so its okay to feel confused when looking at them.
<hr>
<h2>4. Don’t Ignore Memory Management</h2>
Coming from languages like Python or JavaScript, one doesn’t have to worry much about memory much. But in C++, you have to.
One of the great features of C++ and what makes it so powerful is the immense level control it gives to user over the memory, using which very memory efficient application can created (and are created!), but with that being said we all know that famous line,
<blockquote>
With Great Power Comes Great Responsibility.
</blockquote>
If you don’t manage you memory properly, not only will you waste resources but will introduce memory leaks and tracing and fixing memory leaks is no trivial task.
Here are few ways and good practices to manage memory properly in C++,
<ul>
<li>Understand RAII (super important!)</li>
<li>Understand stack vs heap memory</li>
<li>Avoid raw pointers wherever possible and use smart pointers.</li>
<li>Use STL containers and methods.</li>
<li>If you using raw pointers make sure to delete that memory when it goes out of scope using the <code>delete</code> keyword.</li>
<li>Don’t mix <code>new/delete</code> with <code>malloc/free</code>, they work very differently.</li>
</ul>
<hr>
<h2>5. You Don’t Need to Master Everything At Once.</h2>
Trying to learn every feature, template, lambdas, multi-threading, all at once will burn you out. Focus on writing small programs. Use what is required by those programs and slowly build the muscle memory first.
When I was learning C++, I was also tempted to write that advanced level of code, where you use lambdas, templates etc, all the cool stuff that you see in existing C++ code bases for applications. As a result I tried to force myself to use this advanced features in relatively simpler application where a simple solution would be optimal, resulting in over-complicating the relatively simple program.
So here’s the thumb rule that I stick to,
<blockquote>
“The deeper and complex stuff will make more sense when you need it”.
</blockquote>
For example, I had this temptation to write such template based function which can be generic and can pass in callbacks (lambdas) and take n number of parameters of different types. And at the beginning I didn’t find a place where such an implementation was really required but, when I was working on a multi-threaded application ones, I had to implement my own thread-pool, so there I had to create a function which would take in a callback and that callback can have n number of parameters of different type, and that callback had to be registered to the thread pool.
So the point is that every single features exists for a specific use case and you will know when you need it and you will be required to use it, so rush on using the advanced features where its not needed, in complex projects you will have plenty of opportunities to use them.
<hr>
<h2>Final Thoughts</h2>
C++ is hard, but that’s also why it’s beautiful. It forces you to understand what’s happening under the hood. And once things start to click, its incredibly empowering.
If you’re just starting out: take it slow, embrace the STL and don’t fear error messages, they’re teachers in disguise. You’re not alone, we’ve all been confused too.
Now if you read till this point, rest assured because you are well on your way to becoming an C++ addict (like me!!).
Let me know if you’re also learning C++, I’d love to hear what you’re struggling with or what helped you!

This is the place to discuss everything about C/C++ and Assembly —from basic programming concepts to advanced topics like memory management, concurrency, and performance optimization. Share knowledge, ask questions, and collaborate with developers.

C/C++ Community

Learning C++ can be challenging, especially without understanding key concepts like pointers, memory management, and the standard library. Effective error message interpretation and gradual learning of language features are crucial for mastering C++.

"5 Things I Wish I Knew Before Learning C++"

I extend my profound gratitude for your erudite contributions in elucidating the intricacies of C++, while adroitly guiding learners away from superfluous or obfuscatory practices—your sagacious mentorship is an indispensable boon to the community