Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

I'm very disappointed the networking ts wasn't included (I must have missed when that stopped being a C++ 17 thing). It's one of the few things missing that would let me use C++ for more projects (yes I know I can just include the boost library since that's essentially what it'll be but that's not always the easiest thing to grab and build into an existing project (at least not for a C++ novice like myself) but being part of the standard will make it immensely more accessible).

At least it still exists much like some of the other ones like the filesystem ts. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n458...

View on HN

I'm not sure that you should be writing network code in C++ (which is a notorious source of nasty security bugs) if you're not comfortable enough with C++ to link against one of its most popular freely-available libraries.

I'd rather the committee focus on longstanding language core issues than add everyone's favorite library.

If you're in video game or embedded system, it's a different story.

Libraries are fine, but the problem here might be about OS or platform.

I had to write a plug in that makes a REST call a couple of weeks ago. This thing was ~200 LOC max and I had to link to a library that is orders of magnitude larger just to make an HTTP call. I would have loved some standard networking functionality in that instance.

https://github.com/mrtazz/restclient-cpp ? 2 LOC. Wraps libcurl.

The point was that you have to pull in third party library; LOC has nothing to do with it. I know all about libcurl. I work on an FDA regulated product; do you know what it takes for me to get third party code into our system?

Meh, I used to use C++ about 10 years ago and very much enjoyed it but the lack of multiple, built-in and cross-platform ways of doing things, like networking that higher level languages had I just simply stopped using it. This would give me an excuse to check it out again because, being part of the STL, it would be trivial to include in a project.

If I have a reason to use the language I can learn the build tooling (which last time I used C++ they were very, very old and overly complex IMO; nothing easy like rust's).

If you want to drive adoption of C++ you need to lower friction to using it. This works in every single thing ever created. If you can get more features into the STL that the vast, vast majority of languages have built in and get good tooling you'll have a very easy way for someone to jump into the language.

Alternatively you can continue to keep the friction high and address "language core issues" instead of making the STL have parity with all other popular languages. I think that approach is terrible but only if your goal is to grow the community of developers. But that's just my opinion of someone who loved C++ 10 years ago but had to move to higher level languages just to get stuff done, quickly and efficiently.

Networking TS is pretty much based on the Boost Asio library. In fact, there is a non-boost standalone Asio library http://think-async.com/Asio/AsioStandalone that has no dependencies on boost and can just be used as a header-only library.

Using sockets is very portable imo. If I remember correctly there's only 2 functions that differ between linux and windows[1]. I'd rather use 2 source files than the whole boost asio/networking library.

[1] Those are ioctlsocket vs ioctl, and closesocket vs close. A basic TCP implementation can be cross platform with as little as 2 #ifdef/#endif blocks.

Only if you are sticking to synchronous IO. With nonblocking and async IO it gets much more complicated.

You should have a look at the Conan package manager. It'll allow you to use Boost (and other libraries) rather easily in your project.

Why not just use boost.asio? It even supports coroutines now.

Reply on news.ycombinator.com