also the idea of a custom deleter embedded in a unique_ptr seems fucking crazy to me idk custom allocators are a huge pain in c++ anyway and I only recently started adding them in a couple places
-
-
more commonly I was just using my own set of containers that operated on objects that didn't need to have destructors called, and can be memcpy'd. c++20 concepts make it impossible for me to accidentally put an incompatible type into one of those, so there's that as well
1 reply 0 retweets 1 like -
Replying to @TylerGlaiel @cmuratori
It's perfectly fine to use your own containers. That's still RAII.
1 reply 0 retweets 0 likes -
My main annoyance about std:: containers is that their reallocation process is "Allocate" "Copy (either by moving each element, or memcpy the block if trivially constructible)" "I deallocate old". If allocators supported reallocate, then I could be smart about alloc location.
1 reply 0 retweets 0 likes -
That's not really an issue for what I typically work on, but, if it was, then I'd say "Sure, make your own container". Still RAII. The problem is when people don't use a container, and hand-roll raw-malloc/free all over their application logic.
2 replies 0 retweets 0 likes -
Replying to @scottmichaud @cmuratori
"and hand-roll raw-malloc/free all over their application logic" idk I think this is a strawman, I see this in C libraries sometimes, almost never in C++ libraries
2 replies 0 retweets 0 likes -
cause all you need to avoid that in 99% of cases is to just use some kind of container
1 reply 0 retweets 0 likes -
Replying to @TylerGlaiel @cmuratori
I think we might have different ideas of what RAII is. I just mean, like, have a container that manages resources, and put that container as a by-value member (or use directly). (See: Red arrow) It could be a std:: container. It could be your own container. Doesn't matter.pic.twitter.com/JZnHBobu1m
2 replies 0 retweets 0 likes -
Replying to @scottmichaud @cmuratori
reading the wikipedia article makes it sound like its a little more specific than just "constructors and destructors exist"
1 reply 0 retweets 0 likes -
Replying to @TylerGlaiel @cmuratori
My usage, and the usage that I've seen thus far, is basically just "constructors and destructors exist" (and the impact it has on by-value variables -- class members are destroyed in reverse-order, etc.).
1 reply 0 retweets 1 like
Right, and this is not good.
-
-
If you have a per-member destructor, something has gone wrong. Anything a computer does one-by-one means the architecture has failed, unless there is literally only one of that thing ever :)
2 replies 0 retweets 8 likes -
Replying to @cmuratori @scottmichaud
yeah I remember adding an allocator into the one system I had that had a ton of creation+destruction of objects (animation) years ago, noticing no difference in performance, and just going back to malloc again...
1 reply 0 retweets 0 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.