Server based on beast.

[joka921]

No description provided.

[hannahbast]

Detailed 1-1 with Johannes, thank you very much!

[joka921]

@joaomarques90
Yes, you completely got my point. (Additionally I was tired).
At daylight I am confused about the following:

1. Variables can be referenced in their own initialization (size_t x = &x; is valid,
2. size_t x = x; also, but the latter case is rather pointless).
3. Apparently this also holds, if the initialization is an immediately invoked lambda
   ( size_t x = []() {return x;}();)
4. There must be some rationale behind this being valid (@hannahbast discovered the first case as an initialization of a somewhat random or at least nondeterministic seed in Google's absl library. But in the second case I am confused, that this works even if the lambda has no captures (size_t x = [x](){return x;}())

[joaomarques90]

When I said "pointer of vector-var 'types'" what I really meant was that the compiler already has that variable in stack (var name --> stack address line) exposed prior to the execution of the lambda.

Item 1.
size_t x = &x;
Shouldn't be valid due to pointer/type issues. But can if the compiler is permissive or you flag it.

Item 2.
size_t x = x;
It's redundant but valid. If you think on it by assembly: first declares it in memory, then copy the value to the register and then back to the memory. If the compiler is smart enough, it would even skip this, depending on the flag -Ox [except -O0] )

Item 3.

size_t x = []() {return x;}();
Invalid. Would work if, as mentioned above about this commit, it had a reference (or a copy). That lambda function does not have it in its own stack.

Item 4.
size_t x = [x](){return x;}()
Valid. It captures 'x' by value, not by reference, when you define the lambda. Therefore it has access to a copy of the var and its type. Two instances of the var in the memory for different stacks.

In all of them valid, the contents would be past-sediment-values.

I hope my answer does not contain errors. If so, my apologies.

[joka921]

@joaomarques90 You are correct about everything,
see-here(godbolt) .

To clarify my answer:
size_t x = &x // doesn't work because of the wrong type
but
size_t x = reinterpret_cast<size_t>(&x) // would.
(the reason why this fails is unrelated to the original topic).

You are also right about the lambda captures,
size_t x = [](){return x;}(); // doesn't work because of missing capture. *BUT, and here we come to why no compiler complained about my bug:* static size_t x = {return x;}(); // compiles without any warning.

(In fact Clang 13 only warns about the non-static lambda capture variant, GCC 11 also about the "default" variant at item 1.)

(@joaomarques90 in Markdown as its used here,
best enclose code example in backticks it then looks like this and all characters are shown`.)
I have edited your comment to this style:)

[hannahbast]

Another quick 1-1