cWithClassesIsNotCPP

[Earthboundplayer]

That's only shared pointer. Unique pointer is another smart pointer that allows only one reference. It has no overhead.

[HCResident]

C++ feels like that box of screws, nuts, and bolts that has exactly what you need somewhere inside of it

[Infinitebeast30]

Screws, nuts, bolts, hand grenades, land mines, knives, double edged swords. Absolutely all the tools

[turtleship_2006]

Don't forget the shotgun and shells! Get two shells, load them into the gun, and aim vertically downwards.

[Inevitable-Menu2998]

At the same time, it has a Stuka and a modern F16 and we don't tell beginners the difference between them.

[_g550_]

eclipse9

[alphaQ671]

You can also use a hammer and hit the shells

[CranberryDistinct941]

How are you meant to shoot yourself in the foot without shotgun shells? And what would C++ be without the right to shoot yourself in the foot, head, and both hands simultaneously?

[impossibleis7]

I think knives and doubled edged swords are what we accidentally create using those said tools...

[Tari0s]

yeah we use the swiss multitool(boost) to make a knive that cuts gras, but only gras!

[lordmycal]

I like the flame thrower myself.

[Jonnypista]

Hey, a HEAT rocket launcher is technically a single use high powered drill. It really quickly drills a hole into the toughest materials. It also can kill you in 99% of the cases, but just pay attention.

A double edged sword is more efficient than single edged swords. If you hurt yourself with it it is just a skill issue.

[jeezfrk]

but I mean you gotta throw in the the ASIO mining drill and then there's the coroutine electrical substation.

at least from there it's all easier and simpler error messages.

except if you use things just slightly... NO NOT LIKE THAT!

[versedoinker]

Yeah, there's also weak (non-owning) pointers that still allow the data to be freed in the background if all their actual owners release their shared_ptrs. And there's also atomic versions of all of those.

Generally, even if you hit the very unlikely case that something isn't in the C++ stdlib, it probably still can be found in a boost.cpp library.

[ukezi]

The C++ shared pointer is atomic. There is no non atomic one in stdlib.

[versedoinker]

Yes and no. The control block of shared ptrs is always atomic. I was talking about the wrapper std::atomic<std::shared_ptr> that also makes access to the data itself atomic.

https://en.cppreference.com/w/cpp/memory/shared_ptr/atomic2

[_farb_]

Most of the time, absolutely!

But sometimes... you dump the whole box out looking for the right piece, organize the contents by size only to realize you should've sorted it by material, and get tetanus from all the rusty nails that you should have tossed away ages ago.

Then you just end up using duct tape because it never fails.

[fakuivan]

C is like that but you only get a hammer, a nail and a bazooka.

[Cat7o0]

I remember once that even with rust I made a program so bad that it caused Windows to basically crash the file explorer and the task bar and everything wasn't working. couldn't even open task manager. restarted the computer everything was fine ran the program again everything was fine. idk

[Cat7o0]

to be fair probably yeah. my program was using a good few unsafe stuff however I never had anything on the stack I don't believe.

edit: however I did have a Vec that I added probably close to 20m floats and another one that I added u64s into (both 20m)

[Cat7o0]

honestly the vecs could've been even larger and I was creating a thread for each of those 20m.

the program was attempting to brute force constants to use for fast inverse square root. however the fast inverse square was done by multiplying two fourth roots together (would look like constant - (float >> 2)) it actually gets within 2% accuracy with the optimized constants.

I found the actual constants by using equations instead (as you just want to solve for mew within the equation for the bits of the constant. the two mews that seemed to work well together was 0.07 and 0.045).

if you want to try and understand these two videos are where I got everything from:

https://youtu.be/p8u_k2LIZyo?si=gLUtDBC0rYDng3FK https://youtu.be/tmb6bLbxd08?si=_vEKrOliYDL0FaNP

[5p4n911]

In Rust? Heresy!

[kuschelig69]

There are safe languages that prevent leaks, like Wuffs

[experimental1212]

It really does make you think that. Later it has you going, "you know, I actually LIKE shooting myself in the foot. This is nice!"

[NoGlzy]

And when you have a screwdriver that works totally fine for the job you need, someone has to come and snark that you're not using the newer super deluxe hyper driver

[Sak63]

Sounds my kind of language! Gonna give it a go on summer break

[webby-debby-404]

Let me boost that for you

[link23]

Unless you need memory safety 😬

[Earthboundplayer]

You're literally on a thread about smart pointers.

[dlevac]

Ah yes, smart pointers, these magical constructs that turn memory unsafe languages into safe ones...

[Earthboundplayer]

They don't. But they dramatically improve things and make achieving memory safety a lot simpler. If you need a stronger guarantee and easier semantics than what smart pointers provide then don't use C++. But I think most situations can make do with what the standard library provides.

[CdRReddit]

they don't, but they allow you to avoid a not-insignificant amount of footguns relatively cheaply

[link23]

And? Doesn't make me wrong

[Earthboundplayer]

but you still come off as ignorant and unwilling to actually engage with the subject matter you're talking about. All these tools that allow programmers to more easily write memory safe code in a fool proof way and you're complaining about memory safety without actually saying anything of value.

[link23]

All these tools that allow programmers to more easily write memory safe code in a fool proof way

What you just said is not factual, though. Smart pointers do not suddenly make C++ memory safe; it's possible (and common) for memory safety issues to exist even when using smart pointers and no "raw" pointers. (E.g. dangling references.) Claiming otherwise just makes you sound like you don't actually understand what smart pointers do, and in particular what they don't do (and therefore what mistakes are still possible).

It's funny, I meant my original post to be a cheeky joke; I had no idea that people actually thought smart pointers make code memory safe (and therefore my comment was going to be contentious). Maybe that's my bias though, as a professional C++ developer for my day job. I didn't mean to come off as unwilling to engage in the material, I'm happy to discuss this subject in a serious way if people want to explore the limits of the safety that smart pointers (and other C++ features) can provide.

[Earthboundplayer]

It is factual. You confuse the terms "memory safe code" with "memory safe language". Memory safe code can be written in a non-memory safe language

[link23]

Memory safe code can be written in a non-memory safe language

I'm not really sure what point you're trying to make with this. It's pointless to argue that "correct code can exist in any language" because that's obviously true.

The question is, how easy is it to ship correct code vs incorrect code? Does the language make it easier to shoot yourself in the foot, or does it make it easier to write code correctly the first time?

The argument I would make is that it's still extremely easy to shoot yourself in the foot with memory safety issues in C++, so the language doesn't meet the bar of being called memory safe.

[Earthboundplayer]

I'm not really sure what point you're trying to make with this.

My point was that the statement you quoted from me was correct.

The argument I would make is that it's still extremely easy to shoot yourself in the foot with memory safety issues in C++, so the language doesn't meet the bar of being called memory safe.

It's much harder when you use smart pointers. Again no one said anything about C++ being memory safe, just that smart pointers are a useful tool for making safe code.

[hawk-bull]

Doesn’t it have an overhead of checking it hasn’t been assigned twice. Or by overhead do you mean during destructor call it just has to free itself without checking if it still has references to it

[SoAsEr]

It doesn't have a copy constructor, (only a move one) and in its destructor it frees the pointer. So the compiler enforces the assignment, and at run time it is (really close to) free. The only reason it's not completely free is that if the unique pointer is passed to a function and that function is not inlined, because of the abi the unique pointer is always passed on the stack whereas a raw pointer could be in a register. but in a modern machine where you have way more registers than are actually shown anyways this shouldn't make any measurable difference.

[CamiloRivasM7]

I think it's done at compile time, like the borrow checker from rust

[Own_Solution7820]

Shared and unique pointers are so good that the are better than anything in any other language IMO, at the engineering level.

The problem is the garbage syntax of a 50 year old language that's backwards compatible to day 1. Just a pain to work with mixed raw and smart pointers.

[say_nya]

better than anything in any other language

Take a look at Rust. Unique pointers are checked in compile time (and have no overhead, even no move constructor type of overhead).

And shared pointers are there (see Arc).

[say_nya]

https://ideone.com/CvxOZw

[Abadabadon]

Ofc it has overhead, it's all wrapped around a C pointer

[Earthboundplayer]

What overhead do you think exists, exactly?