Re: [boost] File Handle and FILE* wrappers?

Subject: Re: [boost] File Handle and FILE* wrappers?
From: Olaf van der Spek (ml_at_[hidden])
Date: 2014-12-05 06:29:31

On Sat, Nov 29, 2014 at 4:12 PM, Bjorn Reese <breese_at_[hidden]> wrote:
> 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.

Makes sense, though IMO the async part shouldn't negatively affect the
sync part.

> 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,

I kinda wanted to avoid the dependency on fs just for that, but I
guess it does make sense.

> std::io_base::openmode for the mode parameter,
> define a native_handle_type type instead of exposing FILE directly, and

Do you mean a real class (unowned handle) or just a typedef?

> use a native_handle() member function to return it instead of using the
> conversion operator (this pattern is used in Asio and Networking TS.)

-- 
Olaf