程序可移植性 [英] Program portability

查看:163
本文介绍了程序可移植性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如何确保我的程序完全可移植?

How to make sure that my program will be fully portable?

推荐答案

1。测试



这是必要的,但不是正确做任何事情的充分条件。要测试可移植性,您需要多个平台和编译器。

1. Test

This is a necessary but not a sufficient condition for doing anything properly. To test portability, you'll want multiple platforms and compilers.

这意味着,只有做了一些,如果标准说你能做到。只有预期的特定结果,如果标准说,你可以期望它。如果标准说它存在,只使用库或API。该标准可在此处(以及其他地方):

This means, only do something if the standard says you can do it. Only expect a particular result if the standard says you can expect it. Only use a library or API if the standard says it exists. The standard is available here (among other places):

http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-%20ANSI%20ISO%20IEC %2014882%202003.pdf

如果您假设:


  • CHAR_BIT等于9。

  • sizeof(int)等于5, int 是37位类型。


  • 基本字符集为EBCDIC。

  • Epoc始于1721年。

  • time_t double

  • CHAR_BIT is equal to 9.
  • sizeof(int) is equal to 5 and int is a 37 bit type. Or a 16 bit type.
  • the basic character set is EBCDIC.
  • The epoc began in 1721.
  • time_t is double

等等。我不是这个意思,编写依赖于这些事情的代码是真的,我的意思是写代码,如果他们是工作,也将工作在一个平稳的实现。

And so on. By which I don't mean, write code that relies on those things to be true, I mean write code that will work if they are, and will also work on a sane implementation.

这是唯一可行的方式给自己一个合理的机会实现(1)。

This is the only practical way to give yourself a reasonable chance of achieving (1).

理论上,没有一个非便携的C ++程序使用 export 。如果它是一个完美的C ++程序在其他方面,那么它将工作在任何一致的C ++编译器。但几乎没有人使用合格的C ++编译器,所以有一个 C ++的实际子集,你会想要坚持。

Theoretically, there's nothing non-portable about a C++ program that uses export. If it's a perfectly good C++ program in every other respect, then it will work on any conforming C++ compiler. But hardly anyone uses a conforming C++ compiler, so there's a de facto common subset of C++ that you'll want to stick to.

某些东西在标准C ++中不可移植,如在屏幕上绘制图形,因为标准C ++没有图形或GUI API。所以没有这样的东西作为一个完全便携的GUI程序用C ++编写。所以你可能需要或可能不需要修改你的目标,取决于你的程序应该做什么。

Certain things are not portable in standard C++, such as drawing graphics on a screen, since standard C++ has no graphics or GUI API. So there is no such thing as a "fully portable" GUI program written in C++. So you may or may not need to revise your goal, depending what your program is supposed to do.

如果你的程序需要的东西,根本不能完全在标准C ++ ,那么您可以通过将该行为封装在您认为应该在您关心的所有平台上实现的界面中,使您的程序更容易移植。然后设置关于实现它为每一个。这不会导致一个完全便携的程序,因为对我来说意味着一个程序,你可以编译和运行不变的任何符合的C ++实现。一个程序可以移植到大多数平台与C ++编译器,可能,假设他们有一个屏幕和鼠标,与一些定制的编程工作,是不一样的。

If your program requires something that simply cannot be done entirely within standard C++, then you can make your program easier to port by encapsulating that behaviour within an interface which you think should be implementable on all platforms you care about. Then set about implementing it for each one. This doesn't result in a "fully portable" program, though, since to me that means a program which you can compile and run unchanged on any conforming C++ implementation. A program which can be ported to most platforms with a C++ compiler, probably, assuming they have a screen and a mouse, with some bespoke programming work, isn't the same thing.

当然,所有这一切都可能过得太远。你可能实际上想假设 CHAR_BIT 是8(否则读取文件是疯狂的),甚至可能依赖于一个GUI框架,如Qt。但是你说的是完全可移植的,并且你需要做的主要事情之一是编写可移植程序通常是计算出你愿意在完全妥协的程度。

All this can be taken too far, of course. You will probably actually want to assume that CHAR_BIT is 8 (reading files is madness otherwise), and perhaps even rely on a GUI framework like Qt. But you did say, "fully portable", and one of the main things you need to do to write portable programs is usually to work out how far you're willing to compromise on "fully".

在编译时,如果你可以,或者运行时,否则,请确保如果你的程序需要int至少为32位(或任何)它会失败,当它不是。 OK,所以全面的测试覆盖率会捕获您的算术默默地溢出并给出错误的答案的情况,但是很难编写真正全面的测试,无论如何测试可能会造成与代码相同的非可移植错误,或一些糟糕的吮吸者已下载您的代码,可能无法正常运行它们。

At compile-time if you can, or runtime otherwise, ensure that if your program requires int to be at least 32 bits (or whatever), then it will fail noisily when it isn't. OK, so comprehensive test coverage would catch cases where your arithmetic silently overflows and gives the wrong answer, but it's hard to write truly comprehensive tests, and anyway the tests might make the same non-portable errors as the code, or some poor sucker who has downloaded your code might not run them all properly.

使用库时,您可以自动执行此操作。您将 #include 一些标题,如果库不可用,将立即失败。至少,你希望它会的 - 可以想象,一些其他的实现可以有一个相同名称的头部,做一些根本或微妙的不同。根本差异通常会导致编译失败,对于可以测试预处理符号来标识实现的细微差异

When you use libraries, you are effectively doing this automatically. You'll #include some header, and if the library isn't available that will fail immediately. At least, you hope it will - it's conceivable that some other implementation could have a header of the same name which does something radically or subtly different. Radical differences usually result in compilation failures, for subtle differences you can test for preprocessor symbols to identify implementations.

这篇关于程序可移植性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆