Please update us on how that turns out in the end. The only time I've needed to do something similar was way back when I had some shell script (a file descriptor number) and wanted that to interoperate with a C++ program. So long ago in fact I no longer recall the reason. I have a vague recollection of finding some method or item (?called "fd"?) when single stepping through the C++ STL code. I may even have edited the C++ header to expose it! Obviously a transient hack. I think even that became non-viable when g++ was upgraded.
It's nice to hear of "native_handle" - though it would have been nice if they''d not introduced an undefined behaviour scenario. The fact it has taken this long to do even that lends me to think it's been a long fight behind the scenes. One would have thought right from the outset there would have been a C getter method "stream.FileHandle()" and an OS getter method "stream.OsHandle()". I'd have had the latter return a (void*) to an OS dependant struct and washed my hands of it (C++ wise).
I've never liked C++ file handling. Overly complex. I suspect a major argument against exposing the underlying handle is the amount of bug reports which would result through folk using it incorrectly. My (not insubstantial) personal "sdlib" uses std::ifstream/ofstream in only two places - the sdData.Load/Save methods of what is effectively a windoze ".ini" file class. I cheat by loading the whole thing into memory and keeping it there. Very rarely do I have to write an sdData but if I do, I write the entire thing. They're not big and memory is cheap. If threads are involved, a mutex would suffice. Doesn't apply to your (or my ancient problem) of two programs sharing a file though.
At a higher level, the design should be considered along the lines of ownership. Have program A "own" the file and should program B want to make changes then have it send a message to program A. Think of it like two programs accessing the same database table and the notion of a database "transaction" (a high level atomic operation). There's all manner of ways to achieve this. There are daemons which will re-read their config file if sent (say) SIGHUP for instance. Even older method, is a folder with a lock file (a kludgy mutex for programs). Every mechanism we can think of has been used by someone somewhere.
It's nice to hear of "native_handle" - though it would have been nice if they''d not introduced an undefined behaviour scenario. The fact it has taken this long to do even that lends me to think it's been a long fight behind the scenes. One would have thought right from the outset there would have been a C getter method "stream.FileHandle()" and an OS getter method "stream.OsHandle()". I'd have had the latter return a (void*) to an OS dependant struct and washed my hands of it (C++ wise).
I've never liked C++ file handling. Overly complex. I suspect a major argument against exposing the underlying handle is the amount of bug reports which would result through folk using it incorrectly. My (not insubstantial) personal "sdlib" uses std::ifstream/ofstream in only two places - the sdData.Load/Save methods of what is effectively a windoze ".ini" file class. I cheat by loading the whole thing into memory and keeping it there. Very rarely do I have to write an sdData but if I do, I write the entire thing. They're not big and memory is cheap. If threads are involved, a mutex would suffice. Doesn't apply to your (or my ancient problem) of two programs sharing a file though.
At a higher level, the design should be considered along the lines of ownership. Have program A "own" the file and should program B want to make changes then have it send a message to program A. Think of it like two programs accessing the same database table and the notion of a database "transaction" (a high level atomic operation). There's all manner of ways to achieve this. There are daemons which will re-read their config file if sent (say) SIGHUP for instance. Even older method, is a folder with a lock file (a kludgy mutex for programs). Every mechanism we can think of has been used by someone somewhere.
Statistics: Posted by swampdog — Wed Jan 01, 2025 12:17 am