我正在开始新的项目,需要决定如何处理配置。我最近遇到了一个无奶项目。虽然它有自己的问题,但我非常喜欢它的配置方法--只是一个带有静态变量的头文件。
使用编译时选项与运行时选项(==配置文件)有什么优缺点?对于更精通技术的用户来说,使用编译时配置的产品可以接受吗?它对现代系统还有好处吗?
我关注的是现代台式机/笔记本电脑,只有受支持的架构才可能是amd64。项目是GUI应用程序,重点是访问各种信息。
发布于 2015-04-29 17:28:44
这个答案是特定于C++的(如这个问题上的标签所示)。
大多数其他编译语言(C和C++之外)都没有这样的考虑,因为在这些语言中,将配置移动到编译时没有好处。在C和C++之外,条件编译非常不受鼓励或根本不受支持。此外,C和C++编译器应用积极的死代码消除和其他编译时优化,这样编译时配置所排除的代码就不会存在于二进制文件中。
当考虑到准时编译(JIT)时,这个问题也可能成为一个非问题.人们普遍认为,JIT总有一天会提供给C++。
从英里高的角度来看,编译时与运行时(或程序-launchtime)配置有三个主要考虑事项。
必要性是指软件、用户或法律上的需求,这些需求是僵化的,无法工作,因此影响到配置是否需要编译时或运行时。
例如,如果需要在不重新启动已经运行的应用程序的情况下更改配置,那么很明显,该配置必须是运行时可修改的。
如果项目对第三方组件有一个可选的依赖项,而该组件的许可条款使其不适用于某些客户子集,那么您将不得不提供一个构建配置,以便将该第三方组件的链接和使用从您的项目中包含或排除。显然,该配置必须是编译时。
这包括所有事情的时间成本和不便成本-用户的时间重新编译,代码执行开销(条件检查,读取配置等),以及许多其他事情。
正如Dan在评论中指出的那样,重新编译所花费的时间通常会大大超过其他方面的时间。
这个观察的唯一例外是,如果由于其他原因,代码已经频繁地被重新编译,比如每天,甚至每小时一次。当一个持续集成(自动构建和部署)系统已经到位时,就会发生这种情况。在这样的环境中,将配置放入编译时可能是有效的,因为没有额外的成本,而且从更改到效果的延迟很小。
当一个人需要支持多个配置时(无论是编译时还是运行时),当一个人需要支持多个配置(无论是编译时还是运行时)时,膨胀指的是当只需要一个这样的配置时,与相同的数量相比,构建工件的大小、数量或其他数量的增加。
例如,如果一个人可以选择在某项任务中使用算法A与算法B:
很明显,选项3必须有最大的膨胀,因为许多二进制逻辑是共同的,这两者将不得不重复。与备选案文3相比,备选案文1造成的膨胀似乎是合理的。
选项2缺乏运行时的选择,因此它受制于第一个标准--必需--取决于软件和用户的需求。
选项4需要额外的编程努力,但与所有其他选项相比,对负担和膨胀的影响最小。
发布于 2015-04-29 15:42:37
您的决定是基于代码的配置还是基于文件的配置,完全取决于您是否需要在运行时和编译时进行配置的灵活性。性能几乎肯定不是问题,因为一旦从配置文件读取了值,就可以缓存它们。
发布于 2015-04-29 15:48:44
标题暗示这个话题有一定的观点基础。
然而,让我们忽略这个问题,并解决这个问题。我认为利与弊是相当明显的,因为这两种方法都只是取舍。
例如,假设您已经实现了一个运行时配置-系统。缺点:
优点:
那么,让我们看一看编译时配置选项:优点:
缺点:
正如一开始提到的,这主要是基于意见,因为利弊没有太大的份量。如果您已经实现了一个解析器,您可以使用配置文件来填充该解析器,那么我将继续使用它。
编辑:我忘了说的话:只公开那些配置值,您想要修改这些值。让用户启用系统上不支持的功能是没有意义的。
https://softwareengineering.stackexchange.com/questions/280489
复制相似问题