I would upvote this ten times if I could. It’s the type of text I’m always looking for — something that covers a subject I’m working in / fascinated by, starts at the level I’m familiar with, and delivers tons of new ideas & advice.
In this case, I was inspired by Simon’s previous article on C++20 coroutines to experiment with them myself, starting by building & extending some of his sample code. A month or so later, I now have a coroutine runtime with generators, futures and a task scheduler, and I’ve linked with libuv and written a bunch of coroutine-based wrapper classes for sockets, file I/O, timers and such. I got TLS working as a stream connector class calling mbedTLS, and HTTP requests using llhhtp. It’s been a ton of fun, one of those projects where my progress feels limited mostly by my typing speed. (Once I got past some of the brain-hurting aspects of figuring out coroutines.)
OK, I’ve gone off-topic. I will unveil my library soon. Now I have lots of new ideas from Simon’s second article to think about.
Anyway, I’m a big fan of coroutines and async/await based code for I/O. It’s made working with network protocols a lot easier, for sure.
Programming language features are conveniences, not moral imperatives. They exist to make your life easier. So in a case where a feature doesn’t make your life easier, it’s OK not to use it.
For some reason this quote really stuck with me. Of course the counterpoint is that if you are maintaining a codebase in a language that has a very sharp edged feature, to it can be very hard to ensure it doesn’t creep into your code. For example see folks who attempt to write “sane” C++ but have to deal with the fact that other library authors may prevent you from avoiding those features such as exceptions.
I would upvote this ten times if I could. It’s the type of text I’m always looking for — something that covers a subject I’m working in / fascinated by, starts at the level I’m familiar with, and delivers tons of new ideas & advice.
In this case, I was inspired by Simon’s previous article on C++20 coroutines to experiment with them myself, starting by building & extending some of his sample code. A month or so later, I now have a coroutine runtime with generators, futures and a task scheduler, and I’ve linked with libuv and written a bunch of coroutine-based wrapper classes for sockets, file I/O, timers and such. I got TLS working as a stream connector class calling mbedTLS, and HTTP requests using llhhtp. It’s been a ton of fun, one of those projects where my progress feels limited mostly by my typing speed. (Once I got past some of the brain-hurting aspects of figuring out coroutines.)
OK, I’ve gone off-topic. I will unveil my library soon. Now I have lots of new ideas from Simon’s second article to think about.
Anyway, I’m a big fan of coroutines and async/await based code for I/O. It’s made working with network protocols a lot easier, for sure.
For some reason this quote really stuck with me. Of course the counterpoint is that if you are maintaining a codebase in a language that has a very sharp edged feature, to it can be very hard to ensure it doesn’t creep into your code. For example see folks who attempt to write “sane” C++ but have to deal with the fact that other library authors may prevent you from avoiding those features such as exceptions.