hat case the proposed `[[strict]]` is the right tool.
2. The user expects unhanded values and needs them covered. Then the `__ => /*else*/` is available.
3. However, if the user expects, *but does not care,* then we simply value-initialize the return type, if not void, and return it. If the return type is a reference, the program is ill-formed (catch-all case needed).

Let's see two quick examples of the last case.

auto val = Something{inspect(v) { a => "one"s, b => "two"s, c = "tree"s }};

If the user writes this, he might *genuinely* not care whether a 'd' comes along and will *happily* construct `Something` from an empty string if that happens. If he *does* care, he has not one but *two* options, but if we throw and he does not care, he will be *forced* to add a catch-all and clutter his code undesirably.

Another, even better example

if(inspect(v)
{
pattern1 => true,
pattern2 => true,
pattern3 => true
})
{...}

Do we *really* want to force writing `__ => {}` here?!? (On a sidenote, we do need OR!)

In any case, if the value-initialization is unacceptable for some reason, I am willing to argue an alternative, to have mandatory catch-all or else to default to `[[strict]]` is better then using an exception! Somewhat of a KISS approach - either say it every time or get a safety-net without asking. With the exception one will be just annoyed, not once, but *twice* \- once when he/she crashes, and another when he/she adds something just to shut the error down.

**One last thing**

Can we use just `=>` for both expression and statement forms? This way we can gain multiple benefits:

* One could instantly grasp if the code is PM, even from a small snippet, be it on the internet or part of a long `inspect`.
* It will completely free `:` for use inside patterns and every bit of syntax there is welcome.
* It will eliminate the clash with C labels, allowing us to use labels to create local jumps.
* It will eliminate questions why there are two syntaxes without introducing different behavior, considering expressions are already differentiated by using `,`, alongside context.
* It will allow us to reuse the `switch` keyword as there is no confusion how the statements behave.

About the last point. I think it is more easy to learn that the each behavior is used with its own syntax - ordered & no-fallthrogh with `=>`, any-order & fallthrough with `:` \- instead of what we have now, having separate names at the top, yet using potentially the same syntax in the body.

**Conclusion**

I guess the main conclusion is, there is no "simple" PM. Because of the dense context, every pattern, at some point, benefits from "being smart" and/or multi-purpose.

Of course the question is - where to draw the line? The line in general and the line for 23. Is it better to be "full featured", but not very smart (at the beginning?) or "be smart" but not full featured? My personal believe is, we better do less and "be smart", because being smart will pay off every day, for everyone, where being "full featured" will pay off only sometimes, for some people. And we also saw, being "full featured" does not help you with day-to-day code.

In that light, I don't mind having no extractors and even no field-selecting, but have OR and AND as well as automatic deference and "active type" matching for 23. And for 26, we could get "the rest", hopefully including a way to deconstruct higher-level objects, not just structs.

That wraps it out for now, Thank You for reading 8 screens (at 1440p) of text!

\*

CppCon: [https://youtu.be/PBZBG4nZXhk](https://youtu.be/PBZBG4nZXhk)

The Paper: [https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1371r1.pdf](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1371r1.pdf)

https://redd.it/dmvipo
@r_cpp

CppCon 2019: René Rivera “Algorithm Magic”
https://www.youtube.com/watch?v=l9RKWUMfY-4

https://redd.it/dmvw2l
@r_cpp

CppCon 2019: Boris Kolpackov “Why is C++ so Slow?”
https://www.youtube.com/watch?v=j-0_D4yLhj4

https://redd.it/dmxx8l
@r_cpp

CppCon 2019: Jens Weller “Modern C++ Macros”
https://www.youtube.com/watch?v=uY4iZAuov_I

https://redd.it/dmxc4z
@r_cpp

CppCon 2019: Staffan Tjernström “My Temporary Materialization Misconception”
https://www.youtube.com/watch?v=5v8Iyix0kAU

https://redd.it/dmzfyh
@r_cpp

C++ VS Java VS JavaScript - same task - surprising run-times diff

Hey guys,

It all began from me wanting to test different JIT optimizations and see how they affect run-time.

I assumed the first best step to do it would be to take some task, write it in C++, Java and JavaScript and compare the run times.

Well, I'm a bit surprised..I got some interesting results I wanted to share and hear some insights from you smart people :)

**The task:**

\- From 1000000000 numbers that are created from a uniform distribution from 1 to 100 - Count the numbers that are bigger than 75

**The code:**

* C++ - [https://gist.github.com/tomerdbz/49af64abb845c34e6ae7ad36c94ea4be](https://gist.github.com/tomerdbz/49af64abb845c34e6ae7ad36c94ea4be)
* Java - [https://gist.github.com/tomerdbz/edc05ce6071bc7f568e4fbb03a61538c](https://gist.github.com/tomerdbz/edc05ce6071bc7f568e4fbb03a61538c)
* JavaScript - [https://gist.github.com/tomerdbz/318f5e8fe73b925879d355211ae5c481](https://gist.github.com/tomerdbz/318f5e8fe73b925879d355211ae5c481)

**The results:**

* C++ (Visual Studio 2019 LLVM Release x64, i.e clang /O2 /Ot): Time took: 12.2325
* Java (default Eclipse): Time took: 9.489
* JavaScript (default node): Time took: 15.893

Does someone has a clue why the results seem like that?

(Gotta say before I conducted these I'd bet the runtime results would be JS < Java < CPP)

https://redd.it/dmxadi
@r_cpp

Request-Response pattern in C++ actor frameworks (caf, sobjectizer, rotor)
https://basiliscos.github.io/blog/2019/10/05/request-response-message-exchange-pattern

https://redd.it/dn1mi3
@r_cpp

Getting to the next Level

Hello guys. So I have a little experience with c++. Well I know the basics, like I know data structures and their methods, like vector, map, set, arrays and I use the language as the main language for competitive programming. However, reading some codes of other competitors I found that I had little knowledge(like I was using iterator to iterate the map when I could do something like for(auto & entry : map)... ). I usually submit codes on GNU C++14 compiler. So I wonder, how can I become more familiar with the language? What are the best resources to improve my knowledge? Thanks in advance.

https://redd.it/dn51kk
@r_cpp

Unproductive challenge - longest variable declaration in C++

I came up with a stupid, unproductive (yet to me interesting) challenge I summarized here:

[https://shaharmike.com/cpp/longest-var-decl/](https://shaharmike.com/cpp/longest-var-decl/)

Any ideas how to get to a longer declaration? :)

https://redd.it/dn8qrq
@r_cpp

How to export C++ library: An OS-agnostic C++ library template in plain CMake
https://github.com/robotology/how-to-export-cpp-library

https://redd.it/dnc0n2
@r_cpp

constexpr-contracts: a constexpr-friendly, C++20 contracts library
https://github.com/cjdb/constexpr-contracts

https://redd.it/dnd15w
@r_cpp

How to compress C++ headers?

Does anyone know of any existing tools to compress a C++ header? Not interested in compression libraries, but instead on a tool that can take a human-readable header and remove comments, whitespace, etc... to make the header smaller and faster to compile.

https://redd.it/dnh7fh
@r_cpp

How are you supposed to combine vcpkg, cmake and anaconda-python?

I'm writing a library in C++ that I want to use from python. I'm using vcpkg for dependencies of the C++-library (boost, fmtlib, etc). Anyone have a flexible setup to solve this scenario?

https://redd.it/dnjbve
@r_cpp

CppCon 2019 - Beautiful Folds (Manuel Bergler)

[https://youtu.be/\_orZeboZS\_w](https://youtu.be/_orZeboZS_w)

[https://github.com/Corristo/beautiful\_folds](https://github.com/Corristo/beautiful_folds)

Just watched this talk and was amazed. Defining a function almost like a mathematical formula (no loops), e.g.

constexpr std::array<int, 10> input{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
auto standard_deviation = sqrt(1.0 * sum_of_squares / length - square(average<>));
auto [sum, max, std_dev] = reduce(folds::sum, folds::max, standard_deviation)(input);

Apparently this relies on C++20. Just curious, couldn't this be done with C++17 fold expressions too?

https://redd.it/dnle19
@r_cpp

The Case for C++
https://itnext.io/the-case-for-c-4122a5b47130

https://redd.it/dnm77y
@r_cpp

ABI: Now or Never
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf

https://redd.it/dnr2e1
@r_cpp

C++ Day 2019
https://isocpp.org/blog/2019/10/cppday19

https://redd.it/dnr0r2
@r_cpp

Exception handling in emscripten: how it works and why it’s disabled by default
https://brionv.com/log/2019/10/24/exception-handling-in-emscripten-how-it-works-and-why-its-disabled-by-default/

https://redd.it/dnsryb
@r_cpp

Educational code in Boost

I have been working on writing more idiomatic modern C++ and came upon some nice, limited-scope code in a couple Boost libraries, which wouldn't be too out-of-place in the [cppreference.com](https://cppreference.com) samples. These may not be the most robust implementations, but they are readable, not a ton of feature test macros, etc. Here are a few examples that I found useful (not exhaustive):

**Boost.Asio**
* [boost/asio/error.hpp](https://github.com/boostorg/asio/blob/develop/include/boost/asio/error.hpp): using the new error handling facilities in `<system_error>` with `std::is_error_code_enum` or Boost.System equivalent.

**Boost.Beast**
* [boost/beast/core/detail/variant.hpp](https://github.com/boostorg/beast/blob/develop/include/boost/beast/core/detail/variant.hpp): simple variant implementation using uninitialized storage (such as `std::aligned_storage` or `std::aligned_union`) and the very useful Boost.Mp11 function `mp_with_index` for type erasure. Avoids undefined behavior using `std::launder` (if supported),
* [boost/beast/core/span.hpp](https://github.com/boostorg/beast/blob/develop/include/boost/beast/core/span.hpp): simple implementation of `std::span`. Also see [boost/beast/core/detail/type_traits.hpp](https://github.com/boostorg/beast/blob/develop/include/boost/beast/core/detail/type_traits.hpp) for the `is_contiguous_container` type trait. This just checks for the presence of a .data() member so it won't work with something like `std::valarray`, but it's nice and simple. Something like [nlohmann::detail::input_adapter](https://github.com/nlohmann/json/blob/a6bd798bfac278e332dc050c73bee9a513e36640/include/nlohmann/detail/input/input_adapters.hpp#L381-L440) might be more robust.

**Boost.Histogram**
- [boost/histogram/detail/iterator_adaptor.hpp](https://github.com/boostorg/histogram/blob/develop/include/boost/histogram/detail/iterator_adaptor.hpp): simple iterator implementation for custom types. This is just the first example that came to mind; there is a lot of other nice, easy to understand code in this library.

Any other suggestions for educational and readable library code? No need to limit to Boost, it's just a convenient starting point as these libraries are well-tested and peer-reviewed.

https://redd.it/dnxns9
@r_cpp

Proof of concept: runtime heterogeneous containers don't need to rely on dynamic dispatch.

Hello,

I want to contribute an approach to dealing with dynamic heterogeneous containers, i.e., containers that can hold different types. I have developed a [proof of concept implementation](https://github.com/nasosi/eumorphic) of such containers that do not rely on type erasure or inheritance.

The design is motivated by the following needs:

A. *Eliminate coupling* between the data types stored in heterogeneous containers.

B. *Eliminate reference semantic*s both in the interface and the container backbone.

C. *Achieve high performanc*e, beyond what polymorphic or type erasure dynamic dispatch can achieve.

The implementation is not based on typical polymorphic access patterns; in fact, it avoids them. In a sense, it achieves similar behavior as them, but instead of erasing type, it retains it. The core implementation is also surprisingly compact, which makes me wonder if others have followed this approach.

Properties, advantages and disadvantages of the approach include:

1. The data retains its value semantics throughout its lifetime.

2. It is directly implied from 1. that the user interacts with value semantics at all interaction points.

3. There is no type Erasure. The data type is always the concrete constructed type.

4. For unordered containers, there are no virtual functions or vtables, explicit or implicit, anywhere in the pipeline. For ordered containers there is although a dynamic mechanism.

5. The containers can be generated on the heap or the stack.

6. A significant downside is that the types stored in the container need to be known at compile-time like std::variant.

7. Minimal boilerplate is required. No registration of member functions is needed.

8. Performance exceeds or is similar to any other pattern benchmarked. (in some cases x5 higher performance for types that implement similar concepts).

The concept I came up with is similar to boost polycollection, but with static, rather than dynamic, value semantics. It thus provides further performance, safety, and brevity benefits.

The core of the implementation is very brief thanks to boost::hana.

I am very interested in receiving feedback on such an approach and/or being educated about patterns that achieve the same.

Thank you!

Edit: typo

https://redd.it/dnyneq
@r_cpp

CppCon 2019: Javier Estrada “A Conversion Story: Improving from_chars an...

You can find a more detailed explanation and examples in my blog:

[A Conversion Story: Improving from\_chars and to\_chars in C++17](https://javierestrada.blog/2019/06/15/a-conversion-story-improving-from_chars-and-to_chars-in-c17/)

and GitHub for code;

[Character Conversion Utilities](https://github.com/ljestrada/charconvutils)

https://redd.it/dnzwlt
@r_cpp