I know you were probably just throwing out the “90%” statistic, but if you take that as a given, the implication that 10% of the libstdc++ bugs on file are legit is a worrisome notion in and of its own right. I don’t want to be responsible for triaging those bugs (and nor do you, I am guessing; this being why the reports are valueless) but the fact that this is the bug rate in this, a gold-standard library in common, ubiquitous use… well as far as I can see, this is the context in which that the OP’s article should be considered.
… I build all of my C++ projects with Clang and link them against libc++, so I don’t know if I am dodging a very high-caliber bullet (so to speak) or if the other shoe will drop at some point, and I will find myself going down the OP’s rabbit-hole of library-bug investigation.
You are right, it's probably a lot less than that.
The bug quality is higher than you might expect, because you have to register with bugzilla, and most bug reports are with development versions, as bugs are shaken out of new features. There are very few bugs in released versions, and where those bugs exist they are often of the form "stupid type where I have redefined & doesn't compile, while the standard technically days it should", where most users would never got them. Wrong answer or crash bugs in releases are extremely rare, although they could be rarer -- the test suite has less coverage than I would personally like.
Do not use macros.
— Absolutely I agree: I involuntarily grimace whenever I look at and/or things like Boost MPL, or the wartier corners of the Python C-API’s underbelly, etc. I only use macros as straight-up batched ⌘-C-⌘-V:
Do not use typedefs to hide pointers […]
— I cannot stand it when people do this. That asterisk is as syntactically valuable to you, the programmer, as it is essential to your program’s function. If the standard library can slap asterisks on file and directory handles than so can you (and by “you” I specifically include whoever wrote the `gzip` API among other things).
[…] or to avoid writing “struct”
— Huh, actually I feel the opposite, I think all those “struct” identifiers are clutterific, much like excessive “typename” id’s in C++ template declarations. But so aside from the points where I totally disagree with the author, I absolutely feel the same way 100%.
I haven’t got a ton of experience in this arena, but what I have done in the past is: 1) incorporate the larger venture as an LLC (“My Company, LLC”); 2) incorporate the specific project as a C-Corp (“My Company’s App, Inc.”) – my partners and I own the LLC, which controls the C-Corp, which holds the assets of the project.
Specifically, this makes it easier if we want to sell ”My Company’s App“ to a Facebook- or Google-class buyer entity. The LLC can also incorporate a bank, if ”My Company’s App“ needs to start conducting transactions that necessitate the use of (say) a Federal Reserve client (á la Venmo or Stripe).
The hazy miasma visions of a perfect past can legitimatize themselves, in some, with far far less than 10 to 20 years. Some can do it in a span of weeks – q.v. “Where I Was From,” the memoir by Joan Didion (which specifically is about California, but is quite relevant to these topics to anyone most anywhere in the USA).
Yes, there is a Zen state of C++ programming wherein you, the programmer, surrender to the wisdom of the compiler, and in doing so are liberated from caring about the minutiae of the type system, to be carried forth, skyward, on the twin winds of inference and overload resolution. I do enjoy that. RTTI is nothing like this – it’s a red herring, neither elegant nor powerful… at best it’s a misnomer (it’s more like RTT total lack of I, amirite) and at worst a distraction.
I dislike exceptions too, but in a difference-of-opinion way where I can be like “OK, that otherwise legible and reasonable code uses exceptions, unlike mine” and it doesn’t make me grimace like I involuntarily do for RTTI… I’d love to be mistaken tho, anyone with an inspiring counterexample, do share.
Good start but -- some C++ stuff is wrong, e.g. in the bit on friend functions, a member function prototype is written with an empty block instead of a terminal ";". Subtle, but you know. Also, more subjectively, std::string is described as immutable, but with no further discussion about what that means or how that might work.
Just sayin. Frankly I like how it's not Wikipedianishly drowning in citations and/or demands for same -- but how does it get updated? I immediately tried to expand on those two issues I mentioned but there was no sort of UX recourse for my pedantic urges (FWIW)
Thanks for pointing that out! As of right now, it all gets updated manually (there's an internal CMS I built and use). As of right now, when people point out corrections they do so via feedback form, and I update accordingly (if I can verify it). Not the greatest but it's what's in place for the time being.
It'll later be open for others to provide new concepts and corrections.
Wow this takes me back – 2007, those were the days. Back before so many flagship projects had frankensteined libLLVM into their innards; before every single JavaScript framework was required by law to include at least one CLT whose executable name ended in 'c'; back when GCC on Apple was just a matter of /usr/bin, and not a parade of endless Homebrew formulae PRs… srsly dogg this is an excellent article, a product of its time but a bonafide bulwark, presciently on the precipice of paradigm. I +1'ed.
… also one of the forthcoming Clang projects is a static-analysis tool (á la `clang-format`) for replacing any `auto` decls with the actual typename, so you can write lazy code without appearing unscrupulous at code reviews
