What does HackerNews think of CppCoreGuidelines?
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
This is good too: https://github.com/isocpp/CppCoreGuidelines
I also liked Scott Meyer's book "Effective Modern C++".
On the topic of coding standards, there's an excellent github repo https://github.com/isocpp/CppCoreGuidelines which even quotes Bjarne Stroustrup as saying "Within C++ is a smaller, simpler, safer language struggling to get out." There are hundreds of recommendations, like 'ES.31: Don't use macros for constants or "functions"'.
In practice though that's simply not possible. E.g. trivial example but you couldn't ever depreciate #include even though we have #import now.
Instead of "fixing" the language, there's written (not enforced by the compiler) documentation https://github.com/isocpp/CppCoreGuidelines - actually the first line is the perfect summary:
"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup
This is great documentation (and many parts are relevant to other languages) but many of its proscriptions cannot be enforced by the compiler so it will always be opt in, mis interpreted or ignored.
Bjarne Stroustrup: C++ | Lex Fridman Podcast #48 https://www.youtube.com/watch?v=uTxRF5ag27A
1. Carefully. They only give you - roughly and unless you're super-lucky - around one order of magnitude improvement in raw flops and raw GB/sec memory bandwidth over a perfectly-exploited CPU. (Not that it's easy to properly exploit a CPU of course; it's actually quite difficult.) That means that if you cut even a few corners - you're just going to lose that edge, and a (again, perfectly-programmed) CPU beats you.
2. With a programming language which has zero or very-low cost abstractions, and models well the computations a GPU "thread" can perform. Preferably with some JIT'ing capability to be dynamic enough. For the first two, that trusty warthog, C++, does fairly well - especially with some help from nice libraries. (Shameless self-plug time... this kind of help: https://github.com/eyalroz/cuda-kat ; I'm thinking of submitting that to "Show HN" soon.) JITing for GPUs is maaaaasively under-explored and under-developed IMHO, and if someone is interesting in collaborating on that, feel free to write me.
Would other languages do? If there's not enough ability to abstract, you get a mountain of specialized code; if there's too much abstraction, you start paying through your nose. Could Rust work? I don't know. Perhaps one of those "better C"'s like Zig? The fact that CPU-side libraries can't really run on the GPU kind of levels the playing field against languages with a large base of already-written software.
> Ownership... C++ now tries to do "move semantics", with modest success, but has trouble checking at compile time for ownership errors
Actually, C++ has, over the past decade or so, introduced several measures to address the issue of ownership and resource leakage. If you combine move semantics, library facilities (mostly smart pointers), the problem is half-solved. Static analysis is improving too, especially when you "decorate" parameters, e.g. with `owner>` or `non_null>` and such. The "C++ Core Guidelines" (https://github.com/isocpp/CppCoreGuidelines) aim to be machine-checkable whenever possible.
https://github.com/phusion/passenger/blob/stable-5.3/src/cxx...
Has some issues.
There are pointers everywhere, even a void* *
It does not use RAII to manage resources, instead there a a bunch of raw pointer with sizes and a manually called free function
void freeAESEncrypted(AESEncResult &aesEnc);
Just from this brief look, it does not at all surprise me that the development velocity is suffering.
Joel's article on why you should never rewrite software is worth mentioning. There is probably a lot of institutional knowledge that is embedded in the code which will be lost if you convert to Go.
A better alternative might be to incrementally update the code to C++17 following C++ best practices https://github.com/isocpp/CppCoreGuidelines.
That way you always have a working product, that has the features and performance that people have come to expect, while at the same time you are eliminating technical debt and increasing development velocity.
In regards to the question about networking libraries all conflicting with each other, it is about to get better. The C++ committee will standardize a C++ Networking library in the near future. The good news is that it is based on asio https://think-async.com/ and asio is tracking the evolving standard. Most new C++ networking libraries are also standardizing on asio.
https://github.com/isocpp/CppCoreGuidelines
For those that aren't aware, actually some of the input from Microsoft side was based in the work done with Midori and having System C# ideas applied to C++.
VC++ with the code checkers and clang with clang-tidy.
Not sure about the current state of gcc or other commercial C++ compilers.
EDIT: In particular, the clang tidy linter has a way of checking your code against the C++ core guidelines [2], which is a set of modern best practices for the language.
[0] https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/
Could you describe what/who you think this is, because I don't really see a community as a whole for who the points you make are valid. Sure there's some crazy purists everywhere, but in general I don't think it's as bad as you mention. Then again might be biased because I write way more C++ than C.
I know cherry-picking isn't usually the most fair way to discuss, but some things really strike me as unfair so I can't help it.
obsessed with "best practices"
not sure if this is really bad? When pushed to the extreme it is, but that goes for anything extreme, but I don't really feel the C++ community is like that. At least I've read many times things in the spirit of 'best practices ar good, follwing them blindly is not'. Also anecdotally from all colleagues I ever worked with those with some healthy amount of (as in, still being able to think critically) obsession with trying to Do The Right Thing, always wrote better code than those who lacked that
OOP was oversold
it surely was, but imo one of the things modern C++ teaches us is exactly that: OOP overuse is bad and you don't have to use OOP at all in C++ if you don't want to
"some bloke named Herb says X, so you must follow him" sort of attitude
which is in turn countered by an attitude of questioning everything, no matter if the author is called Herb or Bjarne, and I don't think I'm dreaming that (at least I've seen many questions on SO starting with 'in xxx Herb says y, wtf is that all bout?'). On the other hand, those guys' advice is usually golden so following it won't hurt much, as long as you don't blindly follow it.
I just want to use the features of the language that make it easier and simpler to solve a problem more efficiently
in the end everybody wants this I guess, and I do have the feeling that when searching for questions to typical problems I usually do get an answer telling me exactly what to use. Also take https://github.com/isocpp/CppCoreGuidelines for example: sure theres a whole lot of info but it does give a ton of good/bad examples, plus reasoning behind it
[1] https://github.com/isocpp/CppCoreGuidelines
[2] https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr...
https://github.com/isocpp/CppCoreGuidelines
So not the sort of thing one can answer in-line in an HN comment.
https://isocpp.org/blog/2015/09/stroustrup-cppcon15-keynote
clang-tidy: http://clang.llvm.org/extra/clang-tidy/
clang-format: http://clang.llvm.org/docs/ClangFormat.html
C++ Core Guidelines: https://github.com/isocpp/CppCoreGuidelines
C++ Core Guidelines Checkers for VS 2015 Update 1: https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...
Like this?
"The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule. We do not expect you to memorize all the rules before trying to write code."