可以在Mac OS X或Linux上编译并运行Visual C ++程序吗?

问题描述

…如果可以，怎么办?

… and if so, how?

具体地说，我想编译并运行 wavdiff .据我所知(这不是很远，因为我是C ++的新手)，它是使用MS Visual C ++或类似软件创建的.

Specifically, I'd like to compile and run wavdiff on Mac OS X Snow Leopard 10.6.8. As far as I can tell (which isn't very far, since I'm a total novice at C++), this was created with MS Visual C++ or similar.

对于能解决在Mac OS X或Linux上编译Visual C ++程序的一般情况，并能解决上述特定挑战的问题，我将不胜感激.

I'd be most grateful for answers that address the general case of compiling Visual C++ programs on Mac OS X or Linux, and that also address the specific challenge above.

推荐答案

C ++语言是可移植的.从理论上讲，C ++源代码可以编译为可在任何平台上运行.

The C++ language is portable. In theory, C++ source code can be compiled to run on any platform.

但是，有一些警告需要注意:

However, there are a few caveats to be aware of:

• 行为在不同平台上可能有所不同. C ++标准留下了许多由实现定义的内容，这意味着它取决于各个平台和编译器的行为方式.例如，常见数据类型的大小在不同平台之间可以(并且将会)变化. long在64位Linux上通常为64位宽，但在64位Windows上只有32位宽. wchar_t在Windows上为16位宽，但在Linux上通常为32位宽.因此，如果您的代码对实现定义的行为进行了假设，则它可能不是可移植的(经典示例是假定指针可以存储在int或unsigned int中的代码.这在32位计算机上很有效，但是在64位上，您最终尝试将64位数据存储到32位宽的对象中.
• 即使您的代码是可移植的，您的依存关系也可能不是.最明显的例子当然是OS API.使用Win32 API的代码将无法在不可用的平台(Windows以外的任何平台)上编译.如果不可用，则依赖POSIX API的代码将无法编译(Windows支持某些POSIX API，但远非全部).
• C ++可能具有许多不同的含义.有一种可移植的ISO标准化语言，然后是各个编译器都可以理解的方言. Visual C ++，GCC和任何其他主要的C ++编译器都允许使用一组语言扩展，这些语言扩展不是标准的一部分，并且可能不允许在其他编译器上使用.如果您的代码依赖于这些代码，则可能无法使用其他编译器进行编译. (例如，Visual C ++允许将非const引用绑定到一个严格不允许的临时对象，而其他编译器将拒绝它.默认情况下，GCC允许在堆栈上分配动态大小的数组，这也是一个非标准扩展名，其他编译器将拒绝该扩展名.)

• behavior might be different on different platforms. The C++ standard leaves many things implementation-defined, which means that it's up to the individual platform and compiler how it should behave. For example, the size of common data types can (and will) vary across different platforms. A long is typically 64 bits wide on 64-bit Linux, but only 32-bit on 64-bit Windows. A wchar_t is 16 bits wide on Windows, but typically 32 bits on Linux. So if your code makes assumptions about implementation-defined behavior, it might not be portable (a classic example is code which assumes that a pointer can be stored into an int or unsigned int. That works great on a 32-bit machine, but on 64-bit, you end up trying to store 64 bits of data into a 32 bit wide object.
• even if your code is portable, your dependencies may not be. The most obvious example is of course the OS APIs. Code which uses the Win32 API won't compile on platforms where it's not available (anywhere other than Windows). Code which relies on POSIX APIs won't compile if that's not available (Windows supports some POSIX APIs, but far from all).
• C++ can mean a lot of different things. There's the ISO standardized language, which is portable, and then there's the dialect understood by individual compilers. Visual C++, GCC, and any other major C++ compiler, allow a set of language extensions which aren't part of the standard, and may not be allowed on a different compiler. If your code relies on those, it may not compile using other compilers. (For example, Visual C++ allows a non-const reference to bind to a temporary, which isn't strictly speaking allowed, and other compilers will reject it. GCC by default allows dynamically sized arrays allocated on the stack, which, again, is a non-standard extension, and which other compilers will reject.)

所以，这实际上取决于代码.干净，高质量的代码往往可以轻而易举地移植.当然，除了直接依赖于OS服务的部分外，这些部分必须针对不同的OS进行重写(或者在可以使用跨平台包装器/库的情况下，这些包装器/库可用于以可移植的方式完成相同的操作)

So it depends on the code, really. Clean, high-quality code tends to be portable with little trouble. Except of course for the parts that rely directly on OS services, which will have to be rewritten for a different OS (or where a cross-platform wrapper/library may be available which can be used to do the same thing in a portable manner)

这篇关于可以在Mac OS X或Linux上编译并运行Visual C ++程序吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！