Question

I am starting work on a new piece of software that will end up needing some robust and expandable file IO. There are a lot of formats out there. XML, JSON, INI, etc. However, there are always plusses and minuses so I thought I would ask for some community input.

Here are some rough requirements:

1. The format is a “standard”…I don’t want to reinvent the wheel if I don’t have to. It doesn’t have to be a formal IEEE standard, but something you could Google and get some information on as a new user, may have some support tools (editors) beyond vi. (Though the software users will generally be computer savvy and happy to use vi.)
2. Easily integrates with C++. I don’t want to have to pull along a 100mb library and three different compilers to get it up and running.
3. Supports tabular input (2d, n-dimensional)
4. Supports POD types
5. Can expand as more inputs are required, binds well to variables, etc.
6. Parsing speed is not terribly important
7. Ideally, as easy to write (reflect) as it is to read
8. Works well on Windows and Linux
9. Supports compositing (one file referencing another file to read, and so on.)
10. Human Readable

In a perfect world, I would use a header-only library or some clean STL implementation, but I’m fine with leveraging Boost or some small external library if it works well.

So, what are your thoughts on various formats? Drawbacks? Advantages?

Edit

Options to consider? Anything else to add?

• XML
• YAML
• SQLite
• Google Protocol Buffers
• Boost Serialization
• INI
• JSON

Answer 1

For my purposes, I think the way to go is XML.

1. The format is a standard, but allows for modification and flexibility for the schema to change as the program requirements evolve.
2. There are several library options. Some are larger (Xerces-C) some are smaller (ezxml), but there are many options, so we won’t be locked in to a single provider or very specific solution.
3. It can supports tabular input (2d, n-dimensional). This requires more parsing work on “our” end, and is likely the weakest point for XML.
4. Supports POD types: Absolutely.
5. Can expand as more inputs are required, binds well to variables, etc. through schema modifications and parser modifications.
6. Parsing speed is not terribly important, so processing a text file or files is not an issue.
7. XML can be programmatically written just as easily as read.
8. Works well on Windows and Linux or any other OS that supports C and text files.
9. Supports compositing (one file referencing another file to read, and so on.)
10. Human Readable with many text editors (Sublime, vi, etc.) supporting syntax highlighting out of the box. Many web browsers display the data well.

Thanks for all the great feedback! I think if we wanted a purely binary solution, Protocol Buffers or boost::serialization is likely the way that we would go.