I've used this for some projects, with much success. In one case I used it as a data interchange format between a C++ app an some Python utilities. It worked very well for that and the generated API's were easy to work with, albiet a bit bulky.
In another case, more of an experiment, I used them to serialize game data and sent it using enet. This proved very flexible and easy to change/add things, and the packets were extremely compact.
Pros:
* Read/Write access to data from C++ or Python
* Generated API's were easy to work with
* Very compact representation
* Ascii-dump version very useful for debugging
* More error checking than something like json (i.e. it tells you if you leave out a required field)
Cons:
* Adds some build steps, can be more of a headache to maintain (compared to json or something)
* API can't parse ascii version, bad for config data or other stuff that might want to be human readable (vs. xml or json)
* Generally requires copying your data into the protobuf struct, and then packing, rather than going straight from your "native" format into a packed buffer.
* Adds a bit more complexity
* Not as lightweight as json
For what you're doing, I would recommend them.
They're great for "structure" style data, a little weird for array-style. For example, one of the things I was storing was a 4x4 matrix, and I resorted to making a struct with 16 members such as m_00, m_01, etc.. which worked fine and it stored it compactly but was a little weird. I don't think there's a way to have a float[16] or something like that. I could be wrong, maybe there's a better way to do this.
Generally, these days i use one of three formats. I am very happy to have outgrown xml.
protobuf -- for hierarchical, nested data, if it needs to be compact and accessed from different languages
JSON -- for quick and dirty stuff, when format needs to be flexible (or when i need to use javascript)
GTO -- for large sets of structured data. (www.opengto.org)
Comments
I've used this for some projects, with much success. In one case I used it as a data interchange format between a C++ app an some Python utilities. It worked very well for that and the generated API's were easy to work with, albiet a bit bulky.
In another case, more of an experiment, I used them to serialize game data and sent it using enet. This proved very flexible and easy to change/add things, and the packets were extremely compact.
Pros:
* Read/Write access to data from C++ or Python
* Generated API's were easy to work with
* Very compact representation
* Ascii-dump version very useful for debugging
* More error checking than something like json (i.e. it tells you if you leave out a required field)
Cons:
* Adds some build steps, can be more of a headache to maintain (compared to json or something)
* API can't parse ascii version, bad for config data or other stuff that might want to be human readable (vs. xml or json)
* Generally requires copying your data into the protobuf struct, and then packing, rather than going straight from your "native" format into a packed buffer.
* Adds a bit more complexity
* Not as lightweight as json
For what you're doing, I would recommend them.
They're great for "structure" style data, a little weird for array-style. For example, one of the things I was storing was a 4x4 matrix, and I resorted to making a struct with 16 members such as m_00, m_01, etc.. which worked fine and it stored it compactly but was a little weird. I don't think there's a way to have a float[16] or something like that. I could be wrong, maybe there's a better way to do this.
Generally, these days i use one of three formats. I am very happy to have outgrown xml.
protobuf -- for hierarchical, nested data, if it needs to be compact and accessed from different languages
JSON -- for quick and dirty stuff, when format needs to be flexible (or when i need to use javascript)
GTO -- for large sets of structured data. (www.opengto.org)