支持多个 ANSI-C 代码库
我正在开发一个项目，该项目具有关联的 Ansi-C 代码库。 （让我称之为“主”代码库）。
我现在面临一个典型的问题（如下所述），我相信如果我手头有面向对象的语言，我将能够轻松解决这个问题。
问题是这样的： 我将不得不启动多个代码库；即我将不得不开始支持并行代码库（甚至将来可能更多）。所有新（即并行）代码库的初始代码库最初将与旧（即“主”）代码库相同。
当我们谈论“C”语言时，我到目前为止一直在考虑在代码中添加“#ifdef”语句，并在这些“ifdef”块内编写分支空间代码。
希望我能把问题说清楚（足够了！），我想听听关于聪明模式的想法，这将帮助我在 Ansi C 中优雅地处理这个问题。
干杯
I am working on a project, with an associated Ansi-C code base. (let me call this the 'main' codebase).
I now am confronted with a typical problem (stated below), which I believe I would be able to solve much easily if I had an object-oriented language at hand.
The problem is this:
I will have to start more than one codebases; i.e. I will have to start supporting a parallel codebase (even maybe more in the future). The initial codebases for all the new (i.e. parallel) codebases will initially be identical as the old (i.e. 'main') codebase.
As we are talking about the 'C' language, I have till now been thinking of adding '#ifdef' statements to code, and writing the branch-spacific code inside those 'ifdef' blocks.
Hoping that I made the problem clear (enough!), I would like to hear thoughts on clever patterns that would help me handle this problem elegantly in Ansi C.
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不同的代码库之间会发生什么变化？
请注意，在这两种情况下，首先也是最重要的一个问题是了解将要更改的内容，并设置代码以便尽可能少地进行更改。通常，处理变体的最佳方法（不可避免地会出现变体；否则，拥有两个或更多版本是没有意义的）是将不同的变体放在单独的文件中，然后编译和链接正确的文件。但有时，最好将变体（或变体的一部分）放在单个文件中并使用#ifdef 样式条件编译。
另一个关键点是将所有内容保持在同一版本控制系统下 - 尽可能长的时间，或者比这长一两年。
我见过的最大灾难发生在不同版本停止使用通用代码库时。现在我们需要重新整合两个代码库，十年的独立开发是一个主要障碍。过去十五年的一体化发展有起有落，但与我们现在面临的问题相比，这不算什么。啊!
What is going to change between the different code bases?
If it is just different platforms, you carefully isolate the platform dependencies, keeping as much of the core code the same across all platforms as possible, and putting platform-specific stuff into separate files.
If you are going to be changing the program functionality radically, you need to work out how to keep a common core of unchanged code while allowing for the differences between the programs.
Notice that in both cases, it is first and foremost a question of understanding what is going to change, and setting up the code so that as little as possible changes. Often, the best way to handle the variations (there are inevitably going to be variations; otherwise, there's no point in having two or more versions) is to put the different variations in separate files, and compile and link the correct files. Sometimes, though, it is deemed better to put the variations (or one part of the variations) in a single file and use
#ifdefstyle conditional compilation.The other key point is to keep everything under the same version control system - for as long as possible, or a decade or two longer than that.
The biggest disaster I've seen occurred when the different versions stopped using a common code base. Now we need to reintegrate the two code bases, the decade of separate development is a major obstacle. The previous fifteen years of integrated development had its ups and downs - but nothing compared to the problem we now face. Ugh!
您可以抽象出差异（或者至少尝试一下）。将所有特定于代码库的代码放置在与程序逻辑分开的文件中。然后，您可以使用条件编译（ifdef-include），并且只需替换每个新代码库的特定于代码库的文件，而整个应用程序逻辑可以保持不变。
You can abstract the differences away (or at least try). Place all your codebase-specific code in files separate from your program-logic. You can then use conditional compilation (ifdef-include) and only ever have to replace the codebase-specific files for each new codebase while your whole application-logic can stay unchanged.
作为基于
#ifdef的解决方案的替代或补充，您可以在 SCM 中维护不同的分支。As an alternative, or a complement, to
#ifdef-based solutions, you can maintain different branches in a SCM.