Popular Myths about C++, Part 2
isocpp.org
Popular Myths about C++, Part 2
1–10 of 93 posts
Re: Popular Myths about C++, Part 2
#2Here's a good myth:
"Only program in C++ if you absolutely have no other option."
Just putting this out there for the discussion's sake, perhaps someone could engage on it. I recently discovered to my horror that Apache Mesos is written in C++. They use the nice futuristic style Strousup would probably applaud though, still I think any other practical programming language would have been a better fit since it's just a sysadmin tool. Obviously they disagree.
Re: Popular Myths about C++, Part 2
#3Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
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.
Re: Popular Myths about C++, Part 2
#4Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
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 stand…
> 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.
Re: Popular Myths about C++, Part 2
#5Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
I've been doing nothing but modern C++11 for a year solid and I have to also agree. C++11 and its standard libraries are a huge improvement but is still difficult to iterate and prototype with. Templates, lambdas, and generic programming are great additions but still very difficult to deal with and debug at times. By using Intel's compiler performance can really scream, but the time it takes to get things done is very tough to deal with.
Contrasting this to Julia/lighttable/Juno is like night and day. Programming in a canvas/all REPL style is unbelievably freeing since each little piece can be tested and iterated on quickly and easily. Then the program can be organized in a continuous matter while it is being made. The mental energy needed at any one point in time is massively decreased since classes, inheritance, types, memory, and data flow don't all have to be dealt with in an interwoven manner like C++.
The performance won't be equal immediately, but being able to prototype, then optimize, then only have to replace minimal parts with native code after they have been shown to be bottlenecks is amazing (and calling C is even super direct because of strong typing)
So after a solid year, I agree with the idea of using C++ only if there is no other option.
Re: Popular Myths about C++, Part 2
#6Here's a good myth: "Only program in C++ if you absolutely have no other option." I believe in this myth, I also am currently working on a project in C++ and reading one of Strousup's books. I think even Strousup shares this belief, but he would probably phrase it a bit differently. (My project is interfacing with the Unreal Engine by Epic that exposes a C++ API.) Just putting this out there for the discussion's sake…
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 stand…
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.
Re: Popular Myths about C++, Part 2
#7I've heard so much laid at C++ feet over the years, but I don't find it all that horrible to work with. It seems about on the same level as Python to get most things done, just without all the magic of the python standard library.
Are there some good stories of the bad of C++ that anyone can share?
Re: Popular Myths about C++, Part 2
#8I feel like it's a bit grasping if you need such a complex example to debunk a straw man.
Implicit garbage collection is about the ease of writing code, not reliability. You make the compiler work for you by not making what you want explicit. Yes, for bad programmers, this leads to better code, but that doesn't mean you don't benefit from implicit garbage collection if you are a good programmer.
Re: Popular Myths about C++, Part 2
#9Earlier quoted context omitted.
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 stand…
> 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.
> 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++.
Re: Popular Myths about C++, Part 2
#10Earlier quoted context omitted.
> 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.
> 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++.
> Isn't C simpler than C++ and doesn't waste cycles?
I should have added "and also high level". I did that now.