Abusing C to implement JSON parsing with struct methods

In my opinion, C really needs some officially supported reflection for the names of enums and such things. People have reinvented the wheel so many times and it never quite gets there.

I can make it ingest or emit whatever data format I want by writing a deserializer or serializer visitor for it (either directly or through a library), I can perform various pipeline-like transformations by chaining visitors together. The core is header-only, templated, constexpr and suitable for usage on resource-constrained systems.

I know that there are equivalents in managed or interpreted languages (like Java's Jackson library), but I haven't managed to find anything quite like it elsewhere on the Internet for compiled, unmanaged languages. Maybe I haven't looked hard enough or I just don't know what to search for, which is too bad because it handily beats writing serialization/deserlialization code by hand.

  struct json_value {
    enum json_type type;
    union {
      bool boolean;
      char *string;
      double number;
      struct {
        char **keys;
        struct json_value *values;
        size_t length;
      } object;
    } value;
  };

  json->value.object.length

  json->length

Always going through a 'virtual method table' also can't be great for performance (not so much because of the indirection, but because it acts as an optimization barrier for the compiler).

Peformance doesn't matter much of course when the code is ever only used to load tiny JSON files.

If you have normal, non-virtual instance methods you are better off making it a normal function with some class centric naming pattern, e.g. JSON_Parse(JSON* self, const char* json).

If you want to emulate virtual functions from C++ you are better off storing a single pointer to a statically allocated vtable of function pointers (1 instance per class), that way your instance structs are smaller at the cost of an extra indirection per virtual call. You could also go the Rust route and use a large pointer type (pointer to object + pointer to vtable) for polymorphic objects that avoids a longer dependency chain at the cost of larger object pointers.

No need to allocate, just use strtod on the original string.

He could evolve this further: use SOLID and design patterns.

If the goal is to bastardize C experience, why stop at objects?

CFLAGS is for optional flags that don't change semantics or whether (correct) code compiles at all…

That being said, it's still a very clever way to implement this.

https://github.com/montyanderson/foop

Instead of `json_parse(&parser_state)` your code calls `parser_state.parse(&parser_state)` in main. Instead of `json_eof(parser_state)` your code calls `parser_state->eof(parser_state)` in the implementation. This is more to type, more irregular (switching from . to ->), and has worse performance. This interface is also not flexible enough to implement a parser for other file formats such as XML. So it doesn't make things easier, and you're not actually making use of dynamic dispatch, so I don't see the point in using this technique.

In general I can not recommend this article for learning about C. I am being lenient about the things the author mentions explicitly, although I find even that mostly hand-waving away too much even for a prototype or short article. For example I have to say it is a bit of a head scratcher for me to hear that JSON is difficult to parse, since the ease of parsing is why JSON won to begin with. The linked article about JSON being a minefield is about underdefined semantics, not parser complexity.

The biggest mistake, and this is sadly hand-waved away as "over-engineering", is the large amount of mallocs and frees, and necessity to track stack vs heap allocations. In general this style of C reminds me of what my CS professors taught us before they showed us Java GC and C++ RAII as our saviors. C has its issues, but this is far from professional grade C code, and is what C looks like when written by programmers who come from higher level languages with less control over memory allocation (or STL-using C++ programmers where RAII mixes allocation and initialization). A tiny bump allocator would simplify all the following code enormously. For example the freeing function is very complex and can be avoided completely. Whether memory is managed by the stack or heap doesn't need to be tracked anymore. It becomes possible to write code that never allocates at all. Consider this article for comparison: https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...

The json struct mixes 2 responsibilities: providing data and parsing it. If we assume as in the article that all data is available from the start, then there's a lot of complexity in the parser that could've been avoided, since the parser is written as if it doesn't know where the EOF is and doesn't handle that error case correctly (especially in non-DEBUG build where ASSERT would be disabled).

Returning EOF in-band in cur is bad practice also in C. I would avoid this whole function by providing higher level parsing functions like peek and expect which would provide or check for certain tokens (this is for non-optimized easy to write parsers). The check for null/false/true atoms should've been a code smell that this should be easier to implement somehow.

In modern C null-terminated strings are mostly avoided, and string slices are used instead (begin pointer and size, or begin and end pointers). There are variables in the code called "slice", but they're C-strings. I'd suggest to the author to rewrite the code with slices and compare just how much more readable and efficient it becomes.

The whole json_value struct can also be avoided by using X-macros to define the structs. It's the way how one implements a visitor pattern (with serializer and deserializer functions) without language support for reflection.