There seems to be little animo in this, but I am still really quite excited about it and hoping for input ideas from others. This is what I have come up with:
Motivation
Every programmer accumulates a bunch of reusable code snippets. Most often however these snippets end up in a global header file for a project from where they are then copy/pasted to new projects.
This has a few disadvantages. The code is clumsy and it is denied it's own life with proper unit testing and development evolution. Further this leads to several copies of similar or identical code lingering around without infrastructure to maintain them at once.
Any publicly released code also needs the code snippets to be up to standards and thoroughly tested.
Implementation
I found that a good solution for this can be created with a snippet library in git. All future projects I create can just take in this library as a submodule and individual snippets are again submodules from that repo. The user can than choose to only download those snippets they use while enjoying a central include directory for all, and central access to documentation and unit testing.
I have one TidBits_Cpp repository. This repository has submodules with each code snippet.
The main repo has an include directory just like boost, except that the includes in the central directory only include other files from subdirectories and there is only one exactly per tidbit, the one include you need if you want to use that tidbit. They wrap the subdirectory includes in a namespace tidbits. Keeping the namespace outs of the submodules allows other people to include these snippets in their own snippet libraries and add their own namespace around them.
Each submodule with a snippet has mainly header only implementation with a header for unit testing, and a standalone unit testing app.
The unit testing base class is also a TidBit. The main repo has a unit testing application that tests all the TidBits that exist on the system. For this it has a directory with dummy includes which should be last in the include path, so you can always compile. Checking defines allows to know which code is actually available for unit testing.
All code in the submodules assumes the central include directory to be in the include path.
Included in the repository are DoxyFiles, as well as visual studio solutions. Eclipse is harder because it deals badly with projects that use cpp files from different directories. I will add MakeFiles later for other compilers and platforms.
To get the full power of this any project that wants to use a TidBit should include a submodule pointing to the main TidBits_Cpp repository, and then pull the submodules they want to use. They can immediately run all unit tests without writing any code, and then just start coding.
The overhead from the parent repo is small, since it only contains one-line includes as well as 1 folder with some unit testing stuff and a DoxyFile.
The beauty of this kind of system is that the snippet repos need not even by my own. I can call in any github repository as a submodule, and so can other
Considering the static assert, well, I did pull my own one, although there are solutions available here without having to add boost as a dependency for a code snippet. The main reasons I would not do this is because boost is big and it is not available as a git repository, so it cannot get downloaded automatically as a submodule.
However, as Georg Fritzsche pointed out here it is possible to extract a part from boost with bpc. The disadvantage is that for static assert for example this still means 70 files...
If you are interested, this is the link to my repository, however consider it at the moment not more than an illustration to this post. The code in there right now is still very much under development and not yet suited for public release. Neither is there documentation etc. All that is for future times.
发布评论
评论（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 个文件...
如果您有兴趣，这是 链接到我的存储库，但目前仅将其视为本文的一个说明。目前其中的代码仍处于开发阶段，尚不适合公开发布。也没有文档等。所有这些都是为将来准备的。
There seems to be little animo in this, but I am still really quite excited about it and hoping for input ideas from others. This is what I have come up with:
Motivation
Every programmer accumulates a bunch of reusable code snippets. Most often however these snippets end up in a global header file for a project from where they are then copy/pasted to new projects.
This has a few disadvantages. The code is clumsy and it is denied it's own life with proper unit testing and development evolution. Further this leads to several copies of similar or identical code lingering around without infrastructure to maintain them at once.
Any publicly released code also needs the code snippets to be up to standards and thoroughly tested.
Implementation
I found that a good solution for this can be created with a snippet library in git. All future projects I create can just take in this library as a submodule and individual snippets are again submodules from that repo. The user can than choose to only download those snippets they use while enjoying a central include directory for all, and central access to documentation and unit testing.
I have one TidBits_Cpp repository. This repository has submodules with each code snippet.
The main repo has an include directory just like boost, except that the includes in the central directory only include other files from subdirectories and there is only one exactly per tidbit, the one include you need if you want to use that tidbit. They wrap the subdirectory includes in a namespace tidbits. Keeping the namespace outs of the submodules allows other people to include these snippets in their own snippet libraries and add their own namespace around them.
Each submodule with a snippet has mainly header only implementation with a header for unit testing, and a standalone unit testing app.
The unit testing base class is also a TidBit. The main repo has a unit testing application that tests all the TidBits that exist on the system. For this it has a directory with dummy includes which should be last in the include path, so you can always compile. Checking defines allows to know which code is actually available for unit testing.
All code in the submodules assumes the central include directory to be in the include path.
Included in the repository are DoxyFiles, as well as visual studio solutions. Eclipse is harder because it deals badly with projects that use cpp files from different directories. I will add MakeFiles later for other compilers and platforms.
To get the full power of this any project that wants to use a TidBit should include a submodule pointing to the main TidBits_Cpp repository, and then pull the submodules they want to use. They can immediately run all unit tests without writing any code, and then just start coding.
The overhead from the parent repo is small, since it only contains one-line includes as well as 1 folder with some unit testing stuff and a DoxyFile.
The beauty of this kind of system is that the snippet repos need not even by my own. I can call in any github repository as a submodule, and so can other
Considering the static assert, well, I did pull my own one, although there are solutions available here without having to add boost as a dependency for a code snippet. The main reasons I would not do this is because boost is big and it is not available as a git repository, so it cannot get downloaded automatically as a submodule.
However, as Georg Fritzsche pointed out here it is possible to extract a part from boost with bpc. The disadvantage is that for static assert for example this still means 70 files...
If you are interested, this is the link to my repository, however consider it at the moment not more than an illustration to this post. The code in there right now is still very much under development and not yet suited for public release. Neither is there documentation etc. All that is for future times.