Sergey Zubkov
Sergey Zubkov
> sprinkling around a lot Sounds like an opportunity to privately resurrect [std::dynarray](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#dynarray)
@eyalroz I agree with your point but at the call,there was no consensus to choose hpp over other header naming conventions.
oops, as @bgloyer pointed out, the example would *not* break without the test. On self-move, it leaves this->ptr unmodified. (when `delete ptr;` executes, this->ptr is null, so it's a no-op,...
IMO nicest syntax is not even `return make_tuple(...);`, but simply `return {a, b};` Which, in this case, indeed has to become `return {move(large1), move(large2)};` to avoid copy ctors.
it used to work in both gh-pages and github, but then github started prefixing all custom anchors with `user-content`. So when guidelines.md says `# ES: Expressions and statements` gh-pages generates...
This seems to be, in essence, what https://github.com/isocpp/CppCoreGuidelines/pull/1596#issuecomment-1113901271 talks about
[E.2](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Re-throw) actually uses `fopen` in an example...
There are also people who default to `for (auto&& a : b)` in all cases, to avoid one potential corner case.
That may be related to (or even be a note on) [ES.56: Write std::move() only when you need to explicitly move an object to another scope](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-move)