string_type in binary_reader

[kaidokert]

Feature Request

• Describe the feature in as much detail as possible.
  Currently binary_reader requires using std::string, which is cumbersome when trying to work with custom non-standard string classes. In my specific usecase, embedded system and cbor parsing.

• Include sample usage where appropriate.
  The rest of the header currently compiles with a custom string type stand-in with a very minimal standard interface part:

struct awfully_poor_str {
    static const size_t npos = static_cast<size_t>(-1);
    using value_type = char;
    void push_back(char);
    awfully_poor_str();
    awfully_poor_str(const char *);
};

Changing binary_reader to

using string_t = typename BasicJsonType::string_t;

makes it compile as well. Or is there a definite reason why it should use std::string there ?

BTW, on a cortex-m0 compile with custom vector and string types, exceptions/rtti off, and std::streams stubbed out i get about 3kB for the library code size right now. Intel's C tinycbor is about 2.5kB, and a smaller custom c++ cbor-only limited-features parser is <1kB

binary_stringtype.diff.txt

[nlohmann]

I think this is the first time I heard of a proper use of a string_t other than std::string. :-)

There is no specific reason for std::string there. The diff looks simple enough to be used. PRs welcome!

I can image that a CBOR-only parser can be smaller, and I would be happy to improve the library code in this regard. But since CBOR is only one aspect of the library, I'm not sure how much smaller it can get. Then again - any feedback is more than welcome!

[kaidokert]

There's room to get smaller with a custom std::map implementation .. which i didn't know where to borrow right off the bat. Most of the remaining code size beyond parsing itself is std::map's red-black tree implementation, plus some bits pulled in by shared_ptr, required by input_adapter_t and output_adapter_t that i think can probably be avoided too, with some thought.

I'll make a pull request with the diff. It would probably good to add some basic unit-tests compiling with minimal std::string and std::vector replacements, to ensure future changes don't break the interface contract for those

EDIT: i went looking and could borrrow a flat map from boost maybe as well, it'll probably be smaller and the speed doens't much matter in typical tiny payloads in my use cases.

[nlohmann]

Fixed by merging #950.