已关闭。此问题需要更多focused。当前不接受答案。
**想要改进此问题吗？**更新问题，使其仅关注editing this post的一个问题。
3天前关闭。
Improve this question
在我们现有的代码库中，我们有浮点类型的typedef FP_TYPE。这个类型的目的是（或多或少）= double，但让我们有一个开放的选择，很容易改变它为浮点，以实验它将如何影响速度、内存使用和精度。
现在我们将较大的代码库拆分成独立的库模块，其思想是库应该基本上彼此独立。然而，使用FP_TYPE的typedef将要求所有库共享至少一些公共include（具有FP_TYPE定义）-因此它们不会完全独立。
或者我们可以使用模板（它可以把float或double作为模板参数）。这样模块就可以独立了，但这也有它的缺点。因为我们只需要在一个项目的构建中所有的类/函数都使用float或都使用double（以前由FP_TYPE定义确定）我们将在基本上不需要模板的地方引入模板（因为我们不需要同时混合浮点数和双精度数），而且对于模板，您或多或少被迫将实现放在头文件中，而不是当前状态中，此时头文件（使用FP_TYPE）只能包含声明。
在假定独立的库中使用公共FP_TYPE是一个坏习惯吗？它比使用模板带来的复杂性更糟糕吗？单元测试如何？只为“FP_TYPE”而不是特定的浮点/双精度版本的FP_TYPE编写测试可以吗？如果我们要使用模板，我认为测试将只为用例编写。那么它是否可以与只有在FP_TYPE运行时才运行的FP_TYPE测试相比呢？TYPE == double？测试和FP_TYPE可能既是浮点数又是双精度数有什么问题吗？这种情况与我们通常不根据sizeof（int）或sizeof（size_t）编写测试的情况有什么不同吗？
1条答案
按热度按时间h22fl7wq1#
如果你有一个命名基本类型的公司政策，比如FP_TYPE、INT和BOOL，那么你写的所有东西都必须包括一个定义内部基本类型的头文件。
从历史上看，大多数软件团队都会有这些，因为它有助于在具有不同本机位宽的平台之间以及在使用不同整数大小的编译器之间移植代码。
如果UI_INT是16位的，而COMMS_INT是32位的，那么很快就会出现疯狂和糟糕的情况。
然而，我看不出有多少理由从64位后退，也没有理由前进到128位，无论如何，C和C都有你可以使用的固定整数大小的标准化名称。
现在使用float over double有什么实际的好处吗？旧库已经使用了多少年了，你多久利用一次这个特性？
因此，如果您现在正在重新使用C，也许是时候放弃这些内部命名，而使用泛型或固定宽度命名了？好处是每个人都可以阅读您的代码，并且可以更快地编写代码。
但是，如果您认为仍然需要支持其他编译器和32位平台，那么您可能需要保留自己的命名约定。