output_adapter not user extensible

[abrownsword]

I have a type that isn't a vector, string or ostream that I really want to use with to_msgpack directly, rather than having to cause an 'extra' memory copy. I thought that output_adapter would be perfect for this... unfortunately I've discovered that it only has 3 constructors for the aforementioned 3 std types.

If it had an additional constructor that accepted an output_adapter_t, then I could construct my own adapter object and pass it in.

[nlohmann]

Good point! I shall have a look.

[nlohmann]

FYI: Started working on this issue: https://github.com/nlohmann/json/compare/feature/extensible_output_adapter

Is this what you had in mind?

[abrownsword]

Yeah, that looks pretty much exactly like what I envisioned. Should be very useful to adapt to all manner of containers, stream APIs, etc.

[nlohmann]

Before opening the input and output adapters for extension, I cleaned up a bit, and I would love to get some feedback on this:

• Started to move the logics to create an input_adapter_t or output_adapter_t from the respective constructors in the input_adapter/output_adapter class to static functions make_input_adapter/make_output_adapter. Eventually, we should not be needing class input_adapter/output_adapter any longer.
• Removed char type template parameter from output adapter protocol (and thus, from class output_adapter, binary_writer). The JSON library now uses uint8_t for bytes to write, and it the job of the output adapter to do conversions where required. This removes a lot of logics, because serializer worked with char and binary_writer with uint_8, but only the serializer was able to cope with different char types...

Any ideas on this?

[abrownsword]

Scanned through your changes and it looks like a nice cleanup and refinement. One thing would make my life even easier that I don't see in there: I have a class in which I've concretely implemented your two write_characters functions (but I don't want to inherit from your protocol), and it would be nice if there was a templated version of the adapter that could trivially adapt my class to your output function.

[nlohmann]

This is basically what we're doing with the SAX interface: we do have an interface, but we accept any object as long as it passes a SFINAE check. This would be more work, though, and I am not sure whether this can be done without a breaking change...

[abrownsword]

Can't you just provide a template that can be used to adapt anything to be your protocol though? Its not transparent, but its at least a 1-liner?

[abrownsword]

Your latest readme update gave me an idea for another input_adapter use case: a comment stripper.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[abrownsword]

This has gone stale thanks to the bot, but is the feature still on the todo list? @nlohmann

[abrownsword]

@nlohmann -- is there a plan to implement this idea in the near future?

[nlohmann]

I did not come to it... Any help is greatly appreciated.

[nlohmann]

I'll reopen and see if someone can take a look.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[abrownsword]

@nlohmann -- keeping the hope alive.

[jzakrzewski]

I'd also like to see this implemented. It'd save me a lot coping data around.

[abrownsword]

I keep having new use cases for this showing up (mostly because writing to, or at least not directly to, std::ostream is very often not where we want to send data).

[FrancoisChabot]

I am of the opinion that this should be wrapped within a larger refactor of the output_adapter system (see #2172).

If we do go through with moving away from the abstract interface to a templated approach for performance, then it makes sense to do add that feature within that context.