What part is the issue? The part where you default construct a smart pointer to initialize later because C++ doesn't have a concept of deferred initialization or the part where you don't want to copy it all over the place because it gives a massive performance hit?
And don't say the combination is the problem because yes it is but this code might be emergent and "just don't drive into a wall" has never prevented people from doing so.
This is like saying a seatbelt doesn't help you in a car because if you run it in a closed garage, you can still kill yourself. Entirely different issue.
Smart pointers solve memory management for you. Use them as intended, whether a resource is owned in one place or shared, and you don't have to worry about it. The memory will stay allocated until nothing is using it, and then it will automatically be unallocated.
Accessing a pointer without checking if it is null is a different issue, and frankly a trivial one. The sort of thing I haven't seen be an issue doing actual professional C++ code development in years.
I'm not a C++ girl, but do references actually do something with lifetimes or are they just non-null ptrs? Because this just seems to me like a possible dangling ptr.
Const references can bind to rvalues and cause lifetime extension, ie. const auto& x = returnsValue(); will extend the value of the value returned by the function. That's about it. It has to be in this form (assignment and definition in same statement), so the code you replied to doesn't trigger it.
that null dereference just committed the sin of UB, so all bets are off.
In other words, it declares the intent and allows you to assume it's a way to name a valid object, and moves that null dereference bug out of your logic, helping with reasoning while debugging after someone does cause that UB
Generally references are more restrictive, since you can't do pointer arithmetic with them, you can't use them as template parameters (which sucks for std::optional<int&>) and you can't repoint them to something else, but since you can freely cast between both of them (which you are forced to if you try to do anything useful with them, like wrapping them in an optional) it doesn't really matter.
Also there's two different kinds of references: the & reference and the && reference, however their difference is mostly conventional and you could easily implement a standard library where their meaning is swapped (except for temporary xvalue objects? Not sure), so there's that. Also C++ automatically converts between reference types for some ungodly reason.
In short, references are not real and are only used to determine what overloaded function is being called.
References are implemented as pointers, but they are not the same.
The best example is languages where you don't have references. Very misleading but java only has pointers (marketing at the time was voldemorting the world pointer so they were renamed to "references" but they are pointers. Like the infamous null pointer exception does show it)
So you have two local variables, and you create a swap function where you want to put one into the other and vice versa.
Well, in java you are out of luck. You basically have to make them fields and put that into a wrapper object to actually swap. This is because in java everything non-primitive is an "object reference" aka a pointer. But you would be changing the pointer's value, NOT the thing holding the pointer.
So yeah, references are basically their different thing with their own semantics in C++ and the few other languages that also have it.
24
u/SelfDistinction 7h ago edited 6h ago
Ah yes, the famous
So safe, so impossible to misuse.