Skip to content

CBOR/MessagePack from uint8_t * and size #478

Closed

Description

@pboettch

How would one use from_cbor/from_messagepack when data is stored in a uint8_t-buffer received via a low-level C library?

Could something be done in this library to support this without doing copy of the data into a vector?

Activity

  1. theodelrieu commented on Feb 28, 2017

    @theodelrieu
    Contributor

    I think those methods should behave like parse, to be more generic indeed

  2. pboettch commented on Feb 28, 2017

    @pboettch
    ContributorAuthor

    At a first look I thought that simply replacing the vector as argument and giving a uint8_t *and a size_t could work with the existing functions. On a second glance, I think this needs to be tried ;-) .

  3. nlohmann commented on May 8, 2017

    @nlohmann
    Owner

    I have a question regarding this issue.

    For the default JSON parser, we currently have a lot of overloads:

    • T (&array)[N]
    • const CharT (CharT is a pointer to a 1-byte integral type)
    • std::istream& and std::istream&&
    • IteratorType first, IteratorType last
    • const ContiguousContainer& (container with contiguous storage of 1-byte values)

    Internally, this is realized with an input adapter class, see https://github.com/nlohmann/json/blob/develop/src/json.hpp#L8708.

    When I now add these overloads to the CBOR and MessagePack parsers, this would mean 8 additional functions which are more or less the same, because each chooses one of the input adapters, which is then used to configure a binary reader (https://github.com/nlohmann/json/blob/develop/src/json.hpp#L8954) which takes care of the acutal parsing.

    Before I start copying/pasting, I was wondering if there was a more elegant solution. A first idea would be to implement some kind of

    template<class ... Types>
    static basic_json from_cbor(Types ... args)

    which then forwards args to the constructors of the input_adapter class and basically allowing to read CBOR from anything that can create an input adapter.

    This would have the advantage of only two functions (one for CBOR and one for MessagePack), but would have the disadvantage of being a bit obscure for the users of the library, because they cannot immediately recognize which arguments can be used. Of course, this could be tackled by extensive documentation, but still.

    Another disadvantage of this approach is the fact that it cannot be used to limit the number of parse overloads, because these all have a const parser_callback_t cb = nullptr as last parameter which cannot follow a parameter pack.

    Anyway, what are your thoughts about this?

  4. Type1J commented on Jun 1, 2017

    @Type1J
    Contributor

    I'm not sure what the status of it is, but std::array_view is proposed. I think that this is a task well suited to it.

  5. nlohmann commented on Jun 1, 2017

    @nlohmann
    Owner

    std::array_view is not part of C++11, so unfortunately it won't be applicable to this library for a while.

  6. nlohmann commented on Jun 17, 2017

    @nlohmann
    Owner

    Opened #623 as place to discuss the structure of the parsing functions.

  7. nlohmann commented on Jul 23, 2017

    @nlohmann
    Owner

    Function

    static basic_json from_cbor(detail::input_adapter i)
    {
        return binary_reader(i).parse_cbor();
    }

    now allows to read CBOR (and similarly, MessagePack) to a lot of types from which an input_adapter can be constructed. This includes a uint8_t */size_t pair.

    For a std::vector<uint8_t> packed, the call is

    json::from_cbor({packed.data(), packed.size()}

    (Note the braces around the pair.)

  8. pboettch commented on Jul 24, 2017

    @pboettch
    ContributorAuthor

    Great. And no copy of the buffer. Thanks. Can't wait for a release ;-) .

  9. added this to the Release 3.0.0 milestone on Jul 24, 2017
  10. self-assigned this
    on Jul 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions