rapptz / jsonpp Goto Github PK

Essentially the title.

Rather than returning false like it should do, it just fails to compile instead making it a hassle for generic programming. This also applies to as<T>() though I'm not sure what the course of action should be for that.

Example:

#include <jsonpp.hpp>

struct pod {};

int main() {
    json::value x;
    return x.is<pod>();
}

Expected: return 0; equivalent.
Actual: Compiler error.

At the moment, json::value has a to_string member function that essentially gives a minimised JSON. That's good for some people, but there should be a way to get a properly "prettified" JSON.

These are the errors when compiling the first example:

a.cpp: In function 'int main()':
a.cpp:5:18: error: missing template arguments before 'p'
     json::parser p;
                  ^
a.cpp:8:9: error: 'p' was not declared in this scope
         p.parse("[null, \"hello\", 10.0]", v);

Cicada says it "should be json::parse(...) instead of p.parse, and no constructing parser p;".

Title.

Regarding the noexcept fix for VS2013, explicitly defaulted constructors marked as JSONPP_NOEXCEPT will fail to compile.

For example:

format_options() JSONPP_NOEXCEPT = default;

Expands as:

format_options() throw() = default;

Which fails to compile:

error C2610: 'json::format_options::format_options(void) throw()' : is not a special member function which can be defaulted exception specification is not allowed

Out of the box types supported by the dump mechanism can cause overload resolution issues if other types that are implicitly constructible/convertible from the out of the box types are thrown into the to_json overload pool.

Consider the following code snippet:

struct jsonpp_breaker {
    jsonpp_breaker( nullptr_t ) {

    }
};

json::value to_json( jsonpp_breaker breaker ) {
    return json::value(1);
}

int main( int argc, const char* const argv[] ) {

    std::string s = json::dump_string( nullptr );

}

In Visual Studio 2015 (RC), this makes the internal call to json::dump fail due to ambiguous overloads. Upon inspection of the internals, it seems like the Enable/DisableIfs are too lenient when it comes to evaluating whether to_json is acceptable: things that collide with the core serialized types (like nullptr constructors and friends) will trigger ambigious overload errors.

One implementation idea is to use a more sophisticated overloading mechanism or use a templated enable-if-friendly struct dumper<T, ...> to capture appropriate types when considering which dump function to use (it's default case should use the has_to_json<T> enable_if and provide a clean static_assert when that fails, and otherwise call whatever to_json is available).

A couple of changes required (thanks to Cicada of Lounge<C++>):

• No using inline namespace.
  • Solution: Take them out completely (unfortunately)
• No using noexcept.
  • Solution: Hide it behind a macro.
• Removing using alternative token keywords as those require an extra switch for those using it (e.g. ! instead of not).
  • Solution: Include <ciso646> when using them or remove them completely.

Apparently that's all needed to get it working.

It would improve usability if we could specify nested type arguments as legal types in as/is. For example, as<std::vector<std::string>>, or as<std::map<std::string, std::vector<double>>>, rather than unpacking manually for each nested type.

At the moment there's no way to turn a good ol' C++ class into JSON.

Ideally, there should be a way to turn a JSON string into a C++ object too, but that's too much work for something that could be provided by the user themselves so it's outside of the scope for this for now and probably outside the realm of possibility.

A good idea would be to have a to_json free function that takes in the custom type. The to_json function should return json::value that way it interacts with the API already in place.

At the moment they're ignored.

This specialization of parse should provide a default value for Flags.

Since it doesn't dump real JSON, it's probably not a good way to dump JSON. So it should probably be removed or renamed for a better API.

The reason it doesn't dump real JSON is because when dumping strings, it ignores the \uxxxx literals and even the escape sequences which makes it wrong.

It might be worth looking into how Python does JSON dumping. This allows it to be relevant to issue #5.

That way other people's code doesn't break.

Currently, you return an rvalue from operator[], not an lvalue. Furthermore, operator= is not banned on rvalues as it should be. This leads to the exceedingly unintuitive behaviour where

json::value v;
v["thing"] = "string";

does not actually modify v at all, but silently leaves it unchanged.

I think that either supporting this use of operator[], or making it a compiler error, would be useful.

As an alternative to v.as<T>() we should be able to specify json::value_cast<T>(v).

This allows for removal of the template keyword in generic contexts, i.e. v.template as<T>().

Another overload for default parameters if it doesn't exist is fine too.

There's no need to make a parser object, it should be a free function somehow.

The JSON spec doesn't allow comments but the parser shouldn't mind it.

Single line comments, e.g. // stuff and multi line comments e.g. /* */ should be fine.

Need to pass the conformance test suite from json.org

Currently the implementation that checks for leading zeroes disregards the possibility of the next value being the a decimal or a scientific notation initiative. That will need to be fixed along with other conformance issues.

There's no documentation atm. Would be cool to have some basic documentation of the interface in the wiki or a markdown file.

I've noticed that when calling as or is with a type that they do not support, you get a runtime exception, even though you provide distinct overloads for this condition that just throw. It would be nice if this was replaced with a static_assert.