19 ms·

Whenever I read something like this, I'm reminded of that Winston Churchill quote "It has been said that democracy is the worst form of government except all th

by btmorex 13y ago

Whenever I read something like this, I'm reminded of that Winston Churchill quote "It has been said that democracy is the worst form of government except all the others that have been tried". I think C++ usage is one of those things that you don't truly understand until you've decided to start a new project in C++ even in 2013. For a reasonably common feature set in real project (i.e. not a side project for fun), C++ is the only option. Specifically most alternatives exhibit one or more of the following: * automatically managed memory (enough said) * not expressive enough (I would throw C in this category even though C is a fine choice and often times the best choice for many projects) * not nearly mature enough in terms of compiler/toolset/language in general (often, it's unclear whether the language will ever achieve that necessary maturity) * not fast enough, usually for one of the above reasons, but sometimes for other reasons

reikonomusha 13y ago
Automatically managed memory is almost always a good thing. Aside from preventing a huge class of bugs, it also is often more performant. Why disparage it? And I'd hardly label C++ as the epitome of expressiveness. A broad, haphazard feature set doesn't necessarily imply it's expressive.
- 10098 13y ago
  I think he's talking about garbage collection, which is often perceived as slow. But you can certainly have automatic memory management in C++ as well. Stack-allocated objects manage themselves, for dynamically allocated objects one can use scoped/shared pointers. One added perk is that you can extend this approach to deterministically manage not only memory, but any other resource that can be acquired and released (e.g. locks). I actually like this approach very much. The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. But in a garbage-collected language that doesn't expose pointers, the heap can be defragmented during runtime, which is nice.
  - pcwalton 13y ago
    > The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. The biggest downside is not really efficiency but that you lose the memory safety of a managed language doing this.
    - 10098 13y ago
      True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers when you can't), etc. Of course, these don't make the language safe, but they do help alleviate the problem a great deal. I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. I mean, we already can detect some problems using static code checking tools (i.e. PVS-studio), so it must be feasible.
      - pcwalton 13y ago
        > I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. Rust does this. :) It is not easy to get right—the borrow checker required a lot of design work to achieve the right balance between expressiveness and practicality—but I think we've shown that it is possible. (Disclaimer: I work on Rust.)
      - pjmlp 13y ago
        Like most languages in the Pascal family. Arrays are bounded. You can usually disable bounds checking locally if you really need the extra ms, for cases the compiler is not able to optimize them. Proper strings instead of char pointers that might be null terminated or not. Var parameters and unbounded vector parameters to handle arguments that need to be changed. Oberon family has already proven it is possible to write desktop operating systems in GC enabled systems programming languages. Now as you say, many of these things are possible in modern C++. The problem is getting everyone on board, specially when dealing with old code bases littered with C like constructs.
- btmorex 13y ago
  No, automatic memory is always easier to use. It also always has a performance cost. Garbage collection has a ton of problems in systems applications (off the top of my head: unreasonable and unpredictable delays, incapability of dealing with a large amount of heap-allocated memory efficiently). Reference counting is better in many ways, but is not always appropriate and definitely has a cost (and I say this as someone who uses shared_ptr quite often).
  - jzwinck 13y ago
    This is missing something though: "new" and malloc() are just like managed memory: convenient, but sometimes (and often unpredictably) slow. Some people eschew Java and the JVM due to the spectre of garbage collection ruining their quasi-realtime system. But others embrace the JVM, organizing their programs to avoid garbage collection during critical times (which could last for hours or days). With C and C++ it is the same, but backward: people flock to these languages for the predictable performance. Yet once there, they discover they must avoid the default allocator, for it is a source of unpredictable delays. Pooled allocators are created, and the end result is much the same as for the JVM folks.
    - pkolaczk 13y ago
      The funny thing is that most of STL gives no realtime guarantees either, even if you use a custom realtime allocator with it. E.g. vector.push_back takes O(n) time sometimes. Running a chain of destructors caused by reference count dropping to 0 can be unpredictable as well.
      - ArbitraryLimits 13y ago
        I once had to re-implement the pieces of the STL I wanted in a real-time embedded system, for precisely this reason (well, that plus the fact that STL's use of allocators is broken, and I wanted to be able to allocate from fixed-size pools to avoid non-O(1) trips through an allocator at run-time).
      - cma 13y ago
- pandaman 13y ago
  If you are writing code that, essentially, is taking some data from a database and formats it nicely or takes user input and puts it into a database then managed memory is awesome. However, almost always, somebody has to write that database code and the code that displays the nicely formatted data (like in actually lighting pixels on the screen instead of filling out some css properties) and even the code that takes the user input. And for these purposes managed memory is a disaster and C++ is the most expressive language available.
  - pkolaczk 13y ago
    There are database systems written in Java and they have no problems competing in performance with database systems written in C++. Sure, there is probably more effort required with getting memory management right in case you're using Java (pooling / using off-heap memory), but Java has some other strengths, like superior concurrency support. IMHO, managed memory for system-level code is nowhere near being a "disaster". It might be sometimes tricky to get right, but not any harder than getting manual memory management right in C++ (and smart_pointers aren't a silver bullet, neither). Additionally, there are some Java extensions that let you write real-time code in it and guarantee GC won't kick in when you don't want it to.
    - pandaman 13y ago
      This, of course, depends on your definition of "compete" and "system-level" (e.g. I have no problem competing with professional athletes too, I just have a very serious problem winning against them but the competition is no problem at all). I write code that I consider system level (it talks to the hardware directly) and "tricky" is quite an understatement. Starting from the fact that there are half a dozen types of memory (not even talking about memory-mapped I/O) and just one "heap" in Java. Not to mention the hardware is not aware about the awesomeness of JVM and is trying to read/write actual memory pointers. I can imagine that you could get around this (as well as the lack of bit-fields and unsigned types) through some kind of memory-mapped-as-a-file trick but at this point you are not using the memory management at all. And IMHO this is very far from being "not any harder" than using pointers in C++.
- 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.
- jheriko 13y ago
  to a good approximation every memory management problem i've had involved a garbage collector, a reference count or a fancy stl pointer type. without these i have very few leaks or problems - and when i do they are trivial to find and fix. i see the advantage for RAD, but for performance and memory critical code these things are actually dangerous and stupid imo. measurably so...
72deluxe 13y ago
I would say that even the side projects deserve C++! I have written much code on the side in C++. Like a real language, the more you use it the better you understand it. Everyone should try it - I know some will dislike it but rubbishing it without really throwing yourself into is foolish, much like hating a food without trying it (as children do).
- pjmlp 13y ago
  I do use it on side projects, but on the job I am pretty happy to be on JVM/.NET land for our enterprise projects. Mastering C++ is like playing guitar, but most corporate developers only know how to play Kazoo.
pkolaczk 13y ago
Add good concurrent lockless programming support and this rules out C++ and leaves us with Java.
mcguire 13y ago
I'm a little unclear on how you include, "not nearly mature enough in terms of compiler/toolset/language in general (often, it's unclear whether the language will ever achieve that necessary maturity)" in that list. One of my perennial complaints about C++ is that it seems to be a moving target[1], more so than I really want to expose serious work to. [1] https://news.ycombinator.com/item?id=6888366 https://news.ycombinator.com/item?id=6888366
- pkolaczk 13y ago
  It is funny how slow moving target it is, yet the compiler/tool writers can't catch up.

by btmorex 13y ago

reikonomusha 13y ago

Automatically managed memory is almost always a good thing. Aside from preventing a huge class of bugs, it also is often more performant. Why disparage it? And I'd hardly label C++ as the epitome of expressiveness. A broad, haphazard feature set doesn't necessarily imply it's expressive.

10098 13y ago
I think he's talking about garbage collection, which is often perceived as slow. But you can certainly have automatic memory management in C++ as well. Stack-allocated objects manage themselves, for dynamically allocated objects one can use scoped/shared pointers. One added perk is that you can extend this approach to deterministically manage not only memory, but any other resource that can be acquired and released (e.g. locks). I actually like this approach very much. The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. But in a garbage-collected language that doesn't expose pointers, the heap can be defragmented during runtime, which is nice.
- pcwalton 13y ago
  > The only problem I see there is that since you're still using raw pointers, the runtime can't really move things around for efficiency since that would invalidate the pointers. The biggest downside is not really efficiency but that you lose the memory safety of a managed language doing this.
  - 10098 13y ago
    True, but most of these issues can be mitigated by using best practices - use vectors instead of raw arrays, avoid shared ownership (and use shared pointers when you can't), etc. Of course, these don't make the language safe, but they do help alleviate the problem a great deal. I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. I mean, we already can detect some problems using static code checking tools (i.e. PVS-studio), so it must be feasible.
    - pcwalton 13y ago
      > I wonder if it's possible to design a language that would be able to prevent these problems at compile time without incurring the runtime cost of managed languages. Rust does this. :) It is not easy to get right—the borrow checker required a lot of design work to achieve the right balance between expressiveness and practicality—but I think we've shown that it is possible. (Disclaimer: I work on Rust.)
    - pjmlp 13y ago
      Like most languages in the Pascal family. Arrays are bounded. You can usually disable bounds checking locally if you really need the extra ms, for cases the compiler is not able to optimize them. Proper strings instead of char pointers that might be null terminated or not. Var parameters and unbounded vector parameters to handle arguments that need to be changed. Oberon family has already proven it is possible to write desktop operating systems in GC enabled systems programming languages. Now as you say, many of these things are possible in modern C++. The problem is getting everyone on board, specially when dealing with old code bases littered with C like constructs.
btmorex 13y ago
No, automatic memory is always easier to use. It also always has a performance cost. Garbage collection has a ton of problems in systems applications (off the top of my head: unreasonable and unpredictable delays, incapability of dealing with a large amount of heap-allocated memory efficiently). Reference counting is better in many ways, but is not always appropriate and definitely has a cost (and I say this as someone who uses shared_ptr quite often).
- jzwinck 13y ago
  This is missing something though: "new" and malloc() are just like managed memory: convenient, but sometimes (and often unpredictably) slow. Some people eschew Java and the JVM due to the spectre of garbage collection ruining their quasi-realtime system. But others embrace the JVM, organizing their programs to avoid garbage collection during critical times (which could last for hours or days). With C and C++ it is the same, but backward: people flock to these languages for the predictable performance. Yet once there, they discover they must avoid the default allocator, for it is a source of unpredictable delays. Pooled allocators are created, and the end result is much the same as for the JVM folks.
  - pkolaczk 13y ago
    The funny thing is that most of STL gives no realtime guarantees either, even if you use a custom realtime allocator with it. E.g. vector.push_back takes O(n) time sometimes. Running a chain of destructors caused by reference count dropping to 0 can be unpredictable as well.
    - ArbitraryLimits 13y ago
      I once had to re-implement the pieces of the STL I wanted in a real-time embedded system, for precisely this reason (well, that plus the fact that STL's use of allocators is broken, and I wanted to be able to allocate from fixed-size pools to avoid non-O(1) trips through an allocator at run-time).
    - cma 13y ago
pandaman 13y ago
If you are writing code that, essentially, is taking some data from a database and formats it nicely or takes user input and puts it into a database then managed memory is awesome. However, almost always, somebody has to write that database code and the code that displays the nicely formatted data (like in actually lighting pixels on the screen instead of filling out some css properties) and even the code that takes the user input. And for these purposes managed memory is a disaster and C++ is the most expressive language available.
- pkolaczk 13y ago
  There are database systems written in Java and they have no problems competing in performance with database systems written in C++. Sure, there is probably more effort required with getting memory management right in case you're using Java (pooling / using off-heap memory), but Java has some other strengths, like superior concurrency support. IMHO, managed memory for system-level code is nowhere near being a "disaster". It might be sometimes tricky to get right, but not any harder than getting manual memory management right in C++ (and smart_pointers aren't a silver bullet, neither). Additionally, there are some Java extensions that let you write real-time code in it and guarantee GC won't kick in when you don't want it to.
  - pandaman 13y ago
    This, of course, depends on your definition of "compete" and "system-level" (e.g. I have no problem competing with professional athletes too, I just have a very serious problem winning against them but the competition is no problem at all). I write code that I consider system level (it talks to the hardware directly) and "tricky" is quite an understatement. Starting from the fact that there are half a dozen types of memory (not even talking about memory-mapped I/O) and just one "heap" in Java. Not to mention the hardware is not aware about the awesomeness of JVM and is trying to read/write actual memory pointers. I can imagine that you could get around this (as well as the lack of bit-fields and unsigned types) through some kind of memory-mapped-as-a-file trick but at this point you are not using the memory management at all. And IMHO this is very far from being "not any harder" than using pointers in C++.
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.
jheriko 13y ago
to a good approximation every memory management problem i've had involved a garbage collector, a reference count or a fancy stl pointer type. without these i have very few leaks or problems - and when i do they are trivial to find and fix. i see the advantage for RAD, but for performance and memory critical code these things are actually dangerous and stupid imo. measurably so...

72deluxe 13y ago

I would say that even the side projects deserve C++! I have written much code on the side in C++. Like a real language, the more you use it the better you understand it. Everyone should try it - I know some will dislike it but rubbishing it without really throwing yourself into is foolish, much like hating a food without trying it (as children do).

pjmlp 13y ago
I do use it on side projects, but on the job I am pretty happy to be on JVM/.NET land for our enterprise projects. Mastering C++ is like playing guitar, but most corporate developers only know how to play Kazoo.

pkolaczk 13y ago

Add good concurrent lockless programming support and this rules out C++ and leaves us with Java.

mcguire 13y ago

I'm a little unclear on how you include, "not nearly mature enough in terms of compiler/toolset/language in general (often, it's unclear whether the language will ever achieve that necessary maturity)" in that list. One of my perennial complaints about C++ is that it seems to be a moving target[1], more so than I really want to expose serious work to. [1] https://news.ycombinator.com/item?id=6888366 https://news.ycombinator.com/item?id=6888366

pkolaczk 13y ago
It is funny how slow moving target it is, yet the compiler/tool writers can't catch up.