Not than I.

In their defense, smart pointers are of all tools available to developers but not everyone can adapt to a certain tool. Actually remapping mental model and using smart pointers everywhere in the codebase may be troublesome especially if working on a large project with multiple people in collaboration.

so just "above average pointers"

My profesor once said that strings are more complicated than a certain fraction of people present at an undisclosed meeting.

1 bjarne == 100 programmers

You still run into not knowing if deeply nested functions (within a library you didn't write for example) ever try to drop.

​@@loading_wait Most library authors know that pointer can come from new/new[]/pmr/malloc()/stack and therefore it CAN'T be deleted unless they themselves allocated it. And by "most" I mean "probably everyone beside authors of the libs that are used by Low Level Learning and loading_wait, definitely everyone in my last 2 decades of using c++ and not hitting this problem even once" I had more troubles with implicit intfloat conversion than with not knowing if somebody decided to call delete for no apparent reason. This video is bad. Its takes are bad. SeanCline below explained very well how to use.

If the library you're using is written in modern C++ it should be OK since they should follow the core guidelines. The problems arise when you have to call a C library in that case check the doc. But I guess in general, if your gut tells you this function might do something fishy, check the doc.

It’s always best to follow the guidelines

@@loading_wait true but it's fine if you know that's not your case. It also doesn't seem worth it for me to safeguard against the future possibility if it's not expected.

Really helpful explanation

Was looking for this comment. Use references to keep ownership just like in Rust

Yeah, Bjarne's a big advocate of references and their reduction of complexity. Don't give admin controls to any function/object that doesn't need it.

Totally agree with this explanation. We don't need add complexity when it can be avoided and still get the same result.

I was curious about why not use pass by reference. This comment explains everything.

While the overhead is there, its usually the most insignificant detail, (unless you're dealing with multi-threading, but the standard smart pointers aren't helpful in any of those cases anyway) but yes using a shared pointer like this is not really correct, usually a shared pointer is for complex scenarios where you can't be sure of when the pointer should be freed because of all the things that depend on a valid value, containers being one of the most useful cases.

There's also span, mdspan, and string_view, so there's even less incentive now to touch raw pointers now for things that smart pointers can't do well. There's also out_ptr and inout_ptr to assist the smart pointers.

I have a better one: Never use raw pointers

@@Megalcristo2 You still have to use them for non-owning single instances in memory.

@@Spartan322 You can use references for that. If by memory you mean the heap, then you better use the "ownership" concept. Maybe "never" is a strong word there are some situations where they are still useful, like observer pattern or handling dynamic memory within a static variable (although I would personally still use smart pointers here)

@@Megalcristo2 Biggest cases and why you can't really use references is when you need to also return an empty pointer and your class doesn't or can't have a tombstone state. (which usually you don't want if your class consumes more then a pointer size of memory on construction anyway)

Heaphone guy metal571 also in low level programming ?? Damn the world is small :)

Yeah this is my full time real job of being a C, C++, and Python senior software engineer

Shared ptrs in general aren't bad design. But using them like this definitely is. You basically only want to pass a shared pointer to a function like this if it then saves that shared pointer somewhere (like in a vector) but you still want the original location to also own it (Though even in those cases using weak_ptr might be more useful)

@@sinom Nope, shared_ptr in general is a sign of a bad design. It makes lifetimes unclear, which makes it harder to reason about your code. Always avoid shared_ptr and prefer unique_ptr. You should only use it when there is no other option. You often see new C++ programmers slap a shared_ptr on everything, while the seasoned C++ professionals pretty much only use unique_ptr.

@@sinom​​⁠​⁠​⁠might also add that you can use shared ptrs multiple places but also want to pass it as an argument to a method that does not have the intention of sharing ownership. In that case you would use a const ref shared ptr though. A const raw pointer can also be passed using .get() but will require the whole method to be const, while the const ref shared ptr does not.

I noticed that too. The correct syntax would be `sizeof(*somepointer);`.

There's also a huge lack of #includes and declarations there...

is this even correct? Dog is not a pointer now and how do you call -> on it?

@@anon1963 there is a typo in his comment, *dog* is not a *pointer* but a *reference* ... so you can use *.* to access each member void do_thing_with_dog(const Dog& dog) { dog.bark(); }

LOL the lack of declarations for auth and service sold it for me, and then the lack of #includes as well...

This video makes it seem harder and more error prone. You should check other videos to see that it is not that hard and it is pretty safe if you know what you are doing. I know c/c++ can have memory leak issues but unique_ptr actualy solves most of the problems

When a unique pointer is moved it becomes a null pointer( it stops pointing to the original memory but to the address 0x0000). Additionaly 99% of times you wouldn't move a unique_pointer but pass it by reference

he is not using the pointers very properly...

"std::clannad_ptr" makes me want to cry.

If you are not transferring ownership, unique_ptr should have the same performance than raw pointers when optimizations are enabled.

@@elcugo I guess, but why do things the way way when I could do them my way? 😉

It's usually a pass by copy but unique_ptr can't be copied only moved. That's why std::move is required to pass it, it casts the value into an x value expression (somewhat similar to r value expressions in C but with a few differences), allowing the copy to instead call the move constructor. In general move should only be used when you want to transfer ownership over stuff. In general it's less expensive than a copy but can be more expensive than just using a reference. If in C++ you want to signify something is a reference you can either use pointers like in C (T* param) if you want it to be a nullable reference or use the & symbol instead to say it is a non nullable reference (T& param). Non nullable references can be used without having to dereference the parameters while nullable references (pointers) need to be dereferenced (arrow, *, etc.) (And ofc they should always be null checked in the function since they imply you can pass a nullptr into that function without issues. Pass by reference means it isn't null checked since you can't pass null by reference on accident)

@@sinom but I’m talking about the original function when it’s just a pointer and the last line *delete* is called. It wasn’t compiled or ran so I’m just not sure that would work. Again, totally get the point that the video is getting at, but, like you also explained, it would just send a copy which wouldn’t cause a bug.

@@sinom code that uses std::move can be written without it and needs to be refactored passing unique_ptr by value and returning the same object in the function is the stupidest thing I've ever seen in my life, this video was biased and showed that the language allows this but it would be solved by passing the object itself as a reference or const reference no c++ programmer who knows smart pointers would do what he did

You can dealloc the memory. You just can't NULL the pointer that the caller has unless you double indirect.

@@ezekieloruven ah yes. That’s right.

Just pass a const reference

Just pass a const T&

No. This video really isn't doing a lot of stuff correctly. If you want to pass a unique_ptr to a function you need to ask yourself. Do you want that function to then own that unique_ptr or does it not need to own it at all. Ownership is usually only relevant if e.g. you're then gonna add it to a vector, member of some struct etc. if like this you just want to call a function on that object in the unique_ptr then what you actually want to do is pass it by reference instead of value. so instead of using function(unique_ptr ptr) { ptr->do_something(); } you want to do function(unique_ptr& ptr) { ptr->do_something(); } (preferably even const ref if possible) No need for shared_ptr for simple stuff like this shared_ptr is only necessary when for example you have two different vectors that both need to have objects they share between them

They come with overhead when a shared pointer gets created or destroyed

Ah yes, the make no mistakes strategy of programming, why nobody thought of this.

​@elcugo it's why your operating systems and drivers work. Good habits work. However they require discipline and professionalism. Most managers have too much heart to fire the guys who have neither. Once again the fish rots from the head. Engineering is not easy. It is in fact detail oriented and hard. The first real computers were designed programmed and maintained by mechanical engineers and machinists... if they didn't hit their numbers on their lathe then the gun director track solution was wrong and that kamikaze killed you and everyone who screwed up the "program". They were properly motivated and their guns usually didn't miss if the radar was online and working properly. The make no mistakes approach works just fine for real engineers that build serious tech.

@@robmorgan1214 That's a lot of nonsense. People have been killed by engineering mistakes multiple times, millions of dollars lost for memory bugs. Bridges have fallen, rockets exploded. "Real engineers" build tolerances into their processes, because they know mistakes will happen. Important products gets tested by months before they get released. You are stupidly and dangerously wrong.

​@@robmorgan1214everyone makes mistakes, we're not machines

i noticed auth = malloc(sizeof auth) isntead of sizeof *auth almost immediatly

Plus, the `malloc` call being supplied a `sizeof(some_pointer_variable)` as its `size` parameter, causing it to allocate 8 bytes regardless of how large the `auth` struct actually is...

@@Uerdue I mean you could get around that by using the struct type name but maybe in this case the struct name is also auth, the full code isn't given so we can't be sure -_-

@@jlewwis1995 I can't think of any way to both typedef a struct and declare a variable of the same name in C. That's just gonna lead to compiler errors. The sizeof usage definitely appears wrong. It probably functions okay because malloc will probably allocate more than the 4 or 8 bytes (pointer size) due to it allocating pages.

Said "really good practice" is *REALLY GOOD PRACTICE* , it can be a reason others cuss you out for! Simply put, people often omit that word willy-nilly, which can cause significant errors if even one user of your code uses it.

also for the sake of readability everything in that while loop should be in its own function (named something like parseServiceCommandFromInuput [I too suck at function naming it is ligit one of the hardest things in programming]) if I were trying to understand what your app does I don't necessarily care what commands you're parsing for there for it would take less time for me to realize that is what you're doing if you just tell me that is what you're doing... also having common patterns like that in [well named] functions helps with debugging because if you follow the "functions only do one thing. And that one thing is only done in that function" rule that limits the number of places I would have to look for bugs...

men if rust is so damn good what are you doing here ? go and code in it

Yes but you cannot mutate data owned by the Rc references if ownership of the data is shared across multiple different Rc references.

men in c++ smart pointers were there before rust appeared on this earth so what sounds rust ? go and do some research men . this annoying rust you are second one who posted nonsense without doing any kind of research . rust is a shit in and out and it lacks tons of things . it doesn't evne let you do things without using shit impl / struct / trait combined . and without using stupid moronic & ' < > _ and moronic things it has . you are just bunch of web developers who never coded a shit in systems language so go and cry somewhere else : D if you like rust be quit here we are talking about c++ not about crap rust

lolz kids : D why are you bunch of rust clowns here doing ? go and code in that crap : D you think this is exists in c++ cause of rust shit ? in c++ smart pointers were there before rust shit appeared : D go and cry for your rust no one cares :D cuz its dumb and shit syntax and crap langauge where you need 15 mb for just hello world and compilation takes forever : D

This. Const correctness is vastly overlooked

It also prevents angry users who get errors out of nowhere (they would expect that a function which doesn't mutate anything would accept their const pointer, but no, the compiler just craps out).

unique_ptr came to the c++ STL before rust was even introduced. And may I ask, what do you think is so burdensome about it? Having to type 7 extra characters (as opposed to Box)? Otherwise the functionality is identical, readily available in the standard library, and even with extra features (that might not be present in rust or are behind its unsafe firewall). Regarding your ‘mimicking’, I think you might have gotten it the other way around.

@@mariansalam @mariansalam The quote's a meme, don't take it too literally. Though if you want to know why I personally prefer rust's approach, it is because it also gives compile-time checks for ownerships errors. This catches things like what is seen in the video at 4:30

​@@mariansalam Rust does not let you move the ownership of data or unique smart pointer inside a function while allowing usage of that data after the function has been called without compiler errors. That is the power C++ can only dream of, not the extra characters you don't need to type.

Yeah, I do that too, sadly there are a lot of people who would shun you off for even thinking about the word "g0t0"...

In C it's fine. however, you have better tools than spamming goto's in C++

@@anon1963 Wouldn't be so sure of that, with heap-allocated things ("new ...") you'd still need matching deallocations ("delete ..." or "delete[] ...").

@@erikkonstas smart pointers do just fine

Because that's way more logical than what you want... also, if you really want to misalign the pointer, you should be casting to (char *) (or its signed or unsigned variants) instead of (uintptr_t); the latter is for getting the address out of a pointer.

There are a few OS specific ways of doing it on Linux systems. You can definitely try one of those and see if your pointer is valid or not. But there's no standard way of doing it. So just write healthy code.

@@ohwow2074 Can you share a few of these? (the question is generally to the author so mentions its a good idea to check if the pointer is null *or freed/valid*)

@@01rnr01 here is a video: ukposts.info/have/v-deo/sHOpfWh-gHyVu6M.htmlsi=uYFd8mtbsOvweVgm And no. It's actually a bad and harmful idea to check pointers at runtime especially in release builds. The only exception to this is that you can and should always check for null pointers to make sure things are ok. That's good practice.

@@ohwow2074 That’s why I pointed it out in the first place ;)

not to mention any os level mechanism cannot accommodate for any kind of pool allocators, caching etc

in c++ i can do anything without using smart pointers ever . just using functions are enough to create anything . but can you do that in rust ? nope you need bunch of shitty stuff like & ' < > _ . without them you can do zilch nothing yet you have problems with c++ which lets you use whatever the heck do you want ? unlike clown rust ? who doesnt' even let you to have struct constructors inside of the struct itself ? yet lets you to use shitty garbage impl / struct / trait altogether ? LOLZ . yeah seems very sane for me : D shitty syntax like haskell : D every language i ever used has much better syntax than rust shitty . rust needs some syntax bettering cause its too shitty . rust needs rust++ with many more things and it could be used but now ? shitty in and out and garbage LOLZ . they have amde haskell like programming language and want us to use that shitty thing : D no thank you and you can have and use rust shit for everything you wish and want and no one gives a damn : D

But fast as fuck in comparison with python xd, isn’t that the point?

Unique pointers _are_ Rust's way (ownership and borrow semantics) but C++ just defaults to being unsafe for compatibility. Likewise, shared pointers are the same as using Rc in Rust. I definitely prefer the Rust syntax though it's way less verbose!

Rusts way includes compiler errors on such mistakes@@seabrookmx

@@seabrookmx The "Rust's way" happens at compile time without overhead during runtime unlike with C++ if you use smart pointers whose references will be counter during runtime. If you opt for speed by not using smart pointers with C++, you'll pay for it in terms of potential runtime crashes. If you explicitly use Rc in Rust, then you are on the same line with C++'s smart pointers in terms of speed. In Rust you still pay for the complexity of dealing with the borrow checker, which may or may not be a problem dependening on the developer.