I'm probably not the first, but ...

template <typename T>
using $ = std::shared_ptr<T>;

I mean... C'mon!

These smart pointers are complete bullshit imo

@11000100111000 in general

@nitwhiz wait what
Why? They're super useful and used all over big C++ projects like LLVM.

@RememberMe @11000100111000 i think they say "look, i don't know what i'm doing!"

But i have to admit, i don't really work with cpp and i can see that these ptrs are pretty useful in big projects, maintained by multiple people..

..still, i just don't really like them :D

@nitwhiz that is the silliest thing I've heard all week. Would you rather handle raw pointers manually? Try doing that when you have hundreds or thousands of major objects floating around. Heck, it's really easy to make mistakes with less than ten objects, because C++ just gives you so much freedom.

Automatic resource management is a boon. The fact that unique_ptr keeps a compiler-checked unique reference is great. Btw, this is the same thing as Rust's single owning mutable reference concept, would you say that's stupid too? The more work you push onto the compiler, the better, because it doesn't make mistakes.

There's nothing amateur about it, pre-C++ 11 projects like LLVM up to 3.4 declared their own smart pointer classes, like OwningPtr<T>, because they're so damn useful. C++11 just standardized it into shared_ptr, unique_ptr, and others.

@RememberMe alright.
Now tell me why there is no automatic garbage collection on all pointers (as in all pointers are smart pointers), because obivously this works on tons of runtimes and doesn't restrict the dev at all.

@nitwhiz but it is restrictive. You have to operate within the bounds of the runtime engine. The whole point of C++'s design is to give you complete control. You can change allocation and deallocation strategies to suit your application.

Eg. If you're making a game particle engine with millions of particles, the memory allocation/deallocation patterns will be very different from, say, a UI or a raytracer or whatever. C++ gives you the flexibility to take advantage of this. Standard runtimes have to be designed for generic cases.

Heck, you can actually add a GC and auto deallocate pointers if you really want, there's a very nice C++ GC called the Boehm GC.

Also, C++ is used in complex constrained environments where you don't have space for a large runtime. Such as embedded systems.

C++ is a pretty specialized, bare metal language for when you want complete control over every single thing about your application. If you don't need it, just use something else, like Java.

@RememberMe but are shared pointers not some kind of garbage collection?
They count their references and free themselves as soon as possible.

@nitwhiz correct. I never said we avoid shared pointers in C++, or even memory management strategies, and reference counting is a great and widely used strategy.

The argument was against automatically managing pointers by default. If you want to use (and suffer the overhead of) shared pointers, go ahead. It's very similar to having an inbuilt refcounting GC.

C++'s USP is that it's completely optional. You can have refcounting, weak ref counting, uniqueness semantics, pool/slab allocation, tree allocation, indirected compact arrays of objects for cache locality, raw pointers, generational GCs, whatever you want, just implement it. Heck, you can even customize how standard containers like vectors and lists and all allocate themselves.

Also, if you want some custom logic in your refcounting (after all there are many ways to do it) then you can edit how shared_ptr works. Or make your own custom refcounted pointer. You have the power.

@RememberMe tbh, you bought me.

Thanks for sharing all that, I learned something today.😄