目前， network.h包含大量特定于平台的标头（如u.h 、 windows.h和unistd.h ）。 我们应该将这些限制在一个文件（或几个文件）中。
我建议我们在用于网络的操作系统设施上创建一个薄抽象，并为单调时钟创建另一个抽象。 然后我们可以为每个平台类型创建一个文件（例如${module}_win32.c ， _unix.c ， _osx.c ， _posix.c ，...）并根据预处理器有条件地编译它们符号，就像我们已经做的一样。 缺点是它的声明开销要多一些，因为目前那些#ifdef是在需要为每个平台重新定义的函数内部。 优点是代码本身没有或很少有#ifdef s，并且平台特定代码在一组小文件中，而不是（就像现在）在 1100 行文件中混合平台抽象与应用程序代码。
iphydf
👍3
所有5条评论
听起来不错
nurupo
于 2016-09-12
我们做一个“系统”接口，可以由“windows系统”和“posix系统”和“测试系统”来实现怎么样？ 测试系统可用于单元测试并模拟系统，而无需实际进行系统调用。
iphydf
于 2016-12-18
👍2
我不同意实施建议。 我更愿意在一个文件中看到所有函数{network,time,...}.c ， #ifdef用于包装需要为每个平台编写不同的函数。
这种方法相对于单独文件的好处是，我们可以将所有特定于平台的代码强制为静态函数，并为更高级别的 toxcore 公开单个 API。 任何平台实施细节都可以从单个文件中轻松查看。 平台特性需要在单个文件中进行抽象和处理，而不是跨多个文件进行处理。 它还将使 cmakelists.txt 文件更易于维护（它已经开始远离我们了。）然后使用我们当前的审查系统进行审查。
GrayHatter
于 2016-12-30
👍1
没有完全固定
Diadlo
于 2017-01-27
@GrayHatter同意。 让我们有一个实现操作系统细节的文件。
我现在取消分配
iphydf
于 2018-01-16
此页面是否有帮助？
0 / 5 - 0 等级
相关问题
tox-user
·
4评论
iphydf
·
9评论
hkarel
·
8评论
DataMaster-2501
·
6评论
zoff99
·
4评论
最有用的评论
我们做一个“系统”接口，可以由“windows系统”和“posix系统”和“测试系统”来实现怎么样？ 测试系统可用于单元测试并模拟系统，而无需实际进行系统调用。