4 ms·

> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it

> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)? I don't usually write negative comments about C++ but I sure sympathize with them. I write C++ at my day job (and have for years). My team's codebase is in its teenage years. It's code-reviewed and has decent test coverage, but in many cases the author doesn't know C++ as well as the reviewer, and the reviewer is rushed / trying to not be a huge bottleneck, so stuff slips through. New code gets written to mostly C++11 standards (soon, mostly C++17) and the newest company practices. Old code...still exists...and the new code still has to use it. We've modernized some pieces but not as much as we'd like. Company-wide people do a pretty good job of modernizing a lot of the libraries we use, but my team hasn't kept up as well for various reasons. I hate memory errors. They're super hard to track down. I've spent significant time doing so. Thank god for ASAN and TSAN at least. I also don't like crashes in general; my service has to be quite reliable (some operations are critical to big parts of the company and have a 99.9995% success within a certain deadline). And fast, so I can't just rewrite it in Java or Go. A few examples of the sort of foot-guns C++ has: * Data races: no equivalent of Rust's Send+Sync auto traits. * string_view/reference/pointer outliving their backing memory: no lifetime annotations. Even the new proposal for them is very incomplete. * std::optional and equivalents dereferenced incorrectly: no pattern-matching syntax, the decision for the most obvious way to deference (operator*) to be undefined behavior instead of a crash. I wish the whole thing were written in Rust. Then the parts I have to pay super close attention to would all say "unsafe" in them. That covers memory safety (including data races). I'd also know to pay pretty close attention to "expect" and "unwrap", which cover most (not all) panics. Of course, more mundane logic errors can exist in any language, but freedom from those problems would be a huge relief.

Jabbles 8y ago
In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?
- pjc50 8y ago
  Only if the hardware is updated. I maintain an old MFC codebase that has to run on 15 year old 400MHz MIPS systems that don't belong to us.
  - pjmlp 8y ago
    You're keeping a Windows NT alive?!
    - pjc50 8y ago
      Windows CE (various extremely obsolete versions). The GUI side is quite convenient, since you can cross-develop from a normal desktop. The systems side is more of a problem, since the user community is almost non-existant.
      - pjmlp 8y ago
        Oh I completely forgot there was a MFC variant for CE, hence my NT remark.
- scottlamb 8y ago
  In short, yes: * CPU time per request: we do more work than we used to on average. For example, we do more asymmetric cryptographic operations now, and since introducing those operations we've increased the lengths of the keys. CPU time per request contributes not only to cost but to user-facing latency. * overall request rate: we handle >256X as many requests as we did 12 years ago. Those reasons are particular to my service, but I'd say the continued usage of C++ is convincing proof that plenty of people are willing to go to considerable effort to improve latency and efficiency. It'd be a lot easier to write things in a higher-level, GCed language otherwise.
  - jnbiche 8y ago
    > we do more asymmetric cryptographic operations now Could you use session keys to take some of the load off, exchanged using asymmetric crypto, or are you already doing that? Also, cool thing about Rust is that you can start writing parts of a C or C++ code base in Rust, and slowly switch over. This is exactly what Firefox is doing with their browser. Could you convince your company to let you try to rewrite a small part in Rust?
dman 8y ago
Thanks for taking the time to write such a thoughtful and informative reply.
berti 8y ago
There is hope for these, e.g. lifetime in C++20. Herb Sutter's talk at this same conference is really good and covers both of your first examples.
- Rusky 8y ago
  > Even the new proposal for them is very incomplete. I agree with this assessment of the C++20 lifetimes stuff. It's great, it will probably catch a lot of bugs, but it doesn't catch the worst ones and that's where you need it the most.

Jabbles 8y ago

In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?

pjc50 8y ago
Only if the hardware is updated. I maintain an old MFC codebase that has to run on 15 year old 400MHz MIPS systems that don't belong to us.
- pjmlp 8y ago
  You're keeping a Windows NT alive?!
  - pjc50 8y ago
    Windows CE (various extremely obsolete versions). The GUI side is quite convenient, since you can cross-develop from a normal desktop. The systems side is more of a problem, since the user community is almost non-existant.
    - pjmlp 8y ago
      Oh I completely forgot there was a MFC variant for CE, hence my NT remark.
scottlamb 8y ago
In short, yes: * CPU time per request: we do more work than we used to on average. For example, we do more asymmetric cryptographic operations now, and since introducing those operations we've increased the lengths of the keys. CPU time per request contributes not only to cost but to user-facing latency. * overall request rate: we handle >256X as many requests as we did 12 years ago. Those reasons are particular to my service, but I'd say the continued usage of C++ is convincing proof that plenty of people are willing to go to considerable effort to improve latency and efficiency. It'd be a lot easier to write things in a higher-level, GCed language otherwise.
- jnbiche 8y ago
  > we do more asymmetric cryptographic operations now Could you use session keys to take some of the load off, exchanged using asymmetric crypto, or are you already doing that? Also, cool thing about Rust is that you can start writing parts of a C or C++ code base in Rust, and slowly switch over. This is exactly what Firefox is doing with their browser. Could you convince your company to let you try to rewrite a small part in Rust?

dman 8y ago

Thanks for taking the time to write such a thoughtful and informative reply.

berti 8y ago

There is hope for these, e.g. lifetime in C++20. Herb Sutter's talk at this same conference is really good and covers both of your first examples.

Rusky 8y ago
> Even the new proposal for them is very incomplete. I agree with this assessment of the C++20 lifetimes stuff. It's great, it will probably catch a lot of bugs, but it doesn't catch the worst ones and that's where you need it the most.