A Universal I/O Abstraction for C++ (2020)

Post by Const-me » Mon, Apr 19, 2021, 7:09 AM UTC

jcelerier wrote: post #51

Const-me wrote: post #33

Earlier quoted context omitted.

> if we know that a set of tasks are dependent on each other in ways that aren't visible on the source code, but are known to the programmers, it would make sense to schedule them on a queue in their own thread Why it would make sense? In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. Generally,…

> In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. well, yes, those are things that happen fairly often. e.g. there's a lot of work on optimizing code for various arm big.LITTLE things, where you have some algorithm that you want to make sure runs on the "big" cores.

Post by gpderetta » Mon, Apr 19, 2021, 7:20 AM UTC

jcelerier wrote: post #50

gpderetta wrote: post #8

Earlier quoted context omitted.

Hum, in principle you can do arbitrary compile time transformations to the datagraph before submitting it via metaprogramming. If you really want you could even convert the graph (fully or partially) to a runtime representation. The core of the proposals are not about specific classes or functions other than some default algorithm implementations. Instead they are mostly about defining concepts and protocols so that…

> Hum, in principle you can do arbitrary compile time transformations to the datagraph before submitting it via metaprogramming. I would find that to be great, but I don't understand how. In e.g. while(i) { co_await sch.schedule(std::chrono::milliseconds(100)); co_await w.write(--i); } how can you get a meaningful "graph" object out of that, e.g. [wait 100] -> [write 9] -> [wait 100] -> [write 8] -> ... without actua…

Post by jabl » Mon, Apr 19, 2021, 7:30 AM UTC

pjmlp wrote: post #49

Koshkin wrote: post #28

Earlier quoted context omitted.

Problem was, real world programming in Lisp was not simple.

Just like real world programming in C is hardly memory corruption free, and only around 10% of survey answers keep asserting to use any kind of memory assurance tooling.

Post by secondcoming » Mon, Apr 19, 2021, 7:59 AM UTC

MaxBarraclough wrote: post #30

Koshkin wrote: post #27

Earlier quoted context omitted.

Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.

A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.

Post by nly » Mon, Apr 19, 2021, 9:57 AM UTC

v8dev123 wrote: post #35

secondcoming wrote: post #6

C++'s networking support is one of its greatest shortcomings. If I had the choice, I'd never use ASIO again and just use libuv. Coroutines look interesting, I just need to get my head around them. All code examples I've seen, just as with ASIO, deal with the happy path only. For example, there's hardly a mention of timeouts and the faff ASIO makes you do to get them to work. If there's no 'read(..., timeout)' functio…

You might love evpp instead ASIO. It's just pain to install it but once you do it's a heaven. As for HTTP parsing, llhttp does great job. It however lack multipart parsing.