Single_file_libs：单文件C/C++库列表

我是大量单文件C/C++公共域库的作者，我不是唯一这样编写库的人，所以下面是其他类似的库。

通常，下面列出了一些小的、易于集成的、可移植的库，它们可以从C和/或C++中使用，并且应该能够在32位和64位平台上编译。然而，我没有亲自核实任何特定的库是如广告所说的那样，或者是高质量的软件。

库应可在多个平台上使用(理想情况下，所有主要台式机和/或所有主要移动设备)。

这里列出了很多JSON解析器。有关一些分析和性能结果，请查看https://github.com/miloyip/nativejson-benchmark。

可从C和C++使用的公共域单文件库以粗体显示。其他库要么是非公有领域的，要么是两个文件，或者不能同时在C和C++中使用，或者这三个库都不可用。包含两个以上文件的库通常是被禁止的。

对于API列，"；C"；表示仅使用C，"；C++"；表示仅使用C++，而"；C/C++"；表示C/C++可用；某些文件可能需要构建为C或C++，但只要头文件使用extern"；C"；使其工作，仍符合"；C/C++"；的条件。(在某些情况下，仅用于头文件的库可能编译为C或C++，但生成的实现只能从其中一个调用，因为没有使用外部。在这种情况下，该表仍将其限定为C/C++，因为这对大多数用户来说不是障碍。)。

针对Protobuf、LCM/ZCM、JSON和MsgPack序列化/反序列化的本机实现的跨平台套接字包装和数据编组。

也有这些XML库，但是我非常不喜欢XML，所以我把它们放在地下室，让您三思而后行。

新图书馆的提交：我接受提交(作为问题或作为拉取请求)。请注意，必须包含在用户的项目中的每个文件都是2个文件；头文件和源文件是2个文件，但是头文件、源文件和许可证(如果许可证不在源文件中)是3个文件，不会被接受，因为它不是2个文件。但实际上，许可证无论如何都是将库放到源树中的问题，因为它的作用域不只是库，因此鼓励库作者将许可证包含在源文件中，而不需要单独的许可证。？

更正：如果上述图书馆的信息有误，请以问题、拉取请求或电子邮件的形式发送更正。请注意，如果列表指示某个库可以同时从C/C++和C/C++运行，但它不能工作，则这可能是列表中的错误，也可能是库中的错误。如果您发现某个库不能在32位或64位下运行，则应将该库从该列表中删除，除非它是库中的错误。

为什么由此列表中的3个或更多文件组成的库XXX不在此列表中？

我最多在2个文件中任意划线。(请注意，一些看起来是两个文件的库需要单独的许可证文件，这使得我将它们省略了)。其中一些库仍然很容易放入您的项目中并进行构建，因此您可能仍然可以接受它们。但是，由于人们来到STB是为了单文件公共域库，我觉得与我们在这里所做的距离太远了。

为什么最多只有两个文件且对此列表的其他依赖性最小的库XXX不是？

可能是因为我对此一无所知，您可以随时提交请求、发布、发送电子邮件或向我发推特(可以是您自己的图书馆，也可以是其他人)。但我可能因为其他各种原因而不包括它，包括什么是最小的其他依赖的微妙之处，以及什么是轻量级的微妙之处。