3 ms·

Your socket class would have no default constructor? And you would never want to close the socket before the object's lifetime ends? Really?

7jjjjjjj 1y ago
With destructive moves, you can end an object's lifetime whenever you want.
- spacechild1 1y ago
  How would I use such a socket class as a member variable? How do I reopen the socket?
  - sgsjchs 1y ago
    Reopen by constructing and assigning a new socket.
    - spacechild1 1y ago
      So I essentially have to wrap it in something like std::optional. Well, that's certainly one way to write a socket class, but I'd say it's not idiomatic C++. (I have never seen a socket class being implemented like that.)
      - sgsjchs 1y ago
        You don't need optional in this case, the assignment would just destroy the old socket and immediately move the new one in its place.
        spacechild1 1y ago
        Well, reopening a socket implies that I have manually closed the socket, which does require an optional with your implementation.
sgsjchs 1y ago
In this case, I would want the address family and protocol to be statically known, so it would have default constructor. But for example, a file might not have one, sure. As for closing before lifetime ends, why? I can just end lifetime. Wrap it in an optional if the type system can't figure it out like with a struct member.
- spacechild1 1y ago
  > so it would have default constructor. And what's the underlying value of such a default constructed socket? I assume it would be -1 resp. INVALID_SOCKET, in which case the destructor would have to deal with it. > Wrap it in an optional if the type system can't figure it out like with a struct member. So you essentially must wrap it in an optional if you want to use it as a member variable. I find this rather pointless as sockets already have a well-defined value for empty state (-1 resp. INVALID_SOCKET). By wrapping it in a optional you are just wasting up to 8 bytes. Sure, you can implement a socket class like that, but it's neither necessary nor idiomatic C++.
  - sgsjchs 1y ago
    > And what's the underlying value of such a default constructed socket? I assume it would be -1 resp. INVALID_SOCKET No, as explained, the default value would be the result of `::socket` call, i.e. a fresh OS-level socket. > So you essentially must wrap it in an optional if you want to use it as a member variable. No, you only must wrap it if you really want this closed state to exist. > Sure, you can implement a socket class like that, but it's neither necessary nor idiomatic C++. Obviously. Because the moves are not destructive. If they were, this design would be superior. And the wasted space for optional is solvable, just like for non-nullable pointers.
    - spacechild1 1y ago
      > If they were, this design would be superior. I see how destructive moves would slightly simplify the implementation, but what difference would it make apart from that? (Don't get me wrong, I totally think that destructive moves are a good idea in general, I just don't see the qualitative difference in this particular case.) > And the wasted space for optional is solvable, just like for non-nullable pointers. In the case of non-nullable pointers the library author knows that they can use NULL as a sentinel value and write a corresponding specialization. But what could you possibly do with an arbitrary user-defined class?

7jjjjjjj 1y ago

With destructive moves, you can end an object's lifetime whenever you want.

spacechild1 1y ago
How would I use such a socket class as a member variable? How do I reopen the socket?
- sgsjchs 1y ago
  Reopen by constructing and assigning a new socket.
  - spacechild1 1y ago
    So I essentially have to wrap it in something like std::optional. Well, that's certainly one way to write a socket class, but I'd say it's not idiomatic C++. (I have never seen a socket class being implemented like that.)
    - sgsjchs 1y ago
      You don't need optional in this case, the assignment would just destroy the old socket and immediately move the new one in its place.
      - spacechild1 1y ago
        Well, reopening a socket implies that I have manually closed the socket, which does require an optional with your implementation.

sgsjchs 1y ago

In this case, I would want the address family and protocol to be statically known, so it would have default constructor. But for example, a file might not have one, sure. As for closing before lifetime ends, why? I can just end lifetime. Wrap it in an optional if the type system can't figure it out like with a struct member.

spacechild1 1y ago
> so it would have default constructor. And what's the underlying value of such a default constructed socket? I assume it would be -1 resp. INVALID_SOCKET, in which case the destructor would have to deal with it. > Wrap it in an optional if the type system can't figure it out like with a struct member. So you essentially must wrap it in an optional if you want to use it as a member variable. I find this rather pointless as sockets already have a well-defined value for empty state (-1 resp. INVALID_SOCKET). By wrapping it in a optional you are just wasting up to 8 bytes. Sure, you can implement a socket class like that, but it's neither necessary nor idiomatic C++.
- sgsjchs 1y ago
  > And what's the underlying value of such a default constructed socket? I assume it would be -1 resp. INVALID_SOCKET No, as explained, the default value would be the result of `::socket` call, i.e. a fresh OS-level socket. > So you essentially must wrap it in an optional if you want to use it as a member variable. No, you only must wrap it if you really want this closed state to exist. > Sure, you can implement a socket class like that, but it's neither necessary nor idiomatic C++. Obviously. Because the moves are not destructive. If they were, this design would be superior. And the wasted space for optional is solvable, just like for non-nullable pointers.
  - spacechild1 1y ago
    > If they were, this design would be superior. I see how destructive moves would slightly simplify the implementation, but what difference would it make apart from that? (Don't get me wrong, I totally think that destructive moves are a good idea in general, I just don't see the qualitative difference in this particular case.) > And the wasted space for optional is solvable, just like for non-nullable pointers. In the case of non-nullable pointers the library author knows that they can use NULL as a sentinel value and write a corresponding specialization. But what could you possibly do with an arbitrary user-defined class?