4 ms·

You're right, it is generally desired, even Stroustrup (author of C++) doesn't want you to manually manage memory unless you really have to. That's why there ar

by fhd2 13y ago

You're right, it is generally desired, even Stroustrup (author of C++) doesn't want you to manually manage memory unless you really have to. That's why there are smart pointers and why you should work with values as much as you can. You can even plug a garbage collector in in C++. But when you're working in a constrained environment, you need the option to control all this in much detail. C++ is one of the very few options you have for that.

pkolaczk 13y ago
smart_pointers in C++ are dead slow compared to Java's GCed pointers. And full featured GCs for C++ are unicorns. There are a few, but noone actually uses them in production, except a few experimental language runtimes.
- bstamour 13y ago
  unique_ptr, the default smart pointer in C++ is no slower than direct pointer access. If you require data sharing, then shared_ptr offers you that feature at the cost of reference counting.
  - pkolaczk 13y ago
    unique_ptr is not a replacement for Java's GC. It simply doesn't do the same. shared_ptr is much closer, but at the cost of reference counting, which, if you start using it excessively, is much higher than cost of Java GC. I agree that if your memory management is dead simple and you are fine with using only unique_ptr everywhere, C++ solution is superior. You obviously don't need GC, so why pay for it. Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. However, there are some domains where GC enables completely different ways of programming. E.g. lockless concurrency / immutable structures / functional programming etc. Poor shared_ptr performance and scalability is prohibitive in those areas.
    - pjmlp 13y ago
      > Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. While it helps, it can only cover the code you have access to. No way to take care of third party libraries delivered in binary form.
    - pcwalton 13y ago
      > Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. I don't believe such a static analysis tool can exist without being a different language (e.g. Cyclone). There just isn't enough information about ownership semantics in C's type system.
      - mcguire 13y ago
        Cough, cough, Rust?[1] [1] http://static.rust-lang.org/doc/0.8/rust.html#memory-boxes http://static.rust-lang.org/doc/0.8/rust.html#memory-boxes
      - pkolaczk 13y ago
        In cases, where unique_ptr is enough, ownership is simple and statically pairing all mallocs with frees is easy. The whole problem with memory management is sharing ownership. Then things start getting hairy.
- vinkelhake 13y ago
  I assume you mean ref counted smart pointers, not all smart pointers are ref counted. Java's pointer might be faster than shared_ptr. But, in Java, all objects are held by pointers. C++ gives you more options. It's not like we're going "Damn, I just can't figure out the ownership here. I'll just use shared_ptr and be done with it" every day. In my experience, usage of shared_ptr is quite limited.
  - pkolaczk 13y ago
    It is definitely going to change at some time, IBM already has a prototype of JVM supporting object packing and fine-grained alignment control. shared_ptr use is limited because shared_ptr is slow and people learned to avoid it at all cost. But having to think about ownership influences design choices and often makes things more complex and less performant that needed (e.g. it often forces to copy objects instead to just pass a pointer).
    - vinkelhake 13y ago
      Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices. We (C++ programmers) don't avoid shared_ptr at all costs and the primary reason for avoid it is because it muddles ownership semantics. In other words: if a magical zero-cost shared_ptr implementation appeared, we wouldn't start using it everywhere. You can keep extolling the virtues of Java performance, but fact remains that Java doesn't see much use in areas where performance is critical. It doesn't mean Java doesn't have a use, it's just not there.
      - pkolaczk 13y ago
        > Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices Maybe this is the reason C++ guys always complicate things: http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make-things-so-complicated/ http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make... As of Java being not-performant enough: that's why Java is used as one of the most popular language for implementation of modern NoSQL databases systems. Everyone knows performance doesn't matter in databases. ;)

by fhd2 13y ago

pkolaczk 13y ago

smart_pointers in C++ are dead slow compared to Java's GCed pointers. And full featured GCs for C++ are unicorns. There are a few, but noone actually uses them in production, except a few experimental language runtimes.

bstamour 13y ago
unique_ptr, the default smart pointer in C++ is no slower than direct pointer access. If you require data sharing, then shared_ptr offers you that feature at the cost of reference counting.
- pkolaczk 13y ago
  unique_ptr is not a replacement for Java's GC. It simply doesn't do the same. shared_ptr is much closer, but at the cost of reference counting, which, if you start using it excessively, is much higher than cost of Java GC. I agree that if your memory management is dead simple and you are fine with using only unique_ptr everywhere, C++ solution is superior. You obviously don't need GC, so why pay for it. Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. However, there are some domains where GC enables completely different ways of programming. E.g. lockless concurrency / immutable structures / functional programming etc. Poor shared_ptr performance and scalability is prohibitive in those areas.
  - pjmlp 13y ago
    > Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. While it helps, it can only cover the code you have access to. No way to take care of third party libraries delivered in binary form.
  - pcwalton 13y ago
    > Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls. I don't believe such a static analysis tool can exist without being a different language (e.g. Cyclone). There just isn't enough information about ownership semantics in C's type system.
    - mcguire 13y ago
      Cough, cough, Rust?[1] [1] http://static.rust-lang.org/doc/0.8/rust.html#memory-boxes http://static.rust-lang.org/doc/0.8/rust.html#memory-boxes
    - pkolaczk 13y ago
      In cases, where unique_ptr is enough, ownership is simple and statically pairing all mallocs with frees is easy. The whole problem with memory management is sharing ownership. Then things start getting hairy.
vinkelhake 13y ago
I assume you mean ref counted smart pointers, not all smart pointers are ref counted. Java's pointer might be faster than shared_ptr. But, in Java, all objects are held by pointers. C++ gives you more options. It's not like we're going "Damn, I just can't figure out the ownership here. I'll just use shared_ptr and be done with it" every day. In my experience, usage of shared_ptr is quite limited.
- pkolaczk 13y ago
  It is definitely going to change at some time, IBM already has a prototype of JVM supporting object packing and fine-grained alignment control. shared_ptr use is limited because shared_ptr is slow and people learned to avoid it at all cost. But having to think about ownership influences design choices and often makes things more complex and less performant that needed (e.g. it often forces to copy objects instead to just pass a pointer).
  - vinkelhake 13y ago
    Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices. We (C++ programmers) don't avoid shared_ptr at all costs and the primary reason for avoid it is because it muddles ownership semantics. In other words: if a magical zero-cost shared_ptr implementation appeared, we wouldn't start using it everywhere. You can keep extolling the virtues of Java performance, but fact remains that Java doesn't see much use in areas where performance is critical. It doesn't mean Java doesn't have a use, it's just not there.
    - pkolaczk 13y ago
      > Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices Maybe this is the reason C++ guys always complicate things: http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make-things-so-complicated/ http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make... As of Java being not-performant enough: that's why Java is used as one of the most popular language for implementation of modern NoSQL databases systems. Everyone knows performance doesn't matter in databases. ;)