我最近有点着迷于向项目添加依赖项并期望它们正常工作的危险。我还看到，有些人试图将此解析为一切都不够好的声明，因此所有东西都必须更换。显然情况并非如此，但他们却乐此不疲地声称不是这样。
处理这个问题最简单的方法似乎就是站出来，谈谈我实际使用过的库，或者最近使用过的，可能还会再使用的库。
首先关注的是谷歌的相关内容。这里有gmock和gtest，它们通常都可以从yum(在我的RHEL/CentOS口味的机器上)、apt(在Ubuntu/Debian机器上)和Macports上买到。当我在里面的时候，我就养成了很久以前使用它们的习惯，现在还在继续使用它们。这与运行时库的情况不太一样，因为它只影响我的测试代码，但它们是第三方依赖项，所以它在这里算数。它们也工作得很好，所以我把它们留在身边。
还有Protobuf。它作为操作系统级别的软件包也很容易找到，它只是我以前开始使用的东西之一，现在还在继续使用。人们似乎没有太多谈论的一件事是，Protobuf有一个规范的ASCII表示，它构成了一种非常漂亮的配置文件格式，它是类型安全的、完全指定的，并且在程序中变成了一个很好的小对象。你甚至可以发表评论！是的，真的。我既用它来加载配置，也用它来实际序列化内容，并将其传送到其他地方。
现在，让我们来谈谈软件定义的无线电内容。在过去的几年里，我的扫描仪项目一直处于停滞状态，但是代码仍然存在(并且仍然在构建)。它是以一大堆东西为基础的。最大的显然是GNU电台。它是各种信号处理的软件实现的大杂烩，你通常会在电路板上的组件上做这些事情。它在某些地方的数学方面也是超级繁重的，有一堆MMX/SSE类型的优化，甚至可能有一些针对真正热点的特定于体系结构的汇编BLOB。如果您想要将I/Q样本转换为可用的数据，或者反之亦然，那么它几乎就是您要使用的工具。(对红鹰的评价越少越好，对吗？)。
我最初的SDR工作是在Ettus USRP设备上完成的，它使用自己的称为UHD库的小接口已经有很长一段时间了。这成为更大计划的依赖，尽管它埋藏在全球GNU无线电建设中。还有设备内部各种FPGA的二进制斑点，当您运行超高清设备时，这些FPGA就会随之而来。
我还玩上了那些可爱的小棍子，聪明的人意识到你可以把DVB电视接收器棍子变成不折不扣的SDR接收器。这意味着rtlsdr库本身充当实际硬件方面的驱动程序，而gr-osmosdr则将其(以及其他一系列东西，如果您有的话)连接回GNU Radio世界。
我监测到的第一个大型无线电系统是基于摩托罗拉的一个叫做SmartNet的系统，一个叫做GR-SMARTnet的库进入了我的生活，用来处理数据信道的解码。我不得不在内部有效地分叉这个，以处理多年来它在生产过程中的一些问题。尽管如此，如果没有作者所做的信号解码工作，所有这些都不会奏效。
第二个大型无线电系统是(现在也是)基于一个叫做APCO项目25，或简称P25的方案，还有一个叫做OP25的项目对其进行解码。这是一个比智能网(SmartNet)更大的问题空间，因为P25还意味着数字音频通道，然后必须解码。更复杂的是，这些语音路径使用专利(！)。DVSI的编解码器，许多人对反向工程感到不安是可以理解的。这导致了像DSD&34；这样的工具周围出现了很多隐蔽和匕首的东西。OP25实际上处理了所有这些问题，包括曾经难以想象的基于TDMA的第二阶段的事情，而且不知何故并没有与律师发生冲突。怎么做到的，我不知道。
实际上，我一度放弃了使用OP25的编解码器，而是选择了一款主要卖给业余无线电运营商的实际设备，但它也适用于我的情况。它相当于一个U盘，它缠绕在FTDI RS-232芯片上，然后缠绕在DVSI编解码器芯片上。你向它推送语音包，它就会把PCM音频传回给你。它是通过串口进行的，虽然不是世界上最快的事情，但它确实起作用了。实际上，我自己用电路板上AMBE芯片的规格编写了这部分代码。
在这里的扫描仪和无线电设备的世界里，实际网站上的所有电话都是以MP3的形式提供服务的。GNU电台没有编写MP3的部分，这并不令人惊讶。解决方案是使用LAME作为库，将PCM音频放入一边，从另一边取出MP3格式的数据。(早些时候也有过一些黑暗的日子，我掏钱从接收器里运行这个蹩脚的CLI工具，但关于这一点，我说得越少越好。哦，原型。)。
把特别提款权抛在脑后，让我们来谈谈网络产品吧。我的一些程序使用自己的内部Web服务器来提供状态页面，或者(直到今年早些时候)处理我自己糟糕的RPC类型方案。我没有为此编写我自己的http服务器。相反，我使用的是libmicrohttpd，这是另一个GNU库，自从我开始使用它以来，它已经变成了通常的yum/apt/macports类型的位置。我不再需要单独跟踪它，因为我可以从发行商那里获得它(在Linux机器上)，它将工作得很好。
对于网络客户端来说，基本上和其他所有人一样，还有libcurl。它用于正常的Web请求，就像以前我有一个RSS/Atom提要阅读器，需要从远程服务器获取更新一样。它也用于我上面提到的个人内部HTTP上的RPC方案。这也拉动了OpenSSL对https的支持。
[侧栏：我对最近网络协议的发展并不是很满意。它们变得越复杂，就会有越多的人堆积在少数几个实现上。然后，当有人弹出公共实现，每个人都必须打补丁时，我们将会有史诗般的安全狗屎狂欢。
你不相信我吗？看看SNMP发生了什么：ASN.1很糟糕，所以每个人都使用{CMU，UCD，NET}-SNMP。它在2002年前后流行起来，各种各样的东西，大部分都是*嵌入式*(路由器！)。必须打补丁或者直接扔掉。太糟糕了。
顺便说一句，提要阅读器项目需要使用XML，因此libxml进入了讨论范围。或者是libxml2？其中一件事。当你的名字中有一个数字而不仅仅是版本时，这是很奇怪的。(我相信这是有原因的。我只是不知道，也真的不在乎。)
最后，在Web世界中，我有时在提供Web浏览器时必须发出JSON。这很糟糕，但在这件事上我似乎没有太多的选择余地。有一小段时间，我通过printf；做了一件你可能会认为是JSON的可怕的事情，这听起来也很可怕。但是，我找到了一个名为Jansson的库，编写了一些包装器使其更适合我的C++环境，并开始使用它。令人高兴的是，它也很容易从各种OS分发打包系统中获得。
我的一些程序需要与数据库对话。这意味着libmysqlclient或libpq(Postgres)。这在很大程度上是理所当然的。当你和他们交谈时，你在这件事上没有太多的选择余地。它们的厚度也相对较大，因为它们不仅仅是通过网络与远端通话。
哦，而且，这应该是不言而喻的，但是对于人群中的顽固不化的Meeseek来说，显然我(和其他人一样)依赖于libc、libstdc++、ld.so、zlib以及所有其他在发行版的基础级别被拉入而您无法控制的东西。
上面的列表是通过转到我的计算机并查找我已经显式添加到我的项目中的库来编译的。我试图穷尽，但可能遗漏了一些操作非常好的东西，只是躲在堆栈的底部做他们的工作。如果您是这些作者之一，而我没有提到您，很抱歉，但是您应该感到自豪：您的代码正在工作，并且不会产生任何戏剧性的效果。