7 git boost open-source github code-snippets
编程时,我会累积代码片段和实用程序类.我想存储那些以供将来使用.
简单的问题是什么是最好的方法.更详细的例子:
在编写代码时,我们不断重用我们的好花絮来涵盖常见任务.然而,为了使我们的项目开源,比如使用github上的git,这个花絮也需要可用.我想知道如何最好地做到这一点.
像所有公共代码一样,这样的代码片段应该轻巧,快速,经过测试,可移植,有文档记录,并且最好是相对自包含的.现在我在某个地方找到了这个漂亮的代码并且它使用了CTASSERT,这是不可移植的.
我该怎么办？
我期待着听到你如何解决这个问题,以及一般的想法和指导方针.
小智 1
这似乎没什么热情，但我仍然对此感到非常兴奋，并希望得到其他人的意见。这就是我想出的：
动机
每个程序员都会积累一堆可重用的代码片段。然而，大多数情况下，这些片段最终会出现在项目的全局头文件中，然后从其中复制/粘贴到新项目。
这有一些缺点。代码很笨拙，并且通过适当的单元测试和开发演化否认了它自己的生命。此外，这会导致类似或相同代码的多个副本徘徊，而没有基础设施来立即维护它们。
任何公开发布的代码还需要代码片段符合标准并经过彻底测试。
执行
我发现可以使用 git 中的代码片段库创建一个很好的解决方案。我创建的所有未来项目都可以将此库作为子模块，并且各个片段又是该存储库中的子模块。用户可以选择仅下载他们使用的那些片段，同时享受所有人的中央包含目录以及对文档和单元测试的集中访问。
我有一个 TidBits_Cpp 存储库。该存储库具有包含每个代码片段的子模块。
主存储库有一个包含目录，就像 boost 一样，不同之处在于中央目录中的包含仅包含子目录中的其他文件，并且每个花絮只有一个，如果您想使用该花絮，则需要包含该文件。他们将子目录包含在名称空间花絮中。将命名空间保留在子模块之外可以让其他人将这些代码片段包含在他们自己的代码片段库中，并在它们周围添加自己的命名空间。
每个带有代码片段的子模块主要只有标头实现，其中包含用于单元测试的标头和独立的单元测试应用程序。
单元测试基类也是 TidBit。主存储库有一个单元测试应用程序，用于测试系统上存在的所有 TidBits。为此，它有一个包含虚拟包含的目录，该目录应该位于包含路径的最后一个，因此您始终可以进行编译。检查定义可以了解哪些代码实际上可用于单元测试。
子模块中的所有代码都假定中央包含目录位于包含路径中。
存储库中包含 DoxyFiles 以及 Visual Studio 解决方案。Eclipse 更难，因为它很难处理使用来自不同目录的 cpp 文件的项目。稍后我将为其他编译器和平台添加 MakeFiles。
为了充分发挥这一功能，任何想要使用 TidBit 的项目都应该包含一个指向主 TidBits_Cpp 存储库的子模块，然后拉取他们想要使用的子模块。他们可以立即运行所有单元测试，而无需编写任何代码，然后开始编码。
父存储库的开销很小，因为它只包含一行包含内容以及 1 个包含一些单元测试内容和 DoxyFile 的文件夹。
这种系统的优点在于，片段存储库甚至不需要我自己的。我可以调用任何 github 存储库作为子模块，其他也可以
考虑到静态断言，好吧，我确实拉出了自己的断言，尽管这里有可用的解决方案，而无需添加 boost 作为代码片段的依赖项。我不会这样做的主要原因是 boost 很大并且它不能作为 git 存储库使用，因此它不能作为子模块自动下载。
然而，正如Georg Fritzsche在这里指出的那样，可以使用 bpc 从 boost 中提取一部分。缺点是对于静态断言来说，这仍然意味着 70 个文件......
如果您有兴趣，这是我的存储库的链接，但目前仅考虑它只是本文的说明。目前其中的代码仍处于开发阶段，尚不适合公开发布。也没有文档等。所有这些都是为将来准备的。