jsmn: Problem with multiple definitions on C++

Hi, I’m using JSMN in an Arduino project using C++, including it in a header file which gets called in multiple files on the project. The only way I could get it to work is if I modify the jsmn_init and jsmn_parse by adding the inline tag (doing so seems to work ok for now). My questions are:

  • Is there a problem with this approach?
  • If not, is there a reason for these functions not to include it by default?
  • If there is, what would be the best way to include this changes in some official capacity? As it seems like a very basic problem (although very easily solvable), at least for C++ development. Maybe a small notice in the library description?

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 24 (1 by maintainers)

Most upvoted comments

I’d say you could do

#define JSMN_HEADER
#include "jsmn.h"

in father.h and once include jsmn.h before including father.h in main.cpp

It seems to work ok without including jsmn.h before father.h 🤷‍♂️🤔

It seems like the move to single header was not the best idea. It somewhat makes sense in small embedded projects, but seems to just cause issues in bigger projects.

While single-file libraries make sense with some build systems, they more often than not just are a PITA as they require to define custom compilation flags for one file, but not any other. The much simpler approach really is having the main code part of the library as part of the C files, which can then be compiled once and just linked into the final project (be it directly or indirectly using an object archive (static linking) or even as shared library (dynamic linking). This automatically resolves any symbol duplication issues that otherwise improper management of compilation flags with the single header approach may cause. Additionally, the header files are called “headers” for a reason: They should define the externally visible interface of a library, not its internal implementation.

Do you think it would be better to just revert to the regular source + headers system or somehow maintain both versions?

Yes, please have the code be a normal C file, with the header solely containing the externally visible library interface (and nothing more).