Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forced type conversion or lexical cast without exception. #1955

Closed
neel opened this issue Feb 24, 2020 · 5 comments
Closed

forced type conversion or lexical cast without exception. #1955

neel opened this issue Feb 24, 2020 · 5 comments
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated

Comments

@neel
Copy link

neel commented Feb 24, 2020

  • Describe the feature in as much detail as possible.
    json["index"].force<int>(-1) that will first check whether the current type of json["index"] is directly cast-able to int. If cast-able then do a static_cast. Otherwise convert the internal value to string (all json values can be converted to string representation). Then use lexical_cast<int> on that value. If both of these fails then return the default value 0 provided.
  • Include sample usage where appropriate.
    currently this is what I am doing.
size_type index = 0;
if(props["index"].is_number()){
    index = props["index"].get<size_type>();
}else if(props["index"].is_string()){
    index = boost::lexical_cast<size_type>(props["index"].get<std::string>());
}

I would prefer this to be done like

size_type index = props["index"].get<size_type>(0);
@FrancoisChabot
Copy link
Contributor

FrancoisChabot commented Feb 24, 2020

Is there a specific reason why you'd want this as a member funciton instead of just a free-floating utility function?

It's not like anything is preventing you from creating a wrapper around your boilerplate:

template<typename T>
T coerce_json(const json& j) {
    static_assert(is_integral_v<T>);

    T result = {};
    if(props["index"].is_number()){
        result = props["index"].get<T>();
    }else if(props["index"].is_string()){
        result = boost::lexical_cast<T>(props["index"].get<std::string>());
    }
    return result;
}

size_type index = coerce_json<size_type>(props["index"]);

@nlohmann
Copy link
Owner

I agree with @FrancoisChabot - the use case is too special to justify adding it to the public API to the library.

@neel
Copy link
Author

neel commented Feb 24, 2020

@FrancoisChabot This is what I am currently doing. This coerce<T> goes in an util header of the library that uses nlohmann::json. In some other independent submodules I also need the same feature. So what will be the manageable solution ? Having the same functionality in multiple places ? or having a common utility around around nlohmann json for such small needs. The best solution is to have this functionality inside the json library itself.

It can be a free function instead of being a member function. But I'd prefer this to be part of the json library. Not only about integral type I am talking about generalizing coerce<T> for any type. including float, double, char etc..

@nlohmann
Copy link
Owner

I think a util header is the best choice. The public API should only contain functions that are widely used.

@nlohmann nlohmann added the solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) label Feb 25, 2020
@stale
Copy link

stale bot commented Mar 26, 2020

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.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Mar 26, 2020
@stale stale bot closed this as completed Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated
Projects
None yet
Development

No branches or pull requests

3 participants