开发者

Can a Visual C++ program be compiled and run on Mac OS X or Linux?

开发者 https://www.devze.com 2023-04-06 22:21 出处:网络
… and if so, how? Specific开发者_JS百科ally, 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++

… and if so, how?

Specific开发者_JS百科ally, 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.

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.


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:

  • 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.)

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)


This program can not be easily ported (recompiled without source changes). At least not without changes to the source. It holds dependencies to Windows libraries and is tied to Windows API in certain parts.

The problem is not that it's coded in VC++, but that it has these dependencies. A program that is coded such that it has no platform-dependencies can be easily ported in a lot of cases by just recompiling on the target platform or with a switch to target a different platform.


Based just on this source file, it looks as if the code itself might be reasonably portable C++. The question is whether it (or any of the classes it uses) makes use of Windows APIs that won't exist on those other platforms. The bet you can do is ask the authors what they think, or just give it a try.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号