papers VS CppCoreGuidelines

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are:

- The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045

- The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interpreted as preemptively foreclosing a Safe C++-style approach: https://github.com/cplusplus/papers/issues/2121

And yet, there is a good chance that C++ will start doing exactly this [1]. Because [2]:

> The performance impact is negligible (less that 0.5% regression) to slightly positive (that is, some code gets faster by up to 1%). The code size impact is negligible (smaller than 0.5%). Compile-time regressions are negligible. Were overheads to matter for particular coding patterns, compilers would be able to obviate most of them.

> The only significant performance/code regressions are when code has very large automatic storage duration objects. We provide an attribute to opt-out of zero-initialization of objects of automatic storage duration. We then expect that programmer can audit their code for this attribute, and ensure that the unsafe subset of C++ is used in a safe manner.

> This change was not possible 30 years ago because optimizations simply were not as good as they are today, and the costs were too high. The costs are now negligible.

[1] https://github.com/cplusplus/papers/issues/1401

[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

For whatever its worth, if we wait long enough C++ will include the equivalent of `malloc_good_size`. https://github.com/cplusplus/papers/issues/18

https://github.com/cplusplus/papers/issues/1668#issuecomment...

Looks like it did very well in St. Louis!

It is slowly making its way through the standards committee. https://github.com/cplusplus/papers/issues/43

The author has a fork of clang and gcc with some pretty impressive speedups, so I’m hopeful! https://lists.isocpp.org/sg14/2024/04/1127.php

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

C++ lambdas can be used to achieve a similar result, not as pretty though https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines... But in general I agree!

If that is what profiles were actually doing, it would probably make sense. But it's not what profiles are doing.

Instead, for example, the lifetime safety profile (https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...) is a Rust-like compile time borrow checker that relies on annotations like [[clang::lifetimebound]], yet they also repeatedly insist that profiles will not require this kind of annotation (see the papers linked from https://www.circle-lang.org/draft-profiles.html#abstract).

Their messaging is just not consistent with the concrete proposals they have described, let alone actually implemented.

"C++ Core Guidelines" by Bjarne Stroustrup and Herb Sutter Read the guidelines

I've found both explicit future/promise management and coroutines difficult (even irritating) to reason about. Co-routines look simpler at the surface (than explicit future chaining), and so their the syntax is less atrocious, but there are nasty traps. For example:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

I liked "Effective Modern C++" although that is a little bit out of date by now. Stroustrup's recent article "21st century C++" https://cacm.acm.org/blogcacm/21st-century-c/ . There are also the C++ core guidelines though maybe those are also out of date? https://github.com/isocpp/CppCoreGuidelines

I've been looking at Rust and it's an improvement over C, but it still strikes me as a work in progress, and its attitude is less paranoid than that of Ada. I'd at least like to see options to crank up the paranoia level. Maybe Ada itself will keep adapting too. Ada is clunky, but it is way more mature than Rust.

I haven't read much from Bjarne but this is refreshingly self-aware and paints a hopeful path to standardize around "the good parts" of C++.

As a C++ newbie I just don't understand the recommended path I'm supposed to follow, though. It seems to be a mix of "a book of guidelines" and "a package that shows you how you should be using those guidelines via implementation of their principles".

After some digging it looks like the guidebook is the "C++ Core Guidelines":

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

And that I should read it and then:

> use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).

Which seems to be this (at least Microsoft's implementation):

https://github.com/microsoft/GSL

And I'm left wondering, is this just how C++ is? Can't the language provide tooling for me to better adhere to its guidelines, bake in "blessed" features and deprecate what Bjarne calls, "the use of low-level, inefficient, and error-prone features"?

See this: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

Technically, headers are just copy-paste, obviously. However, there's value to keeping them as standalone as possible.

> close a file (which ironically is the poster child for RAII)

Yes, I call this "RAII is a lie" (T-shirt pending).

Closing file descriptors is univerally used to showcase RAII, but it should never be used for that.

C++ has the same problem:

https://github.com/isocpp/CppCoreGuidelines/issues/2203

In there, it is acknowledged that a manual Close() should always be provided, and used if you want guarantees.

> is a bad pattern

Good that Rust at least figured it out early that it's a bad pattern!

Never use RAII in situations where the cleanup can fail!