And even the presented fix hurts my eyes. Should have used a
unique_ptr
oroptional
.Exactly, raw pointers are very rarely the way to go
You’d be missing the whole point too if you think that the pointer is the root cause. The problem is that the class is not designed to be copy-able, let alone moveable. Your suggestion to use a
unique_ptr
will also blow up in your face the moment you try to copy an instance.Depends on what semantic you want. Sure, if you use a
unique_ptr
member, you will get a deleted copy constructor/operator - I wouldn’t consider that blowing up in my face.deleted by creator
I got stuck on cheese counting:
inventory.count(cheeseName) == 1 ? "Yes" : "No"
1 cheese == some, 2 cheese == none :/
Yeah, that’s confusing to read. A hashset can only contain at most one of each cheese kind, in c++20 you can write
inventory.contains(cheeseName)
, before that you had to use.count
orinventory.find(cheeseName) != inventory.end()
or something like that
Naked pointers are just too stupid for modern C++ ;)
Naked pointers are just too stupid for modern C++ ;)
Anyone who works on real-world production software written in C++ knows for a fact that pointers are a reality.
Also, there are plenty of frameworks who employ their own memory management frameworks, and raw pointers are perfectly fine in that context. For example, Qt uses raw pointers extensively because It’s object system implements an object ownership system where each object can have child and parents, and you can simply invoke
deleteLater()
to free the whole dependency tree when you no longer need it.Your reply is an amazing mix of condescension and not getting the point.
I’m having it framed.
stares longingly at Rust book on shelf
Avoid Cpp period.
You’re making a very poor example by subscribing to !cpp@programming.dev
Also avoid /c/cpp