|
|
|
|
|
|
by to3m
3026 days ago
|
|
|
Sure, you can do this, but don't. Approximately the last thing you want is a copy constructor that can fail. If you have to do an OS call to duplicate the underlying resource, assume the class isn't copyable in this way. It's almost certainly possible to make it moveable, and this will get you the bulk of the benefit: you can return it from functions, and you have a std::vector of it. (Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR. I don't consider looping on EINTR ever safe, but that's up to you. EIO, on the other hand - what are you going to do about that? And if you don't call close from the destructor, what the hell use is this class anyway?? Overall, I don't think value objects make very good wrappers for a POSIX-style file descriptor.) |
|
|
It was instructive. That said, there's nothing wrong in general with a class that owns a file descriptor, and making this class copy constructible as a legitimate design decision.
> Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR.
IO errors from close(2) should be ignored. If you care about durability, call fsync before you close. Even if close "fails" with an IO error, the underlying FD is still closed. EINTR does not actually happen.
See extensive discussion http://austingroupbugs.net/view.php?id=529