1

I'm working on an opensource application that processes JSON in C, because I would like to make it easier for people to help me in the project and because JSON is so close to JS. I want to embed a JS engine and compile the JS into the software.

The reason I've chosen C for this particular program is because of C's speed. Is there any reason why I shouldn't include JS? I find it difficult to find any information regarding this particular topic.

Bob van Luijt
  • 223
  • 1
  • 8
  • 3
    Because with any bugs, you would [now have two problems](http://programmers.stackexchange.com/q/223634/40980). –  Jul 27 '15 at 20:31

1 Answers1

4

No reason why not... people embed Lua in C++ engines all the time, and sometimes JS engines. This enables them to run script-based code (eg for games, levels can be described in script).

However, it does raise a large level of additional complexity that may not be needed if all you want to do is parse JSON. For that get a JSON library for C instead (Spirit or libjson)

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • Not to mention any security issues that may be found in a given implementation of a javascript engine (ruby, I'm looking at you). Or the licensing of the javascript engine (if it has some incompatibilities with various other licenses). Or the overhead of launching up a javascript engine just to parse some json. Or the additional maintenance of keeping the engine up to date. Or the additional bundled size if statically linking. Or the "its not there" issues if dynamically linking. Or the joys of "its the wrong version" bindings. Oh... the joys. –  Jul 27 '15 at 20:47
  • @MichaelT I did say it'd add a large amount of complexity... but sometimes its what you need. Chances are though the OP really doesn't need it. – gbjbaanb Jul 27 '15 at 20:49
  • 1
    The 'huge amount of complexity' just seems to be so "simple". There is complexity in the code, and in the legal, and the implementation and the deployment. Its a huge large amount of complexity in a number of different areas - some of which aren't code at all.. –  Jul 27 '15 at 20:51
  • 1
    I'd say a large amount of possibly not-needed complexity is definitely a reason **not** to do something. – whatsisname Jul 27 '15 at 21:00
  • I've been using Jansson to parse JSON and it's pretty lightweight. The gulf between that and a JavaScript engine is *huge*. Partly deployment and maintenance cost as well - Jansson is pretty mature and the new releases tend to be down in the dots... 3.4.5 becomes 3.4.6 and "modify extension that allows comments" type things. – Ⴖuі Jul 27 '15 at 21:12
  • @MichaelT I get what you're saying and it really boils down to the actually design of the solution (besides the fact that I want to parse JSON). – Bob van Luijt Jul 28 '15 at 11:53
  • @gbjbaanb the example you gave of the description of levels is actually what I'm looking for, in the sense that I want to make it easy for people to pass the 'instructions' to _how_ the JSON should be parsed. Accepting the answer for now :-) – Bob van Luijt Jul 28 '15 at 11:53