当前位置：文江博客话题详情

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

发布于 2024-12-06 00:16:41 字数 326 浏览 2 评论 0原文

……如果是这样，怎么办？

具体来说，我想编译并运行 wavdiff< /a> 在 Mac OS X Snow Leopard 10.6.8 上。据我所知（这并不是很远，因为我在 C++ 方面完全是新手），这是用 MS Visual C++ 或类似工具创建的。

我将非常感谢能够解决在 Mac OS X 或 Linux 上编译 Visual C++ 程序的一般情况以及解决上述特定挑战的答案。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

哑 2024-12-13 00:16:41

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

但是，有一些注意事项需要注意：

不同平台上的行为可能有所不同。 C++ 标准留下了许多实现定义的东西，这意味着它的行为方式取决于各个平台和编译器。例如，常见数据类型的大小可能（并且将会）在不同平台上有所不同。 long 在 64 位 Linux 上通常为 64 位宽，但在 64 位 Windows 上仅为 32 位。 wchar_t 在 Windows 上为 16 位宽，但在 Linux 上通常为 32 位。因此，如果您的代码对实现定义的行为做出假设，则它可能不可移植（一个典型的示例是假设指针可以存储到 int 或 unsigned int 中的代码>. 这在 32 位机器上效果很好，但在 64 位机器上，
即使您的代码是可移植的，您最终也会尝试将 64 位数据存储到一个 32 位宽的对象中，但您的依赖性可能不是最大的。明显的例子当然是操作系统API。使用 Win32 API 的代码将无法在不可用的平台上编译（Windows 以外的任何地方）。如果不可用，则依赖于 POSIX API 的代码将无法编译（Windows 支持某些 POSIX API，但远非全部）。。
C++ 可以有很多不同的含义，有可移植的 ISO 标准化语言，还有 Visual C++、GCC 和任何其他主要 C++ 编译器可以理解的方言一组不属于标准的语言扩展，并且可能不允许在不同的编译器上使用。如果您的代码依赖于这些，它可能无法使用其他编译器进行编译。（例如，Visual C++ 允许非常量引用绑定到临时变量，严格来说这是不允许的，其他编译器会拒绝它。GCC 默认情况下允许在堆栈上分配动态大小的数组，这又是非标准扩展，其他编译器将拒绝。）

所以这实际上取决于代码。干净、高质量的代码往往可以轻松移植。当然，直接依赖于操作系统服务的部分除外，这些部分必须针对不同的操作系统进行重写（或者可能有跨平台包装器/库，可以用于以可移植的方式执行相同的操作）

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)

回复收藏 0 原文