This graph cuts off early. Once you learn that pointers are a trap for noobs that you should avoid outside really specific circumstances the line crosses zero and goes back into normal land.
C++ is unironically my favorite language, especially coding in python feels so ambiguous and you need to take care of so many special cases that just wouldn’t even exist in C++.
Typically, I can read an “average” open source programmers code. One of the issues I have with C++ is the standard library source seems to be completely incomprehensible.
I recently started learning rust, and the idea of being able to look at the standard library source to understand something without having to travel through 10 layers of abstraction was incredible to me.
Your graph also cuts out early. Eventually you want to get performance gains with multi-threading and concurrency, and then the line drops all the way into hell.
I’m not saying you can’t do multi-threading or concurrency in C++. The problem is that it’s far too easy to get data races or deadlocks by making subtle syntactical mistakes that the compiler doesn’t catch. pthreads does nothing to help with that.
If you don’t need to share any data across threads then sure, everything is easy, but I’ve never seen such a simple use case in my entire professional career.
All these people talking about “C++ is easy, just don’t use pointers!” must be writing the easiest applications of all time and also producing code that’s so inefficient they’d probably get performance gains by switching to Python.
I’ve been using C++ almost daily for the past 7 years and I haven’t found a use for shared_ptr, unique_ptr, etc. At what point does one stop being a noob?
Given that you probably are using pointers, and occasionally you are allocating memory, smart pointers handle deallocation for you. And yes, you can do it yourself but it is prone to errors and maybe sometimes you forget a case and memory doesn’t get deallocated and suddenly there is a leak in the program.
When you’re there, shared_ptr is used when you want to store the pointer in multiple locations, unique_ptr when you only want to have one instance of the pointer (you can move it around though).
Smart pointers are really really nice, I do recommend getting used to them (and all other features from c++11 forward).
Smart pointers are really really nice, I do recommend getting used to them (and all other features from c++11 forward).
You’re recommending him to give up his sanity and/or life?
This guy probably still uses a char*.
What have you been using it daily for? arduino development? I’m hoping no company still lives in pre C++17 middle ages.
well, if I have an object on the heap and I want a lot of things to use it at the same time, a shared_ptr is the first thing I reach for. If I have an object on the heap and I want to enforce that no one else but the current scope can use it, I always reach for a unique_ptr. Of course, I know you know all of this, you have used it almost daily for 7 years.
In my vision, I could use a raw pointer, but I would have to worry about the lifetime of every object that uses it and make sure that it is safe. I would rather be safe that those bugs probably won’t happen, and focus my thinking time on fixing other bugs. Not to mention that when using raw pointers the code might get more confusing, when I rather explicitly specify what I want the object lifetime to be just by using a smart pointer.
Of course, I don’t really care how you code your stuff, if you are comfortable in it. Though I am interested in your point of view in this. I don’t think I’ve come across many people that actually prefer using raw pointer on modern C++.
I just never learned smart pointers and write C++ code like it’s C for aesthetic reasons.
Shared poibters are used while multithreading, imagine that you have a process controller that starts and manages several threads which then run their own processes.
Some workflows might demand that an object is instantiated from the controller and then shared with one or several processes, or one of the processes might create the object and then send it back via callback, which then might get sent to several other processes.
If you do this with a race pointer, you might end in in a race condition of when to free that pointer and you will end up creating some sort of controller or wrapper around the pointer to manage which process is us8ng the object and when is time to free it. That’s a shared pointer, they made the wrapper for you. It manages an internal counter for every instance of the pointer and when that instance goes out of scope the counter goes down, when it reaches zero it gets deleted.
A unique pointer is for when, for whatever reason, you want processes to have exclusive access to the object. You might be interested in having the security that only a single process is interacting with the object because it doesn’t process well being manipulated from several processes at once. With a raw pointer you would need to code a wrapper that ensures ownership of the pointer and ways to transfer it so that you know which process has access to it at every moment.
In the example project I mentioned we used both shared and unique pointers, and that was in the first year of the job where I worked with c++. How was your job for you not to see the point of smart pointers after 7 years? All single threaded programs? Maybe you use some framework that makes the abstractions for you like Qt?
I hope these examples and explanations helped you see valid use cases.
First year programming in the late 90s … segmentation fault? I put printfs everywhere. Heh. You’d still get faults before the prints happened, such a pain to debug while learning. Though we weren’t really taught your point of the comment at the time.
Least that was my experience on an AIX system not sure if that was general or not, the crash before a print I mean.
