14 ms·

C++ Frequently Questioned Answers (2009)

54 points by thriftwy 5y ago

caaqil 5y ago
Favorite excerpts: I know C++ better than it deserves and Finally, the following sentence is only here to attract a certain set of search engine users interested in our subject, and should not be interpreted as the summary of my point of view on the complicated issues discussed: C++ SUCKS
dang 5y ago
Past related threads: C++ Frequently Questioned Answers - https://news.ycombinator.com/item?id=887722 https://news.ycombinator.com/item?id=887722 - Oct 2009 (28 comments) C++ Frequently Questioned Answers - https://news.ycombinator.com/item?id=602981 https://news.ycombinator.com/item?id=602981 - May 2009 (73 comments)
spoiler 5y ago
Some of these aren't true anymore. I'd say some things improved from that document. But, I'd also say a lot of things got worse that aren't mentioned. We could nitpick at specific sentences/questions, but at the end of the day the spirit/gist of the document remains true, sadly. I used to quite like C++ in my younger days (highschool, uni), but once you start working with multiple people on a team, or a larger project, the illusion quickly unravels. The problem in C++ comes when you always have to make a poor value trade. If you wanted readability, or maintainability you have to sacrifice performance. Of you want performance, you have to sacrifice everything else. A great and easy example of this is that the most succinct/readable usage of std::variant has the most morbid performance, and the visitor API is just... Well, if people find that elegant, then beauty really is in the eye of the beholder. I still write C++ at my job, but I've no illusions about its grandeur. I have met a few profiles of people in my life/career who defended C++, and they seem to be present on HN too, so please don't take these gross over-generalisations personally; they're imperfect as all generalisations are, and they're just anecdotal anyway: Some just like feeling like powerful mystic wizards who have mastered the arcane syntax of invoking eldritch features. An additional layer is people who enjoys feeling like heroes when stuff goes wrong in production and they fix it with gdb keyslaps to dump core and transmute memory. Another profile, that seems way more common, are people stuck with C++. It's kind of a sunk cost fallacy, they already have a career in C++. And there really was nothing better for a long time (ok there was, but not on the job market, and C++ is heavily lobbied at unis). It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.
- dig1 5y ago
  Don't forget you have a complete market of C++ consultants and their companies that will do nothing but explain to you how partial template specialization works. Only for $$$$ per seat ;) Meyers, Alexandrescu, Sutter et al. built their careers by writing books and explaining arcane C++ details.
  - spacechild1 5y ago
    > built their careers by writing books and explaining arcane C++ details. This is only true of Meyers. Alexandrescu and Sutter are accomplished software architects and have been working for large companies.
- lpapez 5y ago
  Fully agree that the language is very taxing on the braincells and I think this is the main reason why Senior C++ Wizards tend to hate Rust. Imagine spending 10 years learning the little details about lifetimes, thread safety, million different UB cases etc. and then seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler. I bet it must be an infuriating feeling which is why I'm glad that I bailed out on C++ early in my carreer.
  - deeringc 5y ago
    I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.
    - spoiler 5y ago
      > I think the person you are characterising is quite rare. You could be right... I hope you are right, but I'm afraid you're not... > I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. [...] I like C++ but don't love all of the baggage and am delighted that things are moving forward. I don't know what the "split" is regarding mentality, and I've definitely seen a lot of experienced C++ devs in Rust communities, but then there's also a lot of people in "Rust bad"[1] circles (you see them on Reddit and HN). I think it might be an even split (as with most polarised opinions), but I don't think that either sort is rate. [1]: I don't blame these people, btw. If you're in a senior or leadership position and you choose C++ for a new project, because C++ is your strong suit. Then you read online "C++ bad" comments that glorify Rust. It's hard to not take these things personally, when it might be affecting your livelihood. Especially if semi-technical management "drinks the Rust Kool-Aid" (for a lack of better expression) and grills you over your decision. It's not a very disheartening situation to be in, and that frustration can fester into contempt, and so on.
Jenny8090 5y ago
[dead]
LAC-Tech 5y ago
Yosefk had one of my favourite programming blogs ever, sad he no longer updates.
- olvy0 5y ago
  He still tweets regularly, I find his tweets very funny sometimes. https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin
einpoklum 5y ago
C++ certainly has flaws - but it also has intentional design choices, which are important for achieving its goals. Also, as others have mentioned - much has improved since 2009. To make this concrete, Let's go over the "C++ defects" summary appearing at the link, before the individual "frequently-questioned answers". > changing the private members of a class requires recompilation of the code using the class. When the class is used to instantiate member objects of other classes, the rule is of course applied recursively. This is mandated by two of C++' language design goals: 1. Performance of compiled C++ code: This recompilation is necessary for exploiting optimization opportunities involved the altered private members. In fact, these days, compilers goes beyond even that situation: _linking_ code may trigger partial re-compilation without any changes to the source. 2. Zero-overhead abstractions: Having a private member should not in itself cost you in terms of performance. However, we can make the class implementation opaque (e.g. using the PIMPL idiom: https://stackoverflow.com/tags/pimpl-idiom/info https://stackoverflow.com/tags/pimpl-idiom/info ) if we want/need to. > Outstandingly complicated grammar C++ is guilty as charged here! It even has a semi-idiom named the "most vexing parse": https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse But there is an excuse, which is: Backwards compatibility. First, with C and C's syntax; then, with earlier versions of the language. Fixing the complicated syntax would break all existing C++ versions. So, they don't do it. > No way to locate definitions The fix for this is now part of the language: Modules. Unfortunately it will take time before these are widely-enough adopted. > No run time encapsulation... C and C++ are not designed to run in managed environments This is again necessitated by the performance requirements. Run-time encapsulation would mean slower code, sometimes much slower. Also, such encapsulation would mean there would be room for another C++-like language, below C++, without this encapsulation... and a goal of C++ is not to leave such room. Luckily, in recent years we have undefined behavior sanitizers in compilers, which catch a lot of these cases. One should also remember that languages with managed runtime environments often have exceptions to the rule, i.e. unsafe/unmanaged sections (unsafe in Rust, JNI in Java). > No binary implementation rules Sorry to have to harp on this, but platform-specific ABI is another necessity of performance. Still, C++ has a long way to improve in this respect, e.g. https://stackoverflow.com/q/58339165/1593077 https://stackoverflow.com/q/58339165/1593077 Recently, stack traces have been introduced into the language, and in C++23 they might be available by default when throwing exceptions; see: https://wg21.link/p2370r2 https://wg21.link/p2370r2 (I may continue in another post or extend this one.)
loicd 5y ago
I would like to comment on the claim that "all popular languages have context-free grammars, while C++ has undecidable grammar". Although I understand what is meant here, the terminology is just plain wrong. There are no such things as undecidable grammars. There are only undecidable problems. The C++ grammar is context-free, period. What gets people confused about it is that it is ambiguous, and that there are in fact two parsing problems you can associate to an ambiguous context-free grammar. One of them is decidable, the other is not in the case of C++. The first parsing problem is what I would call textbook parsing, as this is what is usually presented in books on the topic. It is a decision problem: the answer is either "yes" or "no". For context-free grammars, including C++, it is always decidable. So what about the ambiguous `AA BB(CC);` given in example here? Is it an object definition or a function declaration? The (decidable) textbook answer is simply "yes". The key thing to understand here is that textbook parsing does not require resolving any ambiguities. The "context-free" in "context-free grammar" only refers to this decision problem, which is why C++ has a context-free grammar, because textbook parsing does not require looking at any surrounding context. Of course, if you are writing a compiler, "yes" is not a very useful answer. You want either "yes, it is an object definition" or "yes, it is a function declaration", which turns the parsing problem into a completely different one, which I will call compiler parsing. Compiler parsing is not a decision problem, and in the case of C++, it is undecidable. What is meant by "all popular languages have context-free grammars" is simply that most languages have an unambiguous context-free grammar. To add to the confusion, textbook parsing and compiler parsing are essentially the same problem for unambiguous grammars.
makecheck 5y ago
I think they’ve gotten remarkably far with the language but they still desperately need to build an “opinionated subset” (of both the language and the STL) so that new generations have a hope of learning it properly. Perhaps modules will make it easier to do so in a way that allows interoperable code. I would love to see a backward-compatibility compiler and library that is essentially whatever C++ is now, frozen in time: any “.cpp”/“.cc” file is simply built with that. All new C++25 code should be something else (maybe “.ocp” for Opinionated C++?). The “.ocp” files would build against a complete replacement for the compiler and standard library, offering ONLY the sane subset of the original language and library that we have always needed. Finally remove all these constructs that we are not supposed to be using anymore. Throw std::iostream into a dumpster and set it on fire. Refactor all of this code that had to be implemented in weird ways simply because of the desire for perfect backward-compatibility. And finally take the opportunity to have sane defaults, which alone will probably allow 12 different keywords to be stripped out of the evolved language.
- zozbot234 5y ago
  Building an "opinionated subset" of C++ is definitely non-trivial - the C++ Core Guidelines are the closest thing to that (with plenty of input from standard committee members) and they're still far less usable than an actual greenfield effort like Rust.
pipeline_peak 5y ago
[33.1] Is the type of "pointer-to-member-function" different from "pointer-to-function"? It’s interesting to notice how “this” is what distinguishes the two. When creating member functions in C, function pointers are assigned members. In order to access or change the object with an assigned function pointer, that object needs to be called or in other words, “this”. obj.member_function(&obj); In C++ would be obj.member_function();
- BenjiWiebe 5y ago
  People actually put functions in structs in C to make it look like OOP!? That's horrifying! Or am I (hopefully) misunderstanding something here?
  - pipeline_peak 5y ago
    I'm not sure how common it is in practice. CPython and GTK are the most popular examples of OOP in C that I can think of. It's pretty pointless unless you want some sort of namespace-like organization. Maybe for polymorphism because you can change an instance's "base" member function pointer.
tpoacher 5y ago
> If you end up working with C++, don't try to "fix" it (or "boost" it). You'll just add more layers of complexity. The most productive approach is to accept the problems and try to write simple code which people can easily follow. I don't think this is specifically a C++ problem. It's true of any language, especially in a team setting. Reminds me of the post from yesterday, where some people where adding decorators in python to 'unmutate the mutable default argument' instead of just setting it to 'None'.

54 points by thriftwy 5y ago

Favorite excerpts: I know C++ better than it deserves and Finally, the following sentence is only here to attract a certain set of search engine users interested in our subject, and should not be interpreted as the summary of my point of view on the complicated issues discussed: C++ SUCKS

dang 5y ago

Past related threads: C++ Frequently Questioned Answers - https://news.ycombinator.com/item?id=887722 https://news.ycombinator.com/item?id=887722 - Oct 2009 (28 comments) C++ Frequently Questioned Answers - https://news.ycombinator.com/item?id=602981 https://news.ycombinator.com/item?id=602981 - May 2009 (73 comments)

spoiler 5y ago

Some of these aren't true anymore. I'd say some things improved from that document. But, I'd also say a lot of things got worse that aren't mentioned. We could nitpick at specific sentences/questions, but at the end of the day the spirit/gist of the document remains true, sadly. I used to quite like C++ in my younger days (highschool, uni), but once you start working with multiple people on a team, or a larger project, the illusion quickly unravels. The problem in C++ comes when you always have to make a poor value trade. If you wanted readability, or maintainability you have to sacrifice performance. Of you want performance, you have to sacrifice everything else. A great and easy example of this is that the most succinct/readable usage of std::variant has the most morbid performance, and the visitor API is just... Well, if people find that elegant, then beauty really is in the eye of the beholder. I still write C++ at my job, but I've no illusions about its grandeur. I have met a few profiles of people in my life/career who defended C++, and they seem to be present on HN too, so please don't take these gross over-generalisations personally; they're imperfect as all generalisations are, and they're just anecdotal anyway: Some just like feeling like powerful mystic wizards who have mastered the arcane syntax of invoking eldritch features. An additional layer is people who enjoys feeling like heroes when stuff goes wrong in production and they fix it with gdb keyslaps to dump core and transmute memory. Another profile, that seems way more common, are people stuck with C++. It's kind of a sunk cost fallacy, they already have a career in C++. And there really was nothing better for a long time (ok there was, but not on the job market, and C++ is heavily lobbied at unis). It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.

dig1 5y ago
Don't forget you have a complete market of C++ consultants and their companies that will do nothing but explain to you how partial template specialization works. Only for $$$$ per seat ;) Meyers, Alexandrescu, Sutter et al. built their careers by writing books and explaining arcane C++ details.
- spacechild1 5y ago
  > built their careers by writing books and explaining arcane C++ details. This is only true of Meyers. Alexandrescu and Sutter are accomplished software architects and have been working for large companies.
lpapez 5y ago
Fully agree that the language is very taxing on the braincells and I think this is the main reason why Senior C++ Wizards tend to hate Rust. Imagine spending 10 years learning the little details about lifetimes, thread safety, million different UB cases etc. and then seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler. I bet it must be an infuriating feeling which is why I'm glad that I bailed out on C++ early in my carreer.
- deeringc 5y ago
  I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.
  - spoiler 5y ago
    > I think the person you are characterising is quite rare. You could be right... I hope you are right, but I'm afraid you're not... > I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. [...] I like C++ but don't love all of the baggage and am delighted that things are moving forward. I don't know what the "split" is regarding mentality, and I've definitely seen a lot of experienced C++ devs in Rust communities, but then there's also a lot of people in "Rust bad"[1] circles (you see them on Reddit and HN). I think it might be an even split (as with most polarised opinions), but I don't think that either sort is rate. [1]: I don't blame these people, btw. If you're in a senior or leadership position and you choose C++ for a new project, because C++ is your strong suit. Then you read online "C++ bad" comments that glorify Rust. It's hard to not take these things personally, when it might be affecting your livelihood. Especially if semi-technical management "drinks the Rust Kool-Aid" (for a lack of better expression) and grills you over your decision. It's not a very disheartening situation to be in, and that frustration can fester into contempt, and so on.

Jenny8090 5y ago

[dead]

LAC-Tech 5y ago

Yosefk had one of my favourite programming blogs ever, sad he no longer updates.

olvy0 5y ago
He still tweets regularly, I find his tweets very funny sometimes. https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin https://nitter.net/YossiKreinin

einpoklum 5y ago

C++ certainly has flaws - but it also has intentional design choices, which are important for achieving its goals. Also, as others have mentioned - much has improved since 2009. To make this concrete, Let's go over the "C++ defects" summary appearing at the link, before the individual "frequently-questioned answers". > changing the private members of a class requires recompilation of the code using the class. When the class is used to instantiate member objects of other classes, the rule is of course applied recursively. This is mandated by two of C++' language design goals: 1. Performance of compiled C++ code: This recompilation is necessary for exploiting optimization opportunities involved the altered private members. In fact, these days, compilers goes beyond even that situation: _linking_ code may trigger partial re-compilation without any changes to the source. 2. Zero-overhead abstractions: Having a private member should not in itself cost you in terms of performance. However, we can make the class implementation opaque (e.g. using the PIMPL idiom: https://stackoverflow.com/tags/pimpl-idiom/info https://stackoverflow.com/tags/pimpl-idiom/info ) if we want/need to. > Outstandingly complicated grammar C++ is guilty as charged here! It even has a semi-idiom named the "most vexing parse": https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse But there is an excuse, which is: Backwards compatibility. First, with C and C's syntax; then, with earlier versions of the language. Fixing the complicated syntax would break all existing C++ versions. So, they don't do it. > No way to locate definitions The fix for this is now part of the language: Modules. Unfortunately it will take time before these are widely-enough adopted. > No run time encapsulation... C and C++ are not designed to run in managed environments This is again necessitated by the performance requirements. Run-time encapsulation would mean slower code, sometimes much slower. Also, such encapsulation would mean there would be room for another C++-like language, below C++, without this encapsulation... and a goal of C++ is not to leave such room. Luckily, in recent years we have undefined behavior sanitizers in compilers, which catch a lot of these cases. One should also remember that languages with managed runtime environments often have exceptions to the rule, i.e. unsafe/unmanaged sections (unsafe in Rust, JNI in Java). > No binary implementation rules Sorry to have to harp on this, but platform-specific ABI is another necessity of performance. Still, C++ has a long way to improve in this respect, e.g. https://stackoverflow.com/q/58339165/1593077 https://stackoverflow.com/q/58339165/1593077 Recently, stack traces have been introduced into the language, and in C++23 they might be available by default when throwing exceptions; see: https://wg21.link/p2370r2 https://wg21.link/p2370r2 (I may continue in another post or extend this one.)

loicd 5y ago

I would like to comment on the claim that "all popular languages have context-free grammars, while C++ has undecidable grammar". Although I understand what is meant here, the terminology is just plain wrong. There are no such things as undecidable grammars. There are only undecidable problems. The C++ grammar is context-free, period. What gets people confused about it is that it is ambiguous, and that there are in fact two parsing problems you can associate to an ambiguous context-free grammar. One of them is decidable, the other is not in the case of C++. The first parsing problem is what I would call textbook parsing, as this is what is usually presented in books on the topic. It is a decision problem: the answer is either "yes" or "no". For context-free grammars, including C++, it is always decidable. So what about the ambiguous `AA BB(CC);` given in example here? Is it an object definition or a function declaration? The (decidable) textbook answer is simply "yes". The key thing to understand here is that textbook parsing does not require resolving any ambiguities. The "context-free" in "context-free grammar" only refers to this decision problem, which is why C++ has a context-free grammar, because textbook parsing does not require looking at any surrounding context. Of course, if you are writing a compiler, "yes" is not a very useful answer. You want either "yes, it is an object definition" or "yes, it is a function declaration", which turns the parsing problem into a completely different one, which I will call compiler parsing. Compiler parsing is not a decision problem, and in the case of C++, it is undecidable. What is meant by "all popular languages have context-free grammars" is simply that most languages have an unambiguous context-free grammar. To add to the confusion, textbook parsing and compiler parsing are essentially the same problem for unambiguous grammars.

makecheck 5y ago

I think they’ve gotten remarkably far with the language but they still desperately need to build an “opinionated subset” (of both the language and the STL) so that new generations have a hope of learning it properly. Perhaps modules will make it easier to do so in a way that allows interoperable code. I would love to see a backward-compatibility compiler and library that is essentially whatever C++ is now, frozen in time: any “.cpp”/“.cc” file is simply built with that. All new C++25 code should be something else (maybe “.ocp” for Opinionated C++?). The “.ocp” files would build against a complete replacement for the compiler and standard library, offering ONLY the sane subset of the original language and library that we have always needed. Finally remove all these constructs that we are not supposed to be using anymore. Throw std::iostream into a dumpster and set it on fire. Refactor all of this code that had to be implemented in weird ways simply because of the desire for perfect backward-compatibility. And finally take the opportunity to have sane defaults, which alone will probably allow 12 different keywords to be stripped out of the evolved language.

zozbot234 5y ago
Building an "opinionated subset" of C++ is definitely non-trivial - the C++ Core Guidelines are the closest thing to that (with plenty of input from standard committee members) and they're still far less usable than an actual greenfield effort like Rust.

pipeline_peak 5y ago

[33.1] Is the type of "pointer-to-member-function" different from "pointer-to-function"? It’s interesting to notice how “this” is what distinguishes the two. When creating member functions in C, function pointers are assigned members. In order to access or change the object with an assigned function pointer, that object needs to be called or in other words, “this”. obj.member_function(&obj); In C++ would be obj.member_function();

BenjiWiebe 5y ago
People actually put functions in structs in C to make it look like OOP!? That's horrifying! Or am I (hopefully) misunderstanding something here?
- pipeline_peak 5y ago
  I'm not sure how common it is in practice. CPython and GTK are the most popular examples of OOP in C that I can think of. It's pretty pointless unless you want some sort of namespace-like organization. Maybe for polymorphism because you can change an instance's "base" member function pointer.

tpoacher 5y ago

> If you end up working with C++, don't try to "fix" it (or "boost" it). You'll just add more layers of complexity. The most productive approach is to accept the problems and try to write simple code which people can easily follow. I don't think this is specifically a C++ problem. It's true of any language, especially in a team setting. Reminds me of the post from yesterday, where some people where adding decorators in python to 'unmutate the mutable default argument' instead of just setting it to 'None'.