6 ms·

> Oh. And we’re still lacking any kind of sockets support. There’s this thing I’m hearing about called the Internet that’s going to be big any day now and might

by fivea 5y ago

> Oh. And we’re still lacking any kind of sockets support. There’s this thing I’m hearing about called the Internet that’s going to be big any day now and might need this. Between libcurl, POCO, or even Qt, does it matter at all that the C++ standard offers "any kind of sockets support"? Just because Java forced everything under the sun into their standard library, that does not mean that move makes any sense at all. Between Boost and Apache and POCO and others like that, it's high time we stop insisting in this nonsense.

vlovich123 5y ago
That’s one position. The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. You could easily make the same counter argument against including <filesystem> and yet there’s very real value to having something cross platform out of the box that handles elegantly various pitfalls that people typically fall into.
- fivea 5y ago
  > The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. Given that Java followed that path and already acknowledged that mistake by deprecating the original HTTP client, why do people insist in not learning lessons?
  - pjmlp 5y ago
    Because what the standard library offers, is supposed to be available across all platforms and implementations of a specific language, with a certain expectation level in quality. What is available as external library has various levels of support quality. That is why we have POSIX, the C runtime that ISO C didn't want to rely on, yet almost every C program uses a part of it.
    - jstimpfle 5y ago
      Pretty sure many or most Windows programs don't use the POSIX library.
      - pjmlp 5y ago
        Indeed, there is a semantic difference between almost every and all of them. Still it was deemed important enough to spend development resources on the POSIX subsystem to make DoD happy, then SFU and now integrate the Linux kernel.
        jstimpfle 5y ago
        I don't think there is a need to bring up "semantics" here, and the only reasonably defined semantics that I know for the term "almost all" would be from set theory where that is a useless term without an infinite set to measure against. Common sense anyway would suggest that "almost every" is distinct from "many, but also many not", and the latter is what I think would be a better fit here. The intention behind my comment (and I thought it was clear without any "semantics" discussion required) was to show that there is no need for the POSIX layer to be included as part of ISO C. POSIX is just a "platform layer" (for all I know), meaning that it is much closer to a "library" than a "runtime". I don't see a need to bundle it tightly with the language. Heck, why did I even bring up Windows as a counterexample, when there are probably a lot of more-or-less ISO C conforming compilers for microcontroller platforms that could never support POSIX.
  - vlovich123 5y ago
    HTTP != sockets. I’m not arguing for HTTP within the standard library but for low-level networking support. That one should be non controversial. As for HTTP within the standard library, I would probably tend to agree although I’d note that Python does have it in its standard module set and I don’t think there’s an acknowledgement that that’s somehow a mistake. Each language fills a different need so framing it as “people insisting in not learning lessons” isn’t helpful. Not to mention that the best way to learn is to experiment and double check if what was once true remains that way (experts know when and in what way to break rules).

by fivea 5y ago

vlovich123 5y ago

That’s one position. The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. You could easily make the same counter argument against including <filesystem> and yet there’s very real value to having something cross platform out of the box that handles elegantly various pitfalls that people typically fall into.

fivea 5y ago
> The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. Given that Java followed that path and already acknowledged that mistake by deprecating the original HTTP client, why do people insist in not learning lessons?
- pjmlp 5y ago
  Because what the standard library offers, is supposed to be available across all platforms and implementations of a specific language, with a certain expectation level in quality. What is available as external library has various levels of support quality. That is why we have POSIX, the C runtime that ISO C didn't want to rely on, yet almost every C program uses a part of it.
  - jstimpfle 5y ago
    Pretty sure many or most Windows programs don't use the POSIX library.
    - pjmlp 5y ago
      Indeed, there is a semantic difference between almost every and all of them. Still it was deemed important enough to spend development resources on the POSIX subsystem to make DoD happy, then SFU and now integrate the Linux kernel.
      - jstimpfle 5y ago
        I don't think there is a need to bring up "semantics" here, and the only reasonably defined semantics that I know for the term "almost all" would be from set theory where that is a useless term without an infinite set to measure against. Common sense anyway would suggest that "almost every" is distinct from "many, but also many not", and the latter is what I think would be a better fit here. The intention behind my comment (and I thought it was clear without any "semantics" discussion required) was to show that there is no need for the POSIX layer to be included as part of ISO C. POSIX is just a "platform layer" (for all I know), meaning that it is much closer to a "library" than a "runtime". I don't see a need to bundle it tightly with the language. Heck, why did I even bring up Windows as a counterexample, when there are probably a lot of more-or-less ISO C conforming compilers for microcontroller platforms that could never support POSIX.
- vlovich123 5y ago
  HTTP != sockets. I’m not arguing for HTTP within the standard library but for low-level networking support. That one should be non controversial. As for HTTP within the standard library, I would probably tend to agree although I’d note that Python does have it in its standard module set and I don’t think there’s an acknowledgement that that’s somehow a mistake. Each language fills a different need so framing it as “people insisting in not learning lessons” isn’t helpful. Not to mention that the best way to learn is to experiment and double check if what was once true remains that way (experts know when and in what way to break rules).