Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20
All those "orange site bad" comments lol
A Universal I/O Abstraction for C++ (2020)
11–20 of 88 posts
Re: A Universal I/O Abstraction for C++ (2020)
#12Earlier quoted context omitted.
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
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...
> Too bad those shitty engineers in the 70s didn't think of Rust...
True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model.
OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG
Re: A Universal I/O Abstraction for C++ (2020)
#13Earlier quoted context omitted.
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
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.
Re: A Universal I/O Abstraction for C++ (2020)
#14Earlier 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...
> Too bad those shitty engineers in the 70s didn't think of Rust... True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model. OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG
That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language.
The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity.
We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
Re: A Universal I/O Abstraction for C++ (2020)
#15There’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"
Re: A Universal I/O Abstraction for C++ (2020)
#16C++'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…
what about POCO libs mentioned above for network and IO applications?
Re: A Universal I/O Abstraction for C++ (2020)
#17I 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.
Re: A Universal I/O Abstraction for C++ (2020)
#18Earlier quoted context omitted.
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
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...
Adding slices to C would kill a lot of bugs without going all the way to rust.
Re: A Universal I/O Abstraction for C++ (2020)
#19Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
The late pioneer in compiler optimization--Frances Allen--agrees.
2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."
"There was an interesting debate at the SIGPLAN conference in that period--about the relative need for optimization. It was put on the table that it wasn't going to be needed anymore! So. Anyway. You can have your own opinion on that, but I know I have mine, beyond a doubt that it was a huge setback for--in my opinion--languages and compilers--and the ability to deliver performance--easily--to the user."
Re: A Universal I/O Abstraction for C++ (2020)
#20Earlier quoted context omitted.
Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.
The late pioneer in compiler optimization--Frances Allen--agrees. 2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data-…
She's exactly right. I'm really not sure how we came to accept the worse-is-better argument that high performance required exposing machine details into the source language, and letting compiler writers just "do whatever is fastest", regardless of safety. It gave rise to today's situation where none of application writers, library writers, kernel writers, or compiler writers are quite sure what will happen if a new optimization is introduced. Will it break programs? By how much? Well, let's roll the dice! This is a direct result of allowing--no, even expecting--programmers to peer behind the curtains to see machine details that they frankly, shouldn't. It's why porting programs from one machine to another is even a thing, as opposed to just selecting a different output from a compiler, or running a different VM.
Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.