On 11/29/2014 03:13 PM, Olaf van der Spek wrote:
I don't understand this kind of reasoning. It's not an exclusive or deal is it?
While it is not mutually exclusive, it is easier to build a sync API on top of an async API than the other way around -- see the Half-Sync/ Half-Async design pattern in POSA2. You could design the sync API first, but it should not enforce an awkward design for the async API, and how are you going to ensure that without a reasonable idea about the latter? For example, the async API would need some kind of execution context (same as or similar to asio::io_service), and that should be reflected in the sync API. Regarding your wrapper class, I suggest that you make better use of C++ types. For instance, use filesystem::path (whether std::experimental or boost) for file names, std::io_base::openmode for the mode parameter, define a native_handle_type type instead of exposing FILE directly, and use a native_handle() member function to return it instead of using the conversion operator (this pattern is used in Asio and Networking TS.)