Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cor3ntin.github.io

Post reply on HN
Print view View original

31–40 of 88 posts

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

#31

Post by MaxBarraclough »

miohtama wrote: post #13
linkdd wrote: post #10

Earlier quoted context omitted.

This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. Too bad those shitty engineers in the 70s didn't think of Rust...

They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.

> They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers.

That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).

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

#32

Post by gpderetta »

bregma wrote: post #17

I would hesitate to embrace a "universal" I/O abstraction that is architected around a monolithic kernel. Linux and Windows are not the only game in town. This design make make for a nice third-party library for some applications, but it has no place being cemented into the standard library.

The abstraction doesn't even require the existence of a kernel.

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

#33

Post by Const-me »

jcelerier wrote: post #2

In the end the overall design looks like a semi-reified asynchronous dataflow programming API based on coroutines. I think that it would be useful to consider the existing (very very very large) body of research on dataflow PL and APIs; e.g. check this paper from 1982 which talks about dataflow, coroutines, for handling file operations: - https://scholarship.claremont.edu/cgi/viewcontent.cgi?articl... More recent pap…

> 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, throwing tasks into a shared thread pool is the way to go.

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

#35

Post by v8dev123 »

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.

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

#36

Post by jbluepolarbear »

synergy20 wrote: post #15
jbluepolarbear wrote: post #4

There’s only one C++ library I’ll use for I/O and networking and that’s POCO C++. I’ve used it in a lot of project over the last 10 years and I haven’t seen a better solution.

its open source version has Boost license which is fine, not sure what's the difference between this and its POCO Pro product, it's better than QT license model for sure, but worse than than those "here is _all_ the code, pay me if you need professional service but not the code"

I’ve never used the pro version, which I think is just more specialized features on top of the core framework.

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

#37

Post by jfrd »

jfrd wrote: post #7

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20

For those who didn't click the link, this is a joke response to the author's tweet:

"I am bracing for the inevitable comments about C++ being the most terrible thing since forever :("

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

#38

Post by refenestrator »

titzer wrote: post #21
linkdd wrote: post #10

Earlier quoted context omitted.

This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. Too bad those shitty engineers in the 70s didn't think of Rust...

No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different. C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn'…

That portability to a zillion platforms was part of the language design, though. 'Portable assembler' and all that.

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

#40

Post by zvrba »

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…

> If I had the choice, I'd never use ASIO again and just use libuv.

Same here. I ported a legacy project from linux to windows, and continued to use ASIO (i.e., wrote new code) by inertia since the project already used it. Worst decision ever. If I could start from scratch, I'd just use raw Win32 APIs.

And I agree on HTTP(S). It has become an overcomplicated transport protocol on top of another transport protocol (TCP) and the only (though relevant) problem it solves is that it's allowed through most firewalls by default.

Post reply on HN