3 ms·

Smart pointers are a form of garbage collection. (I'm assuming you mean reference counting).

• steveklabnik 10y ago
  Not all smart pointers are reference counted.
  • vardump 10y ago
    Sure, smart pointers can also refer to bounds checking, etc. In this case, grandparent did mention a memory management technique, namely garbage collection. Memory management + plus typically required thread safety usually means reference counting.
    • steveklabnik 10y ago
      uniq_ptr<T> in C++ and Box<T> in Rust are both considered smart pointers, dealing with memory management, and don't do any reference counting, bounds checking, or anything else like that at runtime. They're a compile-time abstraction only.
      • vardump 10y ago
        Good point. Somehow I wasn't considering unique_ptr<T> as a smart pointer, despite using it all the time for resource management to avoid writing wrapper classes. I do now, you're right.
      • rbehrends 10y ago
        This is not really accurate. A unique_ptr<T> move assignment must check the target location to see if it's null, and if not, free the underlying object. It also has to clear the source location. This is more than just a compile-time abstraction compared to raw pointers, even if modern compilers can elide the code most of the time. Also, the lack of checking leads to unique_ptr<T> dereferences potentially having undefined behavior (i.e. whenever you try to dereference a unique pointer that is null [1]). [1] http://en.cppreference.com/w/cpp/memory/unique_ptr/operator* http://en.cppreference.com/w/cpp/memory/unique_ptr/operator*
        • dbaupp 10y ago
          I think you're picking nits. The equivalent raw pointer code would also have to free a pointer it was overwriting, so I'm not sure that's so interesting (definitely not in terms of "zero cost abstractions"). That said, the null checks required for C++'s destructor semantics are definitely a little more interesting in this respect, given one is rarely going to do this with raw pointers (although the cases when you don't need to do it also seem like cases the optimiser can handle fairly easily), but an extra branch and/or write at least seems significantly qualitatively different to the full reference counting that people often think of when talking about "smart pointers", which is the point the parent is trying to make (smart pointers aren't just reference counting).
          • rbehrends 10y ago
            I'm not picking nits. This is not just about the freeing (which I assume will happen in the minority of cases), but also the test-and-branch code generated (plus the zeroing of the source location), which is something that you can't just ignore even if branch prediction is perfect. The claim that they are a "compile-time abstraction only" is pretty absolute. Also, the cost of it not being memory-safe should not be ignored.
            • dbaupp 10y ago
              I was claiming you were picking nits because the main point of the comment is that smart pointer != reference counting, the incorrect "only" claim is somewhat orthogonal. And, my point about the qualitative difference between the runtime behaviour is definitely true (although I'll now strength it to a quantitative one: moving a unique_ptr doesn't require dereferencing it, unlike a reference counted one, and nor does it require any synchronisation, unlike thread-safe reference counting ala shared_ptr). In any case, it is unfortunate that unique_ptr is not memory safe, but it also not at all notable, as pretty much nothing in C++ is completely memory safe (even the other smart pointers like shared_ptr).
              • rbehrends 10y ago