Live data from Hacker News

Does C++ still deserve a bad rap?

nibblestew.blogspot.com

291–300 of 310 posts

Re: Does C++ still deserve a bad rap?

#291
post #189
post #135

Earlier quoted context omitted.

> This slightly over 100 page book on move semantics https://leanpub.com/cppmove shows some of the iceberg like complexities dotted all over the place. Some developers probably never use and have never even heard of move semantics. I think Scott Meyers' "Effective Modern C++" which is in large part a collection of caveats and description of things which don't fit always together also underlines that impression: https…

Hard agree. I was enthusiastic about reading that book when I got it, as I'd been very late to the bandwagon of new C++11 and C++14 features. Ended the book in a pessimistic tone. It looked more like a cookbook of pitfalls _everywhere_. Every new feature looked exciting, but came with a list of cases where the language decides to leave you on your own when it gets too uncomfortable (the "well that's undefined behavio…

For me, that disillusion has been one of several steps.

Scott Meyers book was one point.

Then I started to learn Clojure, motivated by the idea that we need better concepts for the upcoming massively parallel hardware (a big influence for me was the article "The free lunch is over" by Herb Sutter: http://www.gotw.ca/publications/concurrency-ddj.htm). I now think that immutability by default is clearly the better way to go, even in close-to-the machine applications like embedded devices and industrial control applications.

Then, I saw this article on the different options and syntax for initializing variables in modern C++: http://mikelui.io/2019/01/03/seriously-bonkers.html

And I was like, no, this can't be serious. I think this was the point where I began to distance from the language (though I still use it at work when I need to).

I got also the impression that the actual language use in C++ is undergoing a serious split. Compare the C++ core guidelines with Google's C++ style guide:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

https://google.github.io/styleguide/cppguide.html

This does already look somewhat like different languages, only that they can be compiled with the same compiler.

And then, the C++17 and C++20 standard iterations, at this point it is just like "this is too much! What is this good for?"

Re: Does C++ still deserve a bad rap?

#292
post #289

Earlier quoted context omitted.

I used to work with C++ almost exclusively, but accepted to use more interactive languages for most of my work mostly for faster iteration. C++ is definitely not my main choice anymore, but still use it daily. C++ has pretty much unmatched tooling due to the massive ecosystem. I have my own long list of gripes against it's syntax and historical baggage, however it's a language that doesn't really impose a style/idiom…

> C++ can be vastly simpler and more readable, while retaining 100% control over memory and layout. But unlike assembly, you don't have control over CPU flag registers and special instructions. Can you explain why and when, exactly, 100% control over memory is needed? Outside of OS kernels, high-frequency trading engines, and real-time control systems? If using assembly is too costly, why is using C++ economical? And…

You don't have direct control over caches, however if you have control over memory layout you can indirectly influence how the code performs by leveraging the proper cache sizes/lanes. If that's your goal, you cannot focus on program flow alone, and that's the main point.

Low-level and high-performance code is not "pretty" by modern standards, as it often requires DMA and tight control over data placement in order to fully leverage instruction-level and hardware-level parallelism. The hardware influences how the data structure layout should be first, and we work on top of it. We abstract structs and containers that capture this layout, so that we can still have a readable program flow at the end.

In this sense, C++ can still be used as a glorified assembler, without the need to drop down to ASM for the simple stuff as your for loop: nobody wants to do that (me included). But contrarily to C, you can avoid a ton of preprocessor macros and get improved type checking, while still using ASM in selected spots if needed.

Your example about vector is not really surprising. Do you want the iterator to be efficient, or consistent? Tough choice, depending on the scenario. It's annoying that it's not standardized in one form or the other. I remember I was fretting over this detail over 10 years ago, but in actuality I used vector exactly 0 times in my career so far.

Again, please don't consider this as if I was praising C++. There are _many_ areas, including lack of standardization in the stdlib area (vector being one of many), that I don't like. I just want to say that it's an incredibly versatile tool which is very hard to replace given the same constraints.

Re: Does C++ still deserve a bad rap?

#293
post #159
post #88

Earlier quoted context omitted.

> but a lot of primitive stuff in languages like python is also just C calls and may be optimised to the point of being faster That assertion makes zero sense if we take into account that parallelization is one of the most basic performance techniques there is, and Python's GIL simply eliminates that option except for multi-process applications which then require serializing stuff back and forth. Python is pretty muc…

> That assertion makes zero sense if we take into account that parallelization is one of the most basic performance techniques there is I would not support that stance. There are areas where parallelization is helpful, like numerical weather models, graphics, and scientific number crunching, but for by far the most cases, parallelization is anything but trivial and requires a pretty deep knowledge about things like t…

Its funny that you mentioned games as an example of parallel computation because I'd argue they're some of the hardest programs to parallelize effectively since they don't generally involve that much bulk-processing of read-only data.

Parellism in C++ is most often used for scientific applications and other forms of mass number crunching. It's really easy to just throw a "#pragma omp parallel for" on a loop and call it a day but of course that would also apply to C and Fortran and is somewhat limited. Parallelism libraries like Intel TBB which I'm most familiar with are very easy to use and performant. I think there's a large problem in the reluctance of educators to use libraries to teach parallelism and people always dive straight into locks, threads and atomics which are really not the way to approach parallel computing if you're looking to do parallel computing and not looking to implement parallel primitives yourself (i.e DIY tasking-system or lock-free queue)

Focusing on TBB, it facilitates efficient parallelism by providing high-level canned algorithms such as parallel_invoke, parallel_reduce, parallel_for and parallel_do which anybody who claims to know C++ should be able to use easily. It also provides a task-graph which is great for more complex processing pipelines (things like join/split, fan-in/out and queueing). If you need more low level control you operate at the task level and TBB provides customization points for that. There's other libraries out there which provide similar functionality and even the STL in C++17 provides basic parallel algorithms such as transform (equivalent of map in other langs), reduce and many others.

Re: Does C++ still deserve a bad rap?

#294
post #76

Like every programming language out there, C++ is a tool. And like every tool out there it has its uses. There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. However, there's one thing you can do in C++ and not in Python or JavaScript or PHP: fully control the memory layout of your data. While you don't need it in most of the cases, it becomes a ki…

> There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. People using c++ usually care about programs finishing before the heat death of the universe. I had a few Python scripts that spend several seconds parsing larger files, after a rewrite to c++ that changed to almost instant.

You just compared C++ to the slowest popular language out there. It would be a much more fair comparison if you used pretty much any other high-level language.

Since you can get within about 2x of C++ speed which still using a high-level language, that makes the argument that the times you really need C++ for performance reasons are quite limited. I'm not saying they don't exist, but they are rare.

Re: Does C++ still deserve a bad rap?

#295
post #143

Like every programming language out there, C++ is a tool. And like every tool out there it has its uses. There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. However, there's one thing you can do in C++ and not in Python or JavaScript or PHP: fully control the memory layout of your data. While you don't need it in most of the cases, it becomes a ki…

> There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. Well, I think that Python will probably do that in the shortest code but it is also more or less the slowest language which is today widely in use, at frequently about 1/50 the speed of C. You of course could write the example in the link in Rust but for a quick script with decent performance,…

I feel like the fastest growing and most dominant area for C++ is scientific computing and AI/ML. Although many people write these programs in more user-friendly languages like Python and R, most of these programs call through to C++ frameworks (which many people use directly too), so in a way C++ has latched itself to the growth of such languages. Furthermore many major accelerated computing platforms (frameworks?) such as CUDA, Intel's oneAPI and Khronos' SYCL are focused on and committed to the C++ language and ecosystem and I don't really see much competition in this space for the time being.

Re: Does C++ still deserve a bad rap?

#296
post #88

Earlier quoted context omitted.

it depends on what you're doing of course. It can even go the other way[1] Generally languages like C++ are obviously much faster, but a lot of primitive stuff in languages like python is also just C calls and may be optimised to the point of being faster, because doing things in low level compiled languages often comes with its own tricks and problems. [1] https://stackoverflow.com/questions/9371238/why-is-reading-l…

> but a lot of primitive stuff in languages like python is also just C calls and may be optimised to the point of being faster That assertion makes zero sense if we take into account that parallelization is one of the most basic performance techniques there is, and Python's GIL simply eliminates that option except for multi-process applications which then require serializing stuff back and forth. Python is pretty muc…

Python and C++ are joined at the hip now primarily due to scientific computing and AI/ML adjacent fields. I feel the growth of Python has helped C++ grow too.

Re: Does C++ still deserve a bad rap?

#297
post #262
post #216

Modern C++ can be a joy to write, and is fine for a lot of tasks. It's hard to beat the combination of performance characteristics and higher-level constructs. The issue with C++ is that it's unsafe by default. Foot-guns abound. The right way is to make everything safe by default and provide an escape hatch when needed, e.g. Rust's unsafe or C#'s unmanaged. Unfortunately, there's no way to "fix" C++ to be safe-by-def…

IMO fixing the unsafety is impossible, because doing so would mean re-evaluating the very core idea of C++ that C is a suitable substrate for building a safe, expressive language on. We know from years of experience that C has plenty of footguns of it's own, and fixing them is not possible without a fundamental redesign of the language. Therefore, the foundation of C++ is already rotten. If that foundation were to be…

The raison d'être of a safer C++ would be to enable staged, tool-assisted migration for the many hundreds of millions (billions?) of lines of C++ code in the world.

I think that's plenty of reason all by itself.

Re: Does C++ still deserve a bad rap?

#298
post #249
post #188

The code for that blog post is fragile in an interesting way. Its safety and security depend on a subtle invariant: that the 'word_regex' does not match a string containing any non-ASCII character. If requirements changed so the regex could match a non-ASCII character, then one of the 'c' chars could have a negative value other than -1. https://en.cppreference.com/w/cpp/string/byte/tolower says "If the value of ch is…

In at least some locales tolower segfaults under that condition, in glibc at least. (before anyone says that ‘in reality it’s probably fine’)

I would love to know an example of that.

Re: Does C++ still deserve a bad rap?

#299
post #249

Earlier quoted context omitted.

In at least some locales tolower segfaults under that condition, in glibc at least. (before anyone says that ‘in reality it’s probably fine’)

I would love to know an example of that.

https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

Re: Does C++ still deserve a bad rap?

#300
post #209

Like every programming language out there, C++ is a tool. And like every tool out there it has its uses. There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it. However, there's one thing you can do in C++ and not in Python or JavaScript or PHP: fully control the memory layout of your data. While you don't need it in most of the cases, it becomes a ki…

> [...] fully control the memory layout of your data. Is that actually guaranteed by the standard? > * Try doing anything non-trivial on a microcontroller with 32KB of RAM. You could theoretically use a higher-level language, but you will end up using >10x amount of RAM. It's a shame Forth never took off. Sometimes I wonder what it would have been like to live in an alternate universe where Forth had been the lingua…

> Is that actually guaranteed by the standard?

Kinda sorta. Technically, the program runs on an abstract machine, and the compiler is free to do whatever it wants that has the same observable behavior as the code you wrote. But this is not really a problem in practice: You will get what ask for, or occasionally the optimizer will give you something even better.

If you really need to ensure that you have exactly the layout you ask for, you could use "volatile" which tells the compiler that some region of memory is "special". Storing stuff there could have side effects. The memory could change at any time. This will force the compiler to follow your instruction verbatim. But it's not really advised since it will read the data from memory every time even if it's available for quick and easy access in a register - the memory could have changed, better read it again!

One important thing that is not possible to express in C++, is that some value, e.g. a password, should be purged from memory. A copy of the password in some random location of memory, that is not observable, so the compiler is free to create such a copy if it wants to.

Post reply on HN