Jan Schultke
Jan Schultke
On line 5980 you use `std::strlen`. The namespaced version of this function is not defined in `"string.h"`, only in ``. This leads to a compilation error.
In line 518, `mz_uint64_t` is defined as unsigned long long. However, `std::uint64_t` on my platform (Linux 64-bit Debian 11) is defined as `unsigned long`. This leads to errors on multiple...
C.21 is missing an exception for the copy-and-swap idiom. It's perfectly safe (and considered idiomatic by many) for resource management to write: ```cpp T& operator=(T) noexcept { /* ... */...
A question which comes up every now and then is what type of loop variable you should use for range-based for, particularly when no mutation takes place. ```cpp // case...
F.45 is titled *"Don’t return a `T&&`"* and states: > We don’t know of any other good examples [besides `std::move`] of returning `&&`. This is ignorant of functions such as:...
This PR implements #1191. The colloquial term *"member variable"* is replaced with either: - the C++ standardese term *"data member"* - just *"reference member*", in the case of *"reference member...
Firstly, the explanation in [I.22](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-global-init) says that one of the initializations access an uninitialized object. I believe that this is not correct, and instead, a *zero-initialized* object is accessed. It's...
Should there be a guideline recommending against overloading operators that people almost never anticipate to be overloaded? This would include things like: - overloading the comma operator - overloading logical...
> With guaranteed copy elision, it is now almost always a pessimization to expressly use `std::move` in a return statement. The reasoning in **F.48** is misleading because it only refers...
Here is a suggestion for a rule which encourages the use of `if constexpr`. Not only do we repeat ourselves and keep logic less fragmented, we also save on compile...