4 ms·

> (...) any reasonable change (e.g. networking, fiber, reflection etc) (...) Except those aren't small or simple or trivial or consequence-free. Also, we're t

by rewmie 3y ago

> (...) any reasonable change (e.g. networking, fiber, reflection etc) (...) Except those aren't small or simple or trivial or consequence-free. Also, we're talking about standardizing current practices. You can do networking in C++ in a myriad of ways already, and none of which is standard.

tialaramex 3y ago
For vocabulary reasons it makes sense for the standard library to express basic types. That's why Rust's core::net::Ipv6Addr - sure, this $5 WiFi-enabled thermal probe and a $5000 100Gb/s fibre switch probably have no common elements when it comes to how they actually do networking, but it's worth acknowledging that 128-bit IPv6 addresses are actually the same thing in both codebases. There should not need to be some stupid adaptor layer, or the need to translate via strings. Now, Rust's standard library also provides BSD sockets in std (that cheap WiFi probe presumably lacks an OS and wouldn't have sockets). That's much less obviously necessary, although it's hardly a big problem and I think if C++ had this since 1998 there would be less squabbling. But the fundamental types are vocabulary and it's silly that C++ doesn't have them in its stdlib.
- lionkor 3y ago
  Are you not aware of the networking TS and the asio / boost::asio library its based on? Those have asio::ip::(tcp|udp)::address, both v4 and v6 iirc. Not sure if I'm missing something?
  - tialaramex 3y ago
    > asio::ip::(tcp|udp)::address You mean asio::ip::address presumably. That's not shared vocabulary. Suppose I'm writing a small program maybe a couple of dozen lines of code, and I need some IPv4 addresses. Should I bring in all of ASIO to have this type? It makes plenty of sense for ASIO to live outside of the C++ standard library. But the standard library would benefit from these basic types as vocabulary.
    - planede 3y ago
      It would be quite weird to have these vocabulary types in the standard without any way to use them for networking within the standard library. Like having std::filesystem::path without having actual filesystem operations working on them.
    - lionkor 3y ago
      When do you need ip addresses but no sockets?
      - tialaramex 3y ago
        Sockets are an OS feature (initially on BSD) to make it simple to program with IP on Unix-like systems. They're not crucial to the Network, they're happenstance. Indeed in the early 1990s you'd have found pockets of people who weren't convinced sockets were even the Right Thing™ they wanted some other API to the same network. Same IP addresses, same services, same protocols, different API. So there's no reason the very cheap device would care about sockets. But it does talk to the network, and for that it needs to know about addresses.
        lionkor 3y ago
        a socket is just a name for that abstraction, call it what you will.
        tialaramex 3y ago
        It's a very specific API, you don't need to use that API. QUIC implementations don't tend to have an equivalent for example, there's some of Connection data structure, but no need to give out integer handles if the implementation just lives in a library. It can seem weird today when we're used to sockets everywhere, but that's an arbitrary choice and there's no reason a tiny embedded system would mimic it.
  - planede 3y ago
    AFAIK asio based networking TS is dead.
- kps 3y ago
  This one? https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html That's actually a very good example. Because sooner or later, you'll find yourself ten libraries deep with a FE80::1234 that you can't use because nine of the ten thought Ipv6Addr was enough.
  - tialaramex 3y ago
    Kinda, yes. std::net::Ipv6Addr re-exports core::net::Ipv6Addr - it lives in core because you don't need an operating system to have network addresses. If you wanted the [u8; 16] that's octets() if you wanted [u16; 8] that's segments() and those are both inline constant functions.
tw1984 3y ago
> and none of which is standard. you don't see the problem here? golang/rust doesn't spend 30 years to standardize networking/fs.
- rewmie 3y ago
  > golang/rust doesn't spend 30 years to standardize networking/fs. Golang and rust standardized nothing. Golang and rust just provided implementations for features. Likewise, there's already a myriad of networking/file system libraries for C++. This is not a problem. The problem is to get to an abstraction that can work across all conceivable platforms. You can hack together something, but throwaway code should not feature in an international standard. See for example how Python's fs support is riddled with gotchas and outright bugs on platforms such as Windows. In the meantime C++ already has things like Poco, boost, Qt, etc, not to mention platform-specific SDKs. Not a problem. Never was.

by rewmie 3y ago

tialaramex 3y ago

For vocabulary reasons it makes sense for the standard library to express basic types. That's why Rust's core::net::Ipv6Addr - sure, this $5 WiFi-enabled thermal probe and a $5000 100Gb/s fibre switch probably have no common elements when it comes to how they actually do networking, but it's worth acknowledging that 128-bit IPv6 addresses are actually the same thing in both codebases. There should not need to be some stupid adaptor layer, or the need to translate via strings. Now, Rust's standard library also provides BSD sockets in std (that cheap WiFi probe presumably lacks an OS and wouldn't have sockets). That's much less obviously necessary, although it's hardly a big problem and I think if C++ had this since 1998 there would be less squabbling. But the fundamental types are vocabulary and it's silly that C++ doesn't have them in its stdlib.

lionkor 3y ago
Are you not aware of the networking TS and the asio / boost::asio library its based on? Those have asio::ip::(tcp|udp)::address, both v4 and v6 iirc. Not sure if I'm missing something?
- tialaramex 3y ago
  > asio::ip::(tcp|udp)::address You mean asio::ip::address presumably. That's not shared vocabulary. Suppose I'm writing a small program maybe a couple of dozen lines of code, and I need some IPv4 addresses. Should I bring in all of ASIO to have this type? It makes plenty of sense for ASIO to live outside of the C++ standard library. But the standard library would benefit from these basic types as vocabulary.
  - planede 3y ago
    It would be quite weird to have these vocabulary types in the standard without any way to use them for networking within the standard library. Like having std::filesystem::path without having actual filesystem operations working on them.
  - lionkor 3y ago
    When do you need ip addresses but no sockets?
    - tialaramex 3y ago
      Sockets are an OS feature (initially on BSD) to make it simple to program with IP on Unix-like systems. They're not crucial to the Network, they're happenstance. Indeed in the early 1990s you'd have found pockets of people who weren't convinced sockets were even the Right Thing™ they wanted some other API to the same network. Same IP addresses, same services, same protocols, different API. So there's no reason the very cheap device would care about sockets. But it does talk to the network, and for that it needs to know about addresses.
      - lionkor 3y ago
        a socket is just a name for that abstraction, call it what you will.
        tialaramex 3y ago
        It's a very specific API, you don't need to use that API. QUIC implementations don't tend to have an equivalent for example, there's some of Connection data structure, but no need to give out integer handles if the implementation just lives in a library. It can seem weird today when we're used to sockets everywhere, but that's an arbitrary choice and there's no reason a tiny embedded system would mimic it.
- planede 3y ago
  AFAIK asio based networking TS is dead.
kps 3y ago
This one? https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html That's actually a very good example. Because sooner or later, you'll find yourself ten libraries deep with a FE80::1234 that you can't use because nine of the ten thought Ipv6Addr was enough.
- tialaramex 3y ago
  Kinda, yes. std::net::Ipv6Addr re-exports core::net::Ipv6Addr - it lives in core because you don't need an operating system to have network addresses. If you wanted the [u8; 16] that's octets() if you wanted [u16; 8] that's segments() and those are both inline constant functions.

tw1984 3y ago

> and none of which is standard. you don't see the problem here? golang/rust doesn't spend 30 years to standardize networking/fs.

rewmie 3y ago
> golang/rust doesn't spend 30 years to standardize networking/fs. Golang and rust standardized nothing. Golang and rust just provided implementations for features. Likewise, there's already a myriad of networking/file system libraries for C++. This is not a problem. The problem is to get to an abstraction that can work across all conceivable platforms. You can hack together something, but throwaway code should not feature in an international standard. See for example how Python's fs support is riddled with gotchas and outright bugs on platforms such as Windows. In the meantime C++ already has things like Poco, boost, Qt, etc, not to mention platform-specific SDKs. Not a problem. Never was.