vimpunk

Thanks for the update. If assets can be opened as a file descriptor, could mio not be used as is, passing the descriptor to the [constructor](https://github.com/mandreyel/mio/blob/9bc01337640f9bcba6b7d80164594cc09306bafb/include/mio/mmap.hpp#L122)/[mapping](https://github.com/mandreyel/mio/blob/9bc01337640f9bcba6b7d80164594cc09306bafb/include/mio/mmap.hpp#L291-L292) function?

@rwebb Thanks for your input. This is something I've been pondering as well and in retrospect it seems like it was a bad idea to forgo syncing in the destructor....

@rwebb Ok, you've convinced me. Would you be willing to send a PR? Also, what is your opinion on the most sensible default behavior?

Thank you for your input, I'll land the changes in a bit.

@rwebb I've implemented the changes in [this](https://github.com/mandreyel/mio/tree/destructor-sync-policy) branch, but I chose to implement the destructor policy as an additional optional non-type template parameter. I wanted to avoid increasing the object's...

Hello @unclepaul84, I'm thrilled that you're giving mio a go! Unfortunately serialization is not supported, mio serves as a thin wrapper around the platform memory mapping facilities, which also don't...

Hi @KirbX, thank you for reporting this and apologies for the belated reply (github notifications don't always seem to work and I rarely check my github email). I have run...

@KirbX Hi! Thank you for including the file. It looks correct, but just in case, I pushed a patch that only puts the printable ASCII range in `test-file`, which should...

@david-bouyssie Thank you so much! Honestly, I hadn't planned such a thing, but if there is demand for it, I wouldn't be against it. However, I don't have a lot...

Hmm, this is strange. Admittedly I haven't tested on older toolchains. Thanks for reporting, I'll look into it in a bit.