search

JeffGarland / liaw2019-process

Repository for initial drafting of boost.process standards paper
MIT License
5 stars 4 forks source link

fstream extension #21

Closed JeffGarland closed 5 years ago

JeffGarland commented 5 years ago

If this isn't fundamental I'd also like to remove it and possibly bring it forward as a separate small proposal. While I understand that it might be needed by the implementation, they are free to do that anyway they like. My concern is that there will be the 'abi breaking' bikeshed on this -- which currently can kill a proposal quickly.

** Extension of ~fstream~

The standard file streams (~fstream~/~ofstream~/~ifstream~) shall have a member function that return the native handle of the opened file, so that process can use those for forwarding.

I've moved it to the 'proposal_cuts.org' -- if we must have it I can restore.

eliaskosunen commented 5 years ago

Moving it to a separate paper sounds like a good idea. The change is rather orthogonal to process handling.

I think I could be able to write one before tomorrow morning.

JeffGarland commented 5 years ago

Agree. Honestly I'm not sure how much time should be spent on it. Seems like someone is going to come with iostreams3 based on concepts, at which point the current io system won't get much love. And as mentioned, I'm pretty sure that will be an ABI issue -- which means you'll get the 'nope, can't do -- next paper' treatment.

eliaskosunen commented 5 years ago

I wrote one anyway (going to be P1759), but instead of a member function it'd be a free function to avoid messing with vtables. I'll see how it fares.