-
Notifications
You must be signed in to change notification settings - Fork 135
Description
Commit 784dc09 in PR #17 introduced stateless I/O functions, like read_r() and writre_r(), which return an ioresult type that wrap the success and specific error values derived from errno or GetLastError().
On an unrelated note, in Issue #72, @JakeSays suggested getting rid of exceptions in the few places they're used, and @ldgeng, suggested using std::error_code.
I was not even aware std::error_code existed, but it looks very appropriate for this library. It would be a good way to eliminate platform-specific differences of checking errors on Win32 that has been plaguing us already. And it would present a road forward for handling errors when TLS libraries are introduced in a future version of sockpp.
So, taken all together, I'm thinking of doing this...
- Convert the "last error" in the library to return an error code, like:
std::error_code socket::get_last_error();
- Make a generic
result<T>type whereTis the success variant anderror_codeis the error.
template <typename T>
class result {
/** The return value of an operation, if successful */
T val_;
/** The error returned from an operation, if failed */
error_code err_;
// ...
};
- An
ioresultwould be a specialization ofresult<int>:
using ioresul = result<int>;
- Remove exceptions and return a
result<T>in their place. The whole API will benoexcept. - Constructors that would have thrown now just set the last error, and thus would need to be checked (similar to iostreams, I guess).
- Phase out the need for maintaining the error state. In the next major release, move to all I/O operations being stateless, returning an
ioresult. The only explicit need for the state would be checking the object after construction.
The last point would allow a single socket to be thread-safe for two threads where one reads from the socket and the other writes to it. This is a common pattern in socket apps in C, but couldn't be done in sockpp since get_last_error() is not thread safe.