I am continuing work on QCSSL and focusing on eliminating use of MFC. In one case, MFC is used to load the contents of a file into memory and this brings up the whole question of how we are going to handle file i/o in Hermes. Has there been any discussion of this before? I have not found any with a quick search.
I see three ways to approach this. One is to reduce all file i/o to POSIX file-access functions. Another is to implement three variations of all file i/o code, one for Windows, one for Linux and one for Mac. And the third is to use some open-source multi-platform file-access library.
I find none of these three appealing.
POSIX is ugly, based on 40+ year-old UNIX primitives, has no support (as far as I can determine) for wide-character strings (although they can be managed by extensions), has sniffy support by Microsoft, has a reputation for poor performance, and suffers from having rants all over the Internet saying "POSIX must die!".
Implementing native file i/o for each system would offer the best perfomance and the clearest semantics but would probably require the most work.
Using a multi-platform library is what I would do if I were working on my own code but I do not know of an open-source one that would fit. I have not searched far but the only one I have found (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1031r0.pdf) seems way too overblown and complex for our needs (which are really rather simple). Does anyone know of another that might be fitting?
Of course another option would be to just do everything for Windows at the moment and deal with other platforms later. (Possibly by emulating Windows functions in native code.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is one of the places I think the Boost API might be helpful. At first
glance I see it uses std:string. If this is a question of casting every
string to std::string or building boost with w_chart support I'm not sure
right away. But I know that the Boost API will work consistently across
platforms.
And the general file/path io functions of this API.
If we're going with WxWidgets it may also have some file io support, but
again, I'm not quite sure if it'll do what we want as it's first and
foremost a GUI API and, I haven't looked that close yet, but see for
instance:
I am continuing work on QCSSL and focusing on eliminating use of MFC. In
one case, MFC is used to load the contents of a file into memory and this
brings up the whole question of how we are going to handle file i/o in
Hermes. Has there been any discussion of this before? I have not found any
with a quick search.
I see three ways to approach this. One is to reduce all file i/o to POSIX
file-access functions. Another is to implement three variations of all file
i/o code, one for Windows, one for Linux and one for Mac. And the third is
to use some open-source multi-platform file-access library.
I find none of these three appealing.
POSIX is ugly, based on 40+ year-old UNIX primitives, has no support (as
far as I can determine) for wide-character strings (although they can be
managed by extensions), has sniffy support by Microsoft, has a reputation
for poor performance, and suffers from having rants all over the Internet
saying "POSIX must die!".
Implementing native file i/o for each system would offer the best
perfomance and the clearest semantics but would probably require the most
work.
Using a multi-platform library is what I would do if I were working on my
own code but I do not know of an open-source one that would fit. I have not
searched far but the only one I have found ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1031r0.pdf)
seems way too overblown and complex for our needs (which are really rather
simple). Does anyone know of another that might be fitting?
Of course another option would be to just do everything for Windows at the
moment and deal with other platforms later. (Possibly by emulating Windows
functions in native code.)
There are many purposes for which I would happily use Boost. But this is not one of them. Have you looked at Boost.Filesystem? I find many ways in which it is very much not what we want. Or at least what I think we want. For one, it is based on POSIX.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are many purposes for which I would happily use Boost. But this is
not one of them. Have you looked at Boost.Filesystem? I find many ways in
which it is very much not what we want. Or at least what I think we want.
For one, it is based on POSIX.
There are many purposes for which I would happily use Boost. But this is
not one of them. Have you looked at Boost.Filesystem? I find many ways in
which it is very much not what we want. Or at least what I think we want.
For one, it is based on POSIX.
I am continuing work on QCSSL and focusing on eliminating use of MFC. In one case, MFC is used to load the contents of a file into memory and this brings up the whole question of how we are going to handle file i/o in Hermes. Has there been any discussion of this before? I have not found any with a quick search.
I see three ways to approach this. One is to reduce all file i/o to POSIX file-access functions. Another is to implement three variations of all file i/o code, one for Windows, one for Linux and one for Mac. And the third is to use some open-source multi-platform file-access library.
I find none of these three appealing.
POSIX is ugly, based on 40+ year-old UNIX primitives, has no support (as far as I can determine) for wide-character strings (although they can be managed by extensions), has sniffy support by Microsoft, has a reputation for poor performance, and suffers from having rants all over the Internet saying "POSIX must die!".
Implementing native file i/o for each system would offer the best perfomance and the clearest semantics but would probably require the most work.
Using a multi-platform library is what I would do if I were working on my own code but I do not know of an open-source one that would fit. I have not searched far but the only one I have found (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1031r0.pdf) seems way too overblown and complex for our needs (which are really rather simple). Does anyone know of another that might be fitting?
Of course another option would be to just do everything for Windows at the moment and deal with other platforms later. (Possibly by emulating Windows functions in native code.)
This is one of the places I think the Boost API might be helpful. At first
glance I see it uses std:string. If this is a question of casting every
string to std::string or building boost with w_chart support I'm not sure
right away. But I know that the Boost API will work consistently across
platforms.
See, for instance:
https://www.boost.org/doc/libs/1_32_0/libs/filesystem/doc/portability_guide.htm
And the general file/path io functions of this API.
If we're going with WxWidgets it may also have some file io support, but
again, I'm not quite sure if it'll do what we want as it's first and
foremost a GUI API and, I haven't looked that close yet, but see for
instance:
--- https://docs.wxwidgets.org/3.0/overview_file.html
Since it uses wxString, which, i think, will end up meaning std::wstring,
that is: wchar_t,that should work too.
Regards.
Soren
On Mon, Sep 24, 2018 at 5:36 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
There are many purposes for which I would happily use Boost. But this is not one of them. Have you looked at Boost.Filesystem? I find many ways in which it is very much not what we want. Or at least what I think we want. For one, it is based on POSIX.
(AFK)
What do you mean?
As I recall there's even a C# version!
I'm pretty sure it's cross-platform. I'm afraid I've only used it on POSIX
though...
Nah. That's not right. I have it installed on Windows now.
Regards
On Wednesday, September 26, 2018, Pete Maclean petemaclean@users. sourceforge.net wrote:
--
Søren Bro Thygesen
(AFK)
I'm not sure I understand your unwillingness to embrace this API. But if
it's a gut feeling of yours I'll happily go with it.
It also reinforces the KISS principle (and make the final executable a
little smaller), if nothing else.
Regards
On Wednesday, September 26, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
It is much more than a gut feeling. If you have any reason to think we should be using it, please tell.
(AFK)
Well, the only thing I have right now is that it saved me time in the past.
:)
On Wednesday, September 26, 2018, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
Søren Bro Thygesen
I had a project which used it, but it seems to have disappeared from
version control. What the heck?!
Regards
On Thursday, September 27, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
A program to keep track of my Original Release pirated music. When it
passed several TBs it became unmanageable.
It now resides on a broken 3 TB external disk. Which says "whirr click" at
regular intervals.
Regards
On Thursday, September 27, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
(AFK)
I have it on my hdd though. I'll look at it. See what I used it for.
Regards
On Thursday, September 27, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen