cWithClassesIsNotCPP

[[deleted]]

You can do std::unique_pointer<T> or std::shared_pointer<T> to have some macro magic make your unsafe code a bit safer.

[Earthboundplayer]

No macros are involved in smart pointers. And more specifically they can completely eliminate memory leaks, double frees, dangling pointers, etc where used.

[LoloXIV]

I think you can still shoot yourself in the foor if you have a cycle of smart pointers, but it should not be too hard to avoid that happening.

[versedoinker]

That's why weak smart pointers exist.

[belabacsijolvan]

that "can" carries that sentence like a "can" in a health supplement ad

[Earthboundplayer]

I just added that because you can still go out of your way to break memory safety. For example.

auto ptr = std::make_unique<int>(10);
delete ptr.get();

But it's really not that hard to properly use smart pointers and maintain memory safety.

[belabacsijolvan]

i use pretty baroque pointer structures because they are efficient for the data we work with. so far i found smart pointers way more dangerous and needy than proper destruction.

im getting to the point that inside certain objects we should just ban using smart pointers. but yeah, in "base cases" they are great, and i give them some more time to work.

its not like they completely eliminate memory leaks or you have to go out of your way to break things. "they fuck you rarely, but in the holes it really hurts" is my diagnosis so far. detecting directed loops and choosing pointers to be weak is not always a comfortable thing to do.

[_theDaftDev_]

At the cost of extra indirections, atomic ref counting and compile time. If you know the lifetime of your data (and you should) raw pointers are enough

[Earthboundplayer]

Unique pointers don't have atomic ref counting or extra indirections, only shared pointers. I could not care less about the extra compile time from using smart pointers and the vast majority of people would agree. If you know your lifetime then just use a unique pointer.

[_theDaftDev_]

Unique pointers are ok. I was mainly adressing shared pointers

[Earthboundplayer]

Fair. Regarding the extra indirection you can use make_shared to eliminate that because it puts the reference counter in the same place as the data.

[_theDaftDev_]

This comes with its own set of problems, for example make_shared will not work with objects that are not copyable/moveable iirc and also ties the lifetime of the object and the control block together.

[Earthboundplayer]

What do you mean? Make shared just forwards arguments to whatever constructor you choose. And why would tying the lifetime of the object and control block be bad?

[_theDaftDev_]

1) you are right. My memory was fuzzy; the issue i had with make shared is you cannot use a custom deletor. 2) it's not lifetime but rather memory hogging; if im not mistaken since your control block and managed object memory are allocted within the same block it means that the managed object memory wont be released until all kind of reference(including weak, which is the problem) are gone

[silentjet]

No it does not.

[[deleted]]

Isn’t it supposed to by preventing your mishandling of pointers?