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++

Language: Python

> Quite good reading to stay up to date how to write proper C++ code instead of classical C with C++ compiler,

This is good too: https://github.com/isocpp/CppCoreGuidelines

I also liked Scott Meyer's book "Effective Modern C++".

That's great to hear! I'm sure I could find it, but are the libreoffice coding standards written down (and could you send them my way)?

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"'.

You gloss over the complexity cost of having too many overlapping tools in the bag though, a complexity cost that has drowned projects in the past. Arguably C++ as a language could be improved if someone was able to depreciate and remove the "legacy" parts.

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.

> GPUs. Biggest compute engines we have. How do we program them?

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.

Once you've become familiar with the basics of the language, I highly recommend taking a look at C++ Core Guidelines

https://github.com/isocpp/CppCoreGuidelines

The answer is essentially no, at least if you're seeking substantial levels of assurance or safety. Even the C++ Core Guidelines effort, https://github.com/isocpp/CppCoreGuidelines which is the closest thing to what you describe and is driven by influential members of the ISO C++ community including B. Stroustrup, does not claim that they'll be able to make C++ memory safe.
Another alternative is to migrate to Modern C++. I just did a quick look through the code base.

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.

There is ongoing work to have linters advice on the Core Guidelines items, which are considered the best practices.

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.

C++ has that. Check out clang_tidy [1].

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.

[1]. http://clang.llvm.org/extra/clang-tidy/

[2]. https://github.com/isocpp/CppCoreGuidelines

I thought there was a checker (based on clang) included by the CPP Core Guidelines [0], but I'm not seeing it there currently. Must have been external. I know I saw a tool that provided partial support, at least for GSL [1] (MS's library support of the the CPP Core Guidelines).

[0] https://github.com/isocpp/CppCoreGuidelines [1] https://github.com/microsoft/gsl/

the "Modern C++" community

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

Good supplementary material to the C++ Core Guidelines.[1] If you haven't checked it out yet, both VS 2015 and clang offer checkers[2]

[1] https://github.com/isocpp/CppCoreGuidelines

[2] https://reviews.llvm.org/diffusion/L/browse/clang-tools-extr...

The answer(s) to that question take(s) the form of documents with many dozens or hundreds of pages. For example:

https://github.com/isocpp/CppCoreGuidelines

So not the sort of thing one can answer in-line in an HN comment.

The C++ standards committee has started a guidelines document which encompasses the latest features of C++11/14

https://github.com/isocpp/CppCoreGuidelines

Quite concise and short. Now wouldn't it be great to also have such a short guide for C++... (thinking about the tome that is https://github.com/isocpp/CppCoreGuidelines)
https://github.com/isocpp/CppCoreGuidelines

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."