6 ms·

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 li

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.

jokoon 10y ago
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.
EpicEng 10y ago
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.
- nambit 10y ago
  https://github.com/mrtazz/restclient-cpp https://github.com/mrtazz/restclient-cpp ? 2 LOC. Wraps libcurl.
  - EpicEng 10y ago
    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?
BinaryIdiot 10y ago
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.

jokoon 10y ago

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.

EpicEng 10y ago

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.

nambit 10y ago
https://github.com/mrtazz/restclient-cpp https://github.com/mrtazz/restclient-cpp ? 2 LOC. Wraps libcurl.
- EpicEng 10y ago
  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?

BinaryIdiot 10y ago

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.