The graph goes up for me when I find my comfortable little subset of C++ but goes back down when I encounter other people's comfortable little subset of C++ or when I find/remember another footgun I didn't know/forgot about.
That's one thing that always shocks me. You can have two people writing C++ and have them both not understand what the other is writing. C++ has soo many random and contradictory design patterns, that two people can literally use it as if it were 2 separate languages.
my comfortable little subset of C++
I also have one. I call it "C"
This comment smells like unix
Damm, C23 has a lot of changes. Some of them are really good, some of them I strongly dislike(keyword auto, addition of nullptr).
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.
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.
Yea, pointer arithmetic is cute but at this point the compiler can do it better - just type everything correctly and use
[]... and, whenever possible, pass by reference!Faust bless Stallman for creating GDB.
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).
At what point does one stop being a noob?
I recognize that trick question. For C++, the answer is always "soon".
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++.
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.
Do you still use raw pointers? You know they've discovered fire? (Jk coming from C I too havent learnt how to use smart pointers yet)
Smart pointers are like pointers, but without the same burden of having to worry about memory leaks.
pointers are fine, but when you learn about the preprocessor and templates and 75% of the STL it goes negative again
c++ templates are such a busted implementation of generics that if I didn't have context I'd assume they were bad on purpose like malbolge
Pointers are great for optional references.
But I need pointers for almost everything
Hot take, C is better then C++. It really just has one unique footgun, pointers, which can be avoided most of the time. C++ has lots of (smart)pointer related footguns, each with their own rules.
If you do C, and avoid pointers, do tell me what the point is using the language at all?
I mean if memory management is "the only way to shoot yourself in the foot" in C, then thats a quite big part of the language!
Then C++ what?
Yeah. My journey of love, loathing, hatred, adoration, and mild appreciation for C++, ended with the realization that 90% of the time I can get the job done in C with little hassle, and a consistent, predictable, trustworthy set of unholy abominations.
C++ literally makes it easier to avoid raw pointers and allocation that are dangerous…
Preach brother, I don't think that's a hot take at all. I've become almost twice as productive since moving from c++ to c. I think I made the change when I was looking into virtual destructors and I was thinking, "at what point am I solving a problem the language is creating?" Another good example of this is move semantics. It's only a solution to a problem the language invented.
My hot take: The general fear of pointers needs to die.
I'm not a fan of C++, but move semantics seem very clearly like a solution to a problem that C invented.
Though to be honest I could live with manual memory management. What I really don't understand is how anyone can bear to use C after rewriting the same monomorphic collection type for the 20th time.
The only conceivable way to avoid pointers in C is by using indices into arrays, which have the exact same set of problems that pointers do because array indexing and pointer dereferencing are the same thing. If anything array indexing is slightly worse, because the index doesn't carry a type.
Also you're ignoring a whole host of other problems in C. Most notably unions.
People say that "you only need to learn pointers", but that's not a real thing you can do. It's like saying it's easy to write correct brainfuck because the language spec is so small. The exact opposite is true.
What's wrong with c unions? I've never heard that complaint.
Eventually the line comes back in from the top.
Or perhaps it will come from the right? Undefined behaviour is the magic word
Integer underflow
C++: C with blackjack and 40 year old hookers. Anyway, only the rich can inherit diamonds or something. Or perhaps not, my memory is corrupted. I'm open to any pointers though...
Compared to Assembly language, C++ is fantastic! :-P
It's actually a lot worse than ASM, there are far more ambiguities in C++. And yet here I am, still developing with it some 30+ years later.
Don't worry, I'm using Rust were it makes sense.
Where does using Rust not make sense?
Just got a Commodore 64 and been having fun with ASM. I'm also weird. Don't be like me.
Assembly was my first language after BASIC - I know I'm weird, and I'm okay with that:-). Tbf it was for a calculator, so simplified. Any language ofc can go off the deep end in terms of complexity, or if you stick to the shallows it can be fairly simple to write a hello world program (though it took me a month to successfully do that for my calculator, learning on my own and with limited time spent on that task:-).
32 = JMP
96 = JMP Subroutine
Or is my memory defect 😁
Don't be like me.
Too late!
I like C# better. Ok, I'll see myself out.
Me too. If I can use it, I prefer C# — that is — if I’m not doing systems programming, I don’t have to worry about legacy code, and mainly I’m supporting Windows then it’s really quite cozy.
That's a solid description. I'm stealing that. "Cozy" is an excellent word for that sets C# apart from other languages.
I like C# too. I feel like I shouldn’t because of how Microsoft it is, but I can’t help but see it as a better put together/structured Java when I use it.
I feel the same, but to me, it's more understandable than the other C derivatives. I just understand it better. I've been thinking of diving into rust lately.
As someone who writes C++ every day for work, up to version C++20 now, I hate the incoming C++23 even more somehow. The idea of concepts, it just... gets worse and worse. Although structured binding in C++17 did actually help some with the syntax, to be fair.
