5 ms·

Then C++ is also garbage collected.

pjmlp 10y ago
Kind of, but only because C++11 defined a pluggable GC ABI. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267... Also, there are the C++/CLI and C++/CX that support GC at language level. Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.
- hellofunk 10y ago
  > Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler. Then you also shouldn't say that Swift is garbage collected.
  - pjmlp 10y ago
    Swift RC is managed by the compiler and is visible in the type system and language semantics. C++ language definition doesn't give any special treatment tostd::*_ptr<> types regarding compiler semantics. They could be be something else.
    - hellofunk 10y ago
      Only partially, in Swift, it is still up to the user to cleverly work around scenarios that the system does not catch. Which is why you have weak references and other many tricks in the language to circumvent infinite reference cycles and related problems. It's hard to call language garbage collected when you have to deal with all that stuff yourself. Just look at the stuff you have to do sometimes in your closures to avoid them creating memories leaks.
- int_19h 10y ago
  Why should it be enforced by the compiler? We're talking about garbage-collected languages (and "language" traditionally includes the standard library), not garbage-collected-only languages. I mean, by your definition, C# also doesn't count, because it has unmanaged pointers in it.
  - pjmlp 10y ago
    Totally different. In C#, GC is part of the language semantics and its interaction with unmanaged pointers is well defined in the language semantics standard, including how the memory is pinned when unmanaged pointers need to access GC allocated memory.
    - int_19h 10y ago
      My point is that you're arbitrarily drawing a line between core language and its standard library, that is meaningless in practice. If reference counting is a kind of GC, and the standard library offers reference counting, then the language offers a kind of GC - same as if the language itself had a built-in refcounted pointer. There's simply no practical difference here.
      - pjmlp 10y ago
        No, because there is nothing in the language that requires making use of that specific library. It only makes sense to talk like that, if the language semantics define a relationship between the language and library requiring the library to always exist as a form of runtime and how the use of that runtime relates to language constructs. If I can just throw away the library and replace it by something else where those types aren't available and still make use of 100% of the language features, this relationship doesn't exist.
        int_19h 10y ago
        That's splitting hairs to the point where the difference is not relevant for any practical purpose. There's a single document defining what is ISO C++. It defines both the language and the standard library. Therefore, to "write in C++", by default, means to write code that uses and relies upon both the language semantics and the standard library functionality. Which means that std::shared_ptr etc is readily available, and is the standard way to use refcounting-based GC in C++. Hence, ISO C++ is a language with optional refcounting-based GC.

pjmlp 10y ago

Kind of, but only because C++11 defined a pluggable GC ABI. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267... Also, there are the C++/CLI and C++/CX that support GC at language level. Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

hellofunk 10y ago
> Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler. Then you also shouldn't say that Swift is garbage collected.
- pjmlp 10y ago
  Swift RC is managed by the compiler and is visible in the type system and language semantics. C++ language definition doesn't give any special treatment tostd::*_ptr<> types regarding compiler semantics. They could be be something else.
  - hellofunk 10y ago
    Only partially, in Swift, it is still up to the user to cleverly work around scenarios that the system does not catch. Which is why you have weak references and other many tricks in the language to circumvent infinite reference cycles and related problems. It's hard to call language garbage collected when you have to deal with all that stuff yourself. Just look at the stuff you have to do sometimes in your closures to avoid them creating memories leaks.
int_19h 10y ago
Why should it be enforced by the compiler? We're talking about garbage-collected languages (and "language" traditionally includes the standard library), not garbage-collected-only languages. I mean, by your definition, C# also doesn't count, because it has unmanaged pointers in it.
- pjmlp 10y ago
  Totally different. In C#, GC is part of the language semantics and its interaction with unmanaged pointers is well defined in the language semantics standard, including how the memory is pinned when unmanaged pointers need to access GC allocated memory.
  - int_19h 10y ago
    My point is that you're arbitrarily drawing a line between core language and its standard library, that is meaningless in practice. If reference counting is a kind of GC, and the standard library offers reference counting, then the language offers a kind of GC - same as if the language itself had a built-in refcounted pointer. There's simply no practical difference here.
    - pjmlp 10y ago
      No, because there is nothing in the language that requires making use of that specific library. It only makes sense to talk like that, if the language semantics define a relationship between the language and library requiring the library to always exist as a form of runtime and how the use of that runtime relates to language constructs. If I can just throw away the library and replace it by something else where those types aren't available and still make use of 100% of the language features, this relationship doesn't exist.
      - int_19h 10y ago
        That's splitting hairs to the point where the difference is not relevant for any practical purpose. There's a single document defining what is ISO C++. It defines both the language and the standard library. Therefore, to "write in C++", by default, means to write code that uses and relies upon both the language semantics and the standard library functionality. Which means that std::shared_ptr etc is readily available, and is the standard way to use refcounting-based GC in C++. Hence, ISO C++ is a language with optional refcounting-based GC.