5 ms·

Depends on how strongly you mean "no other option". For example, is Rust another option? I'm not sure how comfortable I am writing for a language with a version

by pyrois 12y ago

Depends on how strongly you mean "no other option". For example, is Rust another option? I'm not sure how comfortable I am writing for a language with a version of "0.12.0". My understanding is that they make breaking changes fairly frequently (at least compared to the religious mania that is C++'s approach to backwards-compatibility). D seems like an option. Go, maybe, depending on what you're doing. Here's my standard example for when I would happily choose C++: I am writing an image processing library that I want to be able to run on both the PC and embedded platforms (e.g. one of TI's DSPs). I also want to be able to write low-cost bindings in python, ruby, etc. There are other options, but I think C++ is the best one in this case.

Dewie 12y ago
> Depends on how strongly you mean "no other option". For example, is Rust another option? What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler - while also being high level - language. > Here's my standard example for when I would happily choose C++: I think the standard examples are certain application-level programs.
- k__ 12y ago
  > What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler language. Isn't C simpler than C++ and doesn't waste cycles? The only "no other option" scenario I could imagine is, legacy code in C++ or using a framework that needs C++.
  - Dewie 12y ago
    > Isn't C simpler than C++ and doesn't waste cycles? I should have added "and also high level". I did that now.
  - maxlybbert 12y ago
    > Isn't C simpler than C++ and doesn't waste cycles? I gave a couple of C++ books to a recent CS graduate. She assured me that C++ would be easy to pick up because it has a much smaller standard library than Java. I smiled but didn't say any anything. Yes, C is simpler than C++. But that simplicity comes with a cost, mainly that the programmer has to keep track of more details. And the C standard library is smaller than the C++ standard library (and that would be true even if the C++ standard library didn't include the C standard library).
- cbd1984 12y ago
  Another thing to think about: Program in C++ if you have memory to waste on leaks, or time to waste on plugging leaks. GC induces things that are arguably leaks, but in the average case they're controlled; leaks in C++ grow without bound in the average case.
  - 72deluxe 12y ago
    This leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C++ should have no leaks if you use RAII properly, have clearly defined container classes, use references everywhere or const pointers if you must. If you write sloppy code, you get sloppy output. See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources". EDIT: Wahay getting downvoted - thanks! In any other language (eg. PHP) if there was a vocal crowd complaining about how their scripts are slow when they do something stupid like fetching an entire database table and then doing filtering within the PHP script itself, everyone would say "But you're doing something stupid - it is going to be slow" and nobody would argue with it. With C++, when you point out that someone is doing something foolish, you get downvoted and people start making arguments about features of the language instead to detract from the truth that you've highlighted, ie "but a good language wouldn't let you do dangerous things", which is the same as saying "knives can cut you - ban all knives!!". It's really wearisome, and always rears its head here on HN where C++ is NOT the language of the day.
    - pif 12y ago
      Just wondering: why the downvotes?
      - Aldo_MX 12y ago
CyberDildonics 12y ago
Rust is likely not an option for most people using C++ yet. C++ has one huge advantage over almost every other language: its tools and eco system. MSVC++, Intel's ICC, GCC and LDC are all solid compilers where you will not paint yourself into a corner because of your tools. D is more mature but still can't compete on tools since only a few languages can make that claim. Your case is another big point. C++ can manage memory without raw pointers AND without garbage collection. It should be able to compile without a big runtime, but for some reason its modern dependencies are just as big as scripting languages.
- 72deluxe 12y ago
  "for some reason its modern dependencies are just as big as scripting languages" In what way? Isn't writing an application trivial with the STL? Even something like a GUI is possible with a small system and FLTK (although it isn't really very pretty).
steveklabnik 12y ago
> My understanding is that they make breaking changes fairly frequently http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html * now -> Jan 9: TONS of breaking changes * Jan 9 -> Feb 16: probably shouldn't break, but we reserve the right to deal with exceptional circumstances * Feb 16 -> six weeks, maybe 12: no more breakage

by pyrois 12y ago

Dewie 12y ago

> Depends on how strongly you mean "no other option". For example, is Rust another option? What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler - while also being high level - language. > Here's my standard example for when I would happily choose C++: I think the standard examples are certain application-level programs.

k__ 12y ago
> What I tend to think people mean when they say that, is that you have some cycles to "waste" on a simpler language. Isn't C simpler than C++ and doesn't waste cycles? The only "no other option" scenario I could imagine is, legacy code in C++ or using a framework that needs C++.
- Dewie 12y ago
  > Isn't C simpler than C++ and doesn't waste cycles? I should have added "and also high level". I did that now.
- maxlybbert 12y ago
  > Isn't C simpler than C++ and doesn't waste cycles? I gave a couple of C++ books to a recent CS graduate. She assured me that C++ would be easy to pick up because it has a much smaller standard library than Java. I smiled but didn't say any anything. Yes, C is simpler than C++. But that simplicity comes with a cost, mainly that the programmer has to keep track of more details. And the C standard library is smaller than the C++ standard library (and that would be true even if the C++ standard library didn't include the C standard library).
cbd1984 12y ago
Another thing to think about: Program in C++ if you have memory to waste on leaks, or time to waste on plugging leaks. GC induces things that are arguably leaks, but in the average case they're controlled; leaks in C++ grow without bound in the average case.
- 72deluxe 12y ago
  This leaks argument is really getting old. I have no leaks in my code. C++11's addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. Even "old" C++ should have no leaks if you use RAII properly, have clearly defined container classes, use references everywhere or const pointers if you must. If you write sloppy code, you get sloppy output. See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources". EDIT: Wahay getting downvoted - thanks! In any other language (eg. PHP) if there was a vocal crowd complaining about how their scripts are slow when they do something stupid like fetching an entire database table and then doing filtering within the PHP script itself, everyone would say "But you're doing something stupid - it is going to be slow" and nobody would argue with it. With C++, when you point out that someone is doing something foolish, you get downvoted and people start making arguments about features of the language instead to detract from the truth that you've highlighted, ie "but a good language wouldn't let you do dangerous things", which is the same as saying "knives can cut you - ban all knives!!". It's really wearisome, and always rears its head here on HN where C++ is NOT the language of the day.
  - pif 12y ago
    Just wondering: why the downvotes?
    - Aldo_MX 12y ago

CyberDildonics 12y ago

Rust is likely not an option for most people using C++ yet. C++ has one huge advantage over almost every other language: its tools and eco system. MSVC++, Intel's ICC, GCC and LDC are all solid compilers where you will not paint yourself into a corner because of your tools. D is more mature but still can't compete on tools since only a few languages can make that claim. Your case is another big point. C++ can manage memory without raw pointers AND without garbage collection. It should be able to compile without a big runtime, but for some reason its modern dependencies are just as big as scripting languages.

72deluxe 12y ago
"for some reason its modern dependencies are just as big as scripting languages" In what way? Isn't writing an application trivial with the STL? Even something like a GUI is possible with a small system and FLTK (although it isn't really very pretty).

steveklabnik 12y ago

> My understanding is that they make breaking changes fairly frequently http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html * now -> Jan 9: TONS of breaking changes * Jan 9 -> Feb 16: probably shouldn't break, but we reserve the right to deal with exceptional circumstances * Feb 16 -> six weeks, maybe 12: no more breakage