To answer your question: I don't want to care about memory deallocation point when I can't. I only use shared_pointer, when what I want is for two different and unpredictable processes running independently needs to share the same memory, and I want to delete the memory when they are both done. I could invent a home rolled mechanism for doing this of course. But that is exactly what shared pointer is. What is an anti pattern, is using shared pointer when you do know the life time of the object. I'll typically only pass references to all functions doing stuff, and the top level of a process keeps the shared pointer. It's a tool, not to be used for everything, but for precisely the situation where you can't detect the point in time of deletion by easy means, and would have to invent a similar tool to do it.
If you're making a single threaded desktop game, there is indeed never a good reason to use shared pointers. If you're making a shared server type environment, there are potentially many times you want to share particular pieces of data across independently running tasks of some kind. Often, a better choice is to copy the data. But sometimes that is not a good choice and you want to share it, and delete when done. It happens.
7:01 So, not quite a cpp dev, but I do a lot of work in one cpp project. We have a UI, and do a far bit of data processing in the project. For the UI stuff, performance generally does not matter a ton, so it is really nice to be able to use shared/unique/etc pointers to speed up development there. Then in the performance critical areas, we can manage memory manually. It gives us many of the advantages of something like Java, without giving up most of the performance of C where we need it.
automatic storage in a function means it's a stack allocated. This is normally indicated by the "auto" keyword, which is implicit if you don't give it a storage type (other storage types would be "static", "extern", "thread_local" and "register") not to be confused by the "auto" keyword to infer the type, in C++, if you use auto with a type it's the storage type (no reason to ever use the "auto" keyword as a storage type though, that's a remnant from old C)
yes, it encorages you to do small allocation on heap, instead i prefer to allocate in bulk depend on life time then relase all of them at one, allocation is now simply a free list or an arena, and each system OWN all objects if outside want to refer to that object i give them a handle so i can always check if handle is valid and i can move memory around freely
Even if you create it as shared_ptr, you'd be plain stupid to PASS it as shared_ptr to everything. Pretty sure even the "official" coding guideline will tell you to pass it as reference or raw pointer to simple functions calls. Do not pass or share ownership when you already KNOW that the reference won't outlive the original (true for pretty much every function that is not async or stores a copy for later). Obviously that also means that if your ownership is properly managed in a way where you already know that no reference outlives the owner, it should never be a shared_ptr to begin with. The "do you like x-pointer" or "use what you like" is just.. just no. Use the CORRECT type for your usage. That choice has nothing to do with taste or "vibes", but understanding the purpose of the different pointer types. It's like saying "do you prefer forks or knives.. or do you rather use spoons". If you use a fork to eat soup, don't be surprised to get some weird looks.
It is evil. Use it sparingly like you would summon a demon to destroy your enemies, but not get over arrogant, cause this is how you loose control. It's a tool to be used. Btw, I use a summoning circle with goat blood and salt.
cakez is slowly becoming ZePrimeAgen
Slowly?
Without the netflix btw
@@sarthhakarora9696and without using vim btw
Cakez is lowkey a C dev at heart
I think I am bro^^
To answer your question: I don't want to care about memory deallocation point when I can't.
I only use shared_pointer, when what I want is for two different and unpredictable processes running independently needs to share the same memory, and I want to delete the memory when they are both done.
I could invent a home rolled mechanism for doing this of course. But that is exactly what shared pointer is.
What is an anti pattern, is using shared pointer when you do know the life time of the object.
I'll typically only pass references to all functions doing stuff, and the top level of a process keeps the shared pointer.
It's a tool, not to be used for everything, but for precisely the situation where you can't detect the point in time of deletion by easy means, and would have to invent a similar tool to do it.
If you're making a single threaded desktop game, there is indeed never a good reason to use shared pointers.
If you're making a shared server type environment, there are potentially many times you want to share particular pieces of data across independently running tasks of some kind.
Often, a better choice is to copy the data. But sometimes that is not a good choice and you want to share it, and delete when done.
It happens.
In expression such as `ptra = ptrb;` the left hand pointer is ptra and right hand pointer is ptrb.
That's what I thought as well. At the same time, I found comfort in the realization that other C++ devs also have brain farts sometimes.
7:01 So, not quite a cpp dev, but I do a lot of work in one cpp project. We have a UI, and do a far bit of data processing in the project. For the UI stuff, performance generally does not matter a ton, so it is really nice to be able to use shared/unique/etc pointers to speed up development there. Then in the performance critical areas, we can manage memory manually. It gives us many of the advantages of something like Java, without giving up most of the performance of C where we need it.
automatic storage in a function means it's a stack allocated. This is normally indicated by the "auto" keyword, which is implicit if you don't give it a storage type (other storage types would be "static", "extern", "thread_local" and "register")
not to be confused by the "auto" keyword to infer the type, in C++, if you use auto with a type it's the storage type (no reason to ever use the "auto" keyword as a storage type though, that's a remnant from old C)
I use C-standard pointers. I like to live dangerously, and I know how to manage my memory, so I don't need my hand held.
I'm building a Slab allocator to be used as a general allocator to my engine. It's fun!!
yes, it encorages you to do small allocation on heap, instead i prefer to allocate in bulk depend on life time then relase all of them at one, allocation is now simply a free list or an arena, and each system OWN all objects if outside want to refer to that object i give them a handle so i can always check if handle is valid and i can move memory around freely
Even if you create it as shared_ptr, you'd be plain stupid to PASS it as shared_ptr to everything. Pretty sure even the "official" coding guideline will tell you to pass it as reference or raw pointer to simple functions calls. Do not pass or share ownership when you already KNOW that the reference won't outlive the original (true for pretty much every function that is not async or stores a copy for later).
Obviously that also means that if your ownership is properly managed in a way where you already know that no reference outlives the owner, it should never be a shared_ptr to begin with.
The "do you like x-pointer" or "use what you like" is just.. just no. Use the CORRECT type for your usage. That choice has nothing to do with taste or "vibes", but understanding the purpose of the different pointer types. It's like saying "do you prefer forks or knives.. or do you rather use spoons". If you use a fork to eat soup, don't be surprised to get some weird looks.
It is evil. Use it sparingly like you would summon a demon to destroy your enemies, but not get over arrogant, cause this is how you loose control. It's a tool to be used. Btw, I use a summoning circle with goat blood and salt.
Love the videos
I agree
Stop zooming in your camera, that is overdone to death, twitch cookie-cutter.