Using input_adapter in a slightly unexpected way

[chetmurthy]

Feature Request

I'm trying to use input_adapter to wrap an Apache Thrift Transport (the details aren't really relevant). To that end, I need to provide the json::parse() function my own subclass of input_adapter_protocol, instead of an input_adapter. I'm happy to send a PR, but figured I should at least first check that this isn't something foolish, or something that can be achieved in another way? It was extremely straightforward to make my own subclass of input_adapter_protocol, btw.

modified   src/lib/cpp/json.hpp
@@ -1562,6 +1562,8 @@ class input_adapter
   public:
     // native support
 
+  explicit input_adapter(input_adapter_t arg_ia) : ia(arg_ia) { }
+
     /// input adapter for input stream
     input_adapter(std::istream& i)
         : ia(std::make_shared<cached_input_stream_adapter<16384>>(i)) {}

[nlohmann]

I am sorry, I need more context on this. I mean: it's good that you could achieve your goal without much effort, but I have not understood yet how a PR could look like.

[chetmurthy]

Ah, I wasn't very clear. So: in this particular case, I have a type that is like a std::istream, but with very few of the methods. It is easy to construct an input_adapter_protocol from it, but would be a lot of work to construct {istream, iterator, etc}. So I'd like to pass that input_adapter to json::parse, e.g.

json j = nlohmann::json::parse(input_adapter(std::shared_ptr<input_adapter_protocol>(new transport_input_adapter(s)))) ;

To do that, I needed to add another constructor to class input_adapter, where I just pass in the input_adapter_t. This is a change to your code, and I figured I should at least report it back to you, for two reasons:

(a) maybe I did something stupid grin

(b) I don't know whether you'd want to explain in your documentation that, in addition to all the other nice ways to read a JSON object, one can provide this really simple object (an input_adapter_protocol) with really only a get_character() method) and you'll parse from that.

In any case, it's working nicely, but I figured I should report back, is all.

I can send you a PR once I get everything all working and am certain that nothing else needs to be done.

[nlohmann]

If extending the library with a new input type is so simple, then of course I would be interested in an example or an PR to understand what needs to be changed.

[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.

[chetmurthy]

Neils, sorry I got sidetracked and didn't respond sooner. The code-snippet in my first comment -is- the change. That's it.

(1) the problem in the original code,was that there's no way for me to supply an input_adapter_t to the constructor to class input_adapter. An input_adapter can be made from many kinds of things, but not from an input_adapter_t. In my case, an input_adapter_t was exceedingly simple to construct, whereas all the other things were much harder.

(2) So I just added a new constructor entry.

That was it!

If you'd prefer, I can send you a PR. But really, the diff in my first comment is -everything-.

[nlohmann]

@chetmurthy Thanks for checking back! I wouldn't need a PR for this, but could you provide an example for the use case?

[chetmurthy]

Sure. In thrift, there's this type called "TTransport", and it's sort of like an istream, but .... different. It would be very messy to make it look like an istream. But -easy- to make it look like an input_adapter_protocol, e.g.

https://github.com/chetmurthy/thrift-nicejson/blob/3ce7a84af55591be4388f93c095032d739ee3917/src/lib/cpp/TNiceJSONProtocol.cpp#L316

https://github.com/chetmurthy/thrift-nicejson/blob/3ce7a84af55591be4388f93c095032d739ee3917/src/lib/cpp/TNiceJSONProtocol.h#L34

an input_adapter_protocol has two methods, both of which are concerned with reading. It's really simple. An iterator's interface is also pretty simple, but .... it requires knowing a lot more C++ to build something that looks like an iterator. [it's also possible that I've forgotten, and an iterator requires implementing things that a TTransport doesn't support -- but I forget, so I can't be firm on this.]

In any case, the type input_adapter_protocol is -so- trivial to implement.

[nlohmann]

I see.

So it's just adding

explicit input_adapter(input_adapter_t arg_ia) : ia(arg_ia) { }

then? Sounds doable.

[chetmurthy]

grin Yepper, it's that simple.