/prog/ - Valid C++ — Tinychan BBS

Name: Anonymous 2018-09-21 10:50

auto my_coroutine = [] do -> std::future<int> {
    int i = ([<-]std::foo()).size();
    return i [<-]std::bar();
}

Name: Anonymous 2018-09-21 11:03

but is it VALID PERL CODE?

Name: Anonymous 2018-09-21 11:20

WTF are do and [<-] supposed to do here? HIBT?

Name: Digital Nomad 2018-09-21 11:39

Though I code among the worst in the Valley, I shall fear no evil, because...?

Name: Anonymous 2018-09-21 12:01

>>3
Its likely some 2020 addition for lambdas. OP posted some experimental stuff barely supported by latest compilers.

Name: Anonymous 2018-09-21 12:08

Ok it's currently not valid C++ but it may be valid C++ in the future

>>3
The do is for differentiating coroutine lambdas from normal lambdas, the [<-] is like await
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1063r0.pdf

Name: Anonymous 2018-09-21 12:34

>>6

dfwehh8c34r899uiqeo78y23u8390u839283948djijduej89m849sl;
HAX MY ANUS!
(define my-other-car cdr)

this is valid C++ now. Ok it's currently not valid C++ but it may be valid C++ in the future

Name: Anonymous 2018-09-21 16:37

reminder that MODULES are supported already in C++ compilers

#include is deprecated

Name: Anonymous 2018-09-21 17:39

>>8
But can C++ modules #include <void.h>?

Name: Anonymous 2018-09-21 18:00

Removing #include will never happen.
Even if headers go extinct, its used for
#including arbitrary text data files: example->

char* pass=
#include "password.txt"
;
int a[]={
#include "array.data"
}

Name: Anonymous 2018-09-21 18:41

>>10
storing passwords in source code is a really bad idea.

Name: Anonymous 2018-09-21 19:28

>>11
A common misconception. In real world, your GIT/MERCURIAL/TeamFuckingCity is secured in the same (miserable) way as your password manager or database.

Name: Anonymous 2018-09-22 4:10

>>11,12
Not really. Its more like random salt used to add entropy for algorithms.
the char*pass is compile-script generated to make the binary have a unique pass(salt) that makes decrypting the user-facing data impossible without bruteforcing. Each binary has a different "*pass" so each client has different encrypted data (even if they use the same password).
Its essentially adding a one-time pad at compile time. The binary is not exposed, so its not "security by obscurity".

Name: Anonymous 2018-09-23 2:34

doesn't compile

Name: Anonymous 2018-09-24 3:29

>>11
technically it's not in the source code

Name: Anonymous 2018-09-24 6:57

>>13

the char*pass is compile-script generated to make the binary have a unique pass(salt) that makes decrypting the user-facing data impossible without bruteforcing.

it can still be reverse engineered from the executable binary you anus

Name: Anonymous 2018-09-24 8:28

>>16
That means you need to steal the clients binary first.

The binary is not exposed

Name: Anonymous 2018-09-24 8:31

expose my anus

Name: Cudder !cXCudderUE 2018-09-24 11:32

>>17
In which case it's pointless anyway.

Name: Anonymous 2018-09-24 11:54

>>4
As i step_through The.valley of Shadow of Code

Valid C++

1 Name: Anonymous 2018-09-21 10:50

2 Name: Anonymous 2018-09-21 11:03

3 Name: Anonymous 2018-09-21 11:20

4 Name: Digital Nomad 2018-09-21 11:39

5 Name: Anonymous 2018-09-21 12:01

6 Name: Anonymous 2018-09-21 12:08

7 Name: Anonymous 2018-09-21 12:34

8 Name: Anonymous 2018-09-21 16:37

9 Name: Anonymous 2018-09-21 17:39

10 Name: Anonymous 2018-09-21 18:00

11 Name: Anonymous 2018-09-21 18:41

12 Name: Anonymous 2018-09-21 19:28

13 Name: Anonymous 2018-09-22 4:10

14 Name: Anonymous 2018-09-23 2:34

15 Name: Anonymous 2018-09-24 3:29

16 Name: Anonymous 2018-09-24 6:57

17 Name: Anonymous 2018-09-24 8:28

18 Name: Anonymous 2018-09-24 8:31

19 Name: Cudder !cXCudderUE 2018-09-24 11:32

20 Name: Anonymous 2018-09-24 11:54