NFD

it doesn't seem something general enough to warrant a library implementation. As a matter of fact, FacePersistency is parsed in nfdc itself. Why is RouteOrigin different than FacePersistency?

nfdc only accepts 'persistent' and 'permanent' but not 'on-demand', so a general stream extraction operator of FacePersistency would not be useful. Also, it's unlikely for a new FacePersistency to be added.

nfdc can accept any RouteOrigin value, so it can use the stream extraction operator. Also, when a new RouteOrigin is introduced, only ndn-cxx needs to be changed.

nfdc only accepts 'persistent' and 'permanent' but not 'on-demand', so a general stream extraction operator of FacePersistency would not be useful. Also, it's unlikely for a new FacePersistency to be added.

Neither of these justifications are particularly convincing. In particular, nfdc could use a generic library-provided parsing function and then reject the "on-demand" value.

My point about not being "general enough" though was referred to the API itself. Why providing operator>> instead of e.g. a "fromString" kind of function?

Why providing operator>> instead of e.g. a "fromString" kind of function?

What's the benefit?

Junxiao Shi wrote:

Why providing operator>> instead of e.g. a "fromString" kind of function?

What's the benefit?

I don't know. It's more likely that an app has the data to be parsed in a string rather than an istream. But anyway, that's beside the point. I'm just saying that I'm not sure if an operator>> API would be general enough. You already made several choices in that API: accepting an istream, case-insensitive matching, leading/trailing whitespace handling, ...