Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compile-time JSON deserialization in C++

medium.com

Post reply on HN
Print view View original

11–20 of 89 posts

Re: Compile-time JSON deserialization in C++

#11

Post by threatripper »

adolph wrote: post #10
stephc_int13 wrote: post #9

I am afraid of the compile-time cost. For this kind of things I tend to prefer using a simpler program (written in anything you like) to generate C or C++ instead of having the compile do the same thing much slowly. Meta programming can be good, but it is even better done with an actual meta program, IMO.

Brings to mind the old story about a JSON DSL https://thedailywtf.com/articles/the-inner-json-effect

Is this real? It can't be real. Nobody can be this stupid. But then again it takes a special kind of person who doesn't understand satire to actually do something like that. Somebody, where they would say "we trained him wrong on purpose as a kind of a joke".

Re: Compile-time JSON deserialization in C++

#13

Post by leni536 »

nikeee wrote: post #5

Could this be leveraged to emit a parser that is specialized for the provided type that can be used at runtime? Afaik .NET does something like that using code generators. The advantage being that the parser is tailored to the specific type that is deserialized and it writes directly to the struct's fields instead of going through some dictionary.

This lib does something like that:

https://github.com/beached/daw_json_link

Re: Compile-time JSON deserialization in C++

#15

Post by bruce511 »

threatripper wrote: post #11
adolph wrote: post #10

Earlier quoted context omitted.

Brings to mind the old story about a JSON DSL https://thedailywtf.com/articles/the-inner-json-effect

Is this real? It can't be real. Nobody can be this stupid. But then again it takes a special kind of person who doesn't understand satire to actually do something like that. Somebody, where they would say "we trained him wrong on purpose as a kind of a joke".

I'm _pretty_ sure it's satire, but the fact that you and I can't say for sure is perhaps illustrative of the failure.

I've encountered this pattern several times over my career. Some very smart programmer decides that for "reasons" the standard way to do something is "bad". (Usually "performance" or "bloat" are words bandied around.) They then happily architect a new system to replace the "old thing". Of course the new thing is completely undocumented (because genius programmers don't waste their time writing docs).

If you're _lucky_ the programmer then spends his whole career there maintaining the thing. If you're lucky the whole thing becomes obsolete and discarded before he retires. Hint: You're not lucky.

So what you are left with is this big ball of smoosh, with no documentation, that no-one can figure-out, much less understand. Oh he designed this before multi-core processors were a thing? Before we switched to a preemtive threaded OS? Well no, none of the code is thread-safe, and he's left the company so we need someone to "just update it".

There are reasons standard libraries exist. There are usually reasons they're a bit slower than hand-coding specific cases in assembler. There are reasons why they are "bloated" with support for lots of edge-cases. (like comments).

When some really smart person starts talking about how it's all rubbish, be afraid. Be very afraid.

Re: Compile-time JSON deserialization in C++

#16

Post by emmanueloga_ »

dctwin wrote: post #2

Hello! I wrote this short blog post about using pattern-matching-like template metaprogramming to deserialize JSON at build time - please let me know what you think (especially if you see improvements)

The concept reminds me of F#'s "Type Providers" [1].

In terms of the implementation ... I feel like C++ is best when used in an "orthodox style" and minimizing the use of templates as much as possible.

--

1: https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/ty...

Re: Compile-time JSON deserialization in C++

#17

Post by kazinator »

stephc_int13 wrote: post #9

I am afraid of the compile-time cost. For this kind of things I tend to prefer using a simpler program (written in anything you like) to generate C or C++ instead of having the compile do the same thing much slowly. Meta programming can be good, but it is even better done with an actual meta program, IMO.

> generate C or C++ instead of having the compile do the same thing much slowly

That's a wild-assed guess. A JSON decoder right in the compiler could easily be faster than generation involving extra tool invocations and multiple passes.

Also, if you use ten code generators for ten different features in a pipeline instead of ten compile-time things built into the language, will that still be faster? What if most files use just use one one or two features? You have to pass them through all the generators just in case; each generator decides whether the file contains anything that it knows how to expand.

Re: Compile-time JSON deserialization in C++

#18

Post by kazinator »

anothername12 wrote: post #12

Not a C++ user, but is this the same as #. reader macro in Common Lisp?

Also, this:

  (defmacro macro-time (&rest forms)
    `(quote ,(eval `(progn ,@forms))))
forms are evaluated at macro-expansion-time, and their result is quoted, and substituted for the (macro-time ...) invocation.

For instance, if we have a snarf-file function which reads a text file and returns the contents as a string, we can do:

  (macro-time (snarf-file "foo.txt"))
and we now have the contents of foo.txt as a string literal.

Re: Compile-time JSON deserialization in C++

#19

Post by _nalply »

threatripper wrote: post #11
adolph wrote: post #10

Earlier quoted context omitted.

Brings to mind the old story about a JSON DSL https://thedailywtf.com/articles/the-inner-json-effect

Is this real? It can't be real. Nobody can be this stupid. But then again it takes a special kind of person who doesn't understand satire to actually do something like that. Somebody, where they would say "we trained him wrong on purpose as a kind of a joke".

It's the inner platform effect. When I was young I fell into the same trap. I invented a flexible database schema where I put each field into a database row with some metadata describing the field. But that's nonsense. Just use what the database provides.

There's a Wikipedia page about it: https://en.wikipedia.org/wiki/Inner-platform_effect

A variant of it is: Any sufficiently complicated program contains a slow and buggy implementation of half of Lisp. That's the Greenspun's tenth rule: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

This applies to the kernel as well to put it bluntly and a bit ironically: eBPF, but this shouldn't be understood that I mean that eBPF is not well thought out! https://en.wikipedia.org/wiki/EBPF

Re: Compile-time JSON deserialization in C++

#20

Post by jayd16 »

kazinator wrote: post #17
stephc_int13 wrote: post #9

I am afraid of the compile-time cost. For this kind of things I tend to prefer using a simpler program (written in anything you like) to generate C or C++ instead of having the compile do the same thing much slowly. Meta programming can be good, but it is even better done with an actual meta program, IMO.

> generate C or C++ instead of having the compile do the same thing much slowly That's a wild-assed guess. A JSON decoder right in the compiler could easily be faster than generation involving extra tool invocations and multiple passes. Also, if you use ten code generators for ten different features in a pipeline instead of ten compile-time things built into the language, will that still be faster? What if most files…

I'm not taking sides but I don't think a code-gen tool necessitates re-scanning the entire codebase every compile. gRPC would be a good example.
Post reply on HN