mio VS llfio

As simple and clean example you can see https://github.com/mandreyel/mio readme.md

I loaded a 7Gb file into a memory map using the mio header file. The mmap variable is a char* array. I used a short file since this is my first time attempting a memory mapped file. This is the text2.txt file

I am using this mio header file and attempting to read in a 7GB file. This is taking a long time to execute so I stop the execution. I am reading in a small file just to test this out.

A great fellow redditor showed me this memory mapping header file to read in large files. This is how I am using it with a syntax error.

I would memory map it. Use this lib: https://github.com/mandreyel/mio

The reference library can be found at https://ned14.github.io/llfio/

Thanks for the suggestions, which I have transposed into https://github.com/ned14/llfio/issues/106

There was an effort to get an afio library accepted into boost in the past. I believe the most current work on that library is happening here nowadays : https://github.com/ned14/llfio I'm not sure if it is considered production-ready or not. But I couldn't see any mention of it in the replies so I figured I would fix that!

It has an implementation: LLFIO

I'm a fan of Interprocess, used it for over a decade. But for mmapping I've switched to LLFIO and recommend it highly. (Plugging so Niall doesn't have to.)

Since that post, I have the reference implementation library very nearly passing its test suite https://github.com/ned14/llfio/pull/89. Once it's done I'll start very slowly writing its proposal paper for WG21 SG4. Should land before this summer.

FYI it doesn't solve quite what you're solving, but I've been careful to ensure https://github.com/ned14/llfio works well on Freestanding and < 64 Kb microcontrollers and I know Victor has been careful to ensure a good subset of std::format could work well on embedded. In other words, the i/o story for embedded C++ may improve greatly in the next few years.

If you want stronger guarantees than iostreams can give you, either use the OS-specific calls or a wrapper of said calls (e.g. https://github.com/ned14/llfio, disclaimer I'm the owner of that). Note that even in LLFIO, there is no concept of "seek to the end" because that's racy so we don't implement that. All you get is atomic append, otherwise you're on your own to coordinate what "end of file" means.