Ops! You’re perfectly right! Too low on coffee when I wrote that.
Thanks!
I skipped over this bit before, but it seems the main difference is whether they support FileInfo and Directory, I’m not sure about other implications (e.g. how much memory each consumes).
All versions of File seem to use the same API, so File-based code should work regardless of any other considerations.
Aside from the mistake @filmote pointed out, here’s a few other tips:
Usually reading functions automatically advance the stream position, you don’t need to seek every time you read something, you’re just burning CPU time doing that.
file.read<char>() will read a single char, so you could read characters one by one into a buffer until you find '\n' or can no longer read any more characters.
A more efficient way would be to read a fixed number of characters into a buffer and work with that buffer until you need to read more characters, but that will get quite complicated.
(Depending on what format you’re actually working with, reading an entire line might not be wise.)
You don’t need to use a char array to store the data you read. Ordinary variables will work, e.g.
std::uint32_t integer;
file.read(&integer, sizeof(integer));
Also note that there’s a useful template for reading specific types:
std::uint32_t integer = file.read<std::uint32_t>();
You can also do:
std::uint32_t integer;
file >> integer;
As well as things like:
file << 1 << "Hello" << 'x';
Though a file.write('A') (i.e. a counterpart to file.read<char>()) seems to be lacking.
Note that the file closes itself when it goes out of scope, so if you only need it around for a single function then you don’t necessarily need an explicit close().
If you need any help, feel free to ask.
Parsing and file formats are two things I’m quite well versed in.
I’ve never really used the File API, but one file API is usually much like another so it doesn’t take long to figure out.
1 Like
I forgot to mention, it’s possible to read entire structs/classes as well, but there are some rules you have to follow. Specifically the types should follow the standard layout rules, should not have members that are pointers (because addresses change between invocations/recompiles), and should probably be a trivial type too.
If in doubt, just stick to bare structs with no access markers (private, public et cetera) and only simple functions.
(If you care about portability, it gets more complicated because of things like endianness and padding.)
I prefer to go in plain asci text, to allow editing data with external tools too.
Json could be a option with this https://github.com/rafagafe/tiny-json and this https://github.com/rafagafe/json-maker
But probably I’ll keep a simpler approach.
Thanks for your suggestions.
One approach you could do to that is make a “compiler” tool that runs on the PC (can just be a simple C++ CLI program) that does all the parsing and outputs a binary format that can be read straight into a class/struct. That’s what I’ve done for PtaD and it works rather nicely as I can easily edit the data files even with just a plain text editor but not have to slow the game down with parsing and interpreting all that text.
1 Like
To add to what @tuxinator2009 says, the main reason to prefer binary is that it’ll save both CPU time and battery life. Text-based formats are fine on desktop, but inefficient for an embedded system.
Besides which, you’re going to have to work out how the JSON (or whichever text format you choose) would correspond to binary data anyway, so writing a compiler that pre-converts it wouldn’t be too dissimilar to what you’re going to end up writing for the Pokitto (except you won’t have to worry about memory usage because it’ll be on desktop).
Any chance you’re going to implement it in the near future?
Asking for a friend 