![]() |
1
6
我认为处理这个问题的正确方法是将代码库拆分为特定于平台的模块,并在构建时将它们组装起来(这当然需要某种平台抽象层)。这样一来,Unix代码就不会被Windows调用所占据,反之亦然。有效地将ifdef头痛转移到makefile。 |
![]() |
2
3
我在职业生涯的大部分时间里不得不同时支持多个平台。这就是我过去解决问题的一般方法:抽象出依赖于平台的部分并将它们隐藏在可移植接口后面,为需要支持的每个平台创建该接口的单独实现,并使用适当的makefile魔法构建所需的内容。 例子:
此接口提供应用程序代码将引用的平台无关类型和原型。
这是Windows版本(WindowsModule.c)。
这是Unix特有的版本。 现在只需要在makefile中设置正确的规则。无论是静态地构建所有的东西,还是将特定于平台的代码构建到.dll中,都不太受可移植性的影响,而更多地取决于对所讨论的应用程序有意义的东西。我所做的大部分都是静态链接的。
是的,这是一个屁股痛,但它的规模
许多的
诀窍是正确地使用抽象类型,以便它们包含底层实现所需的所有内容,而不会给程序员带来过多的实现细节负担。是的,很难做好,而且我没有任何好的“食谱”例子来演示。 |
![]() |
3
2
在C++或其他一些面向对象语言中,可以抽象平台,并使用工厂(ETC)来实例化正确的平台特定实现。 也就是说,如果您需要/想要如上所述的ifdef,我建议您采用以下方式:
|
![]() |
4
1
通常,代码片段变得足够大,看起来像这样:
有时它会变得足够大,以至于我们可以在链接器中执行(根据makefile开关连接impwindows.o或impunix.o)。 |
![]() |
5
1
|
![]() |
6
1
没有绝对的真理。 我会这么做的。我会抽象掉这个例程,只调用一个函数来检查您所使用的平台。我把它也包括在内,因为我喜欢那里。
|
![]() |
7
0
可以为每个平台(.so或.dll)创建单独的共享库,然后在运行时动态加载相应的库。每个库将包含特定于平台的代码。对于特定于操作系统的加载库调用,您需要一个包装器,但这可能是您唯一的#ifdef’d函数。 |
![]() |
8
0
Imake最初由X window系统使用,其工作原理类似于knight666的答案;它使用一组依赖于系统的配置文件来确定系统的具体功能,并允许您处理系统之间的差异。据我所知,它从来没有见过多少实际的使用,而且从维基百科页面来看,即使是X窗口系统也不再使用它了。Imake有点恐怖。 Autoconf/automake(和libtool)是shell脚本、Makefile模板和m4宏的捆绑包,它们生成“configure”脚本,每个人都知道并喜欢在任何模糊的Unixish上构建软件。configure脚本运行一系列测试,然后定义预处理器宏并编写Makefile,这两种方法都允许代码处理系统依赖关系。如果你感兴趣的话,一本相当不错的书, GNU Autoconf, Automake, and Libtool ,是可用的,尽管它看起来已经过时了。Autoconf和automake有点恐怖。
执行诸如“if(windows){doWindowsRoutine();}”这样的动态操作通常行不通,因为dowWindowRoutine不会在非windows计算机上编译。 总的来说,整个地区不仅仅是一个爬行恐怖。 |
![]() |
sid_com · 为条件OO模块加载编写包装器模块的正确方法是什么? 11 年前 |
![]() |
tssch · 获取用户名的可移植方式 11 年前 |
![]() |
Prof. Falken · 如何编写(可移植的)反向网络字节顺序? 11 年前 |