Closed kapstok closed 6 years ago
@j4cbo, thanks for the response. When using a system that needs to keep track of a lot of vars and has limited (RAM) storage to do so, having a more efficient way of storing data using a short instead of an int, could increase the amount of stored variables significantly. In my particular case I use different protocols that do support short and long types. To me it made more sense to handle the conversions in this library instead of handling the conversions in the implementation. Maybe it's a wrong assumption, but I assume the library should be concerned with outputting variables to the most memory-efficient type.
Catching up on a backlog. I'm with J4cbo here that the goals you describe feel out-of-scope for this library. Supporting fine-grained specifications of types of integers also seems incompatible with our choice to limit numeric types for broad compatibility, documented here: https://github.com/dropbox/json11/blob/master/json11.hpp#L16 That's not necessarily the right choice for every use case, but it's a core choice in this library from the beginning.
Are you actually worried about memory storage space in Json objects themselves, or elsewhere? If you are, then I think there already enough other sources of overhead (e.g. the extra indirections and memory allocations implied by the abstract JsonValue) that you should likely be storing your data in a different type. If not, then the storage type of objects which are later converted to Json seems orthogonal.
I don't quite understand the purpose of this. 'short' and 'long' aren't distinguishable in the serialized format, so this seems like it would just move the implicit conversions elsewhere - what's the use case here?