一个Visual C++程序能否在Mac OS X或Linux上编译和运行？

Question

一个Visual C++程序能否在Mac OS X或Linux上编译和运行？

c++macosvisual-c++osx-snow-leopard

4

...如果是这样，该怎么做呢？

具体来说，我想在Mac OS X Snow Leopard 10.6.8上编译和运行wavdiff。据我所知（由于我对C ++完全是个新手），它是使用MS Visual C ++或类似软件创建的。

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

- user82216

4

“Visual C++ 程序”并不存在，因为并没有叫做 Visual C++ 的编程语言。 - user405725

11

抱歉Vlad，但这是最无用和有失傲慢的评论。那个人承认自己在C ++方面是新手 - 你不需要用那样的评论来突出一个易受攻击的目标。这就像踩金鱼一样，很不好。 - sashang

从技术上讲......它有足够的供应商特定更改，使其几乎成为一种独立的语言。 - Blindy

3

@Vlad Lazarenko，你的回答完全没有用而且很粗鲁。 - MGZero

5

@VladLazarenko，通过“Visual C++程序”，我指的是使用MS Visual C++创建的程序。我不是指用一种名为Visual C++的编程语言编写的程序。我认为这从我的问题中相当清楚，但如果对您不清楚，我很抱歉。感谢上面其他评论者理解我的意图。 - user82216

3个回答

3

这个程序不容易进行移植（重新编译而无需源代码更改）。至少在没有对源代码进行更改的情况下是不可能的。它依赖于Windows库，并且在某些部分与Windows API相关联。

问题不在于它是用VC++编写的，而在于它有这些依赖项。如果一个程序被编码为没有平台依赖性，那么在很多情况下只需要在目标平台上重新编译或使用切换来针对不同平台即可轻松移植。

- Mike Kwan

2

仅从这个源文件来看，代码本身似乎是相当可移植的C ++。问题是它（或任何它使用的类）是否使用了其他平台上不存在的Windows API。你可以问作者他们的想法，或者尝试一下。

- Ernest Friedman-Hill

感谢您的帮助！在发布我的问题之前，我下载了包含wavdiff.cpp的ZIP文件，并在终端窗口中运行了“c++ wavdiff.cpp”。这导致出现错误，包括“source/wav_source.h：没有那个文件或目录”和“‘printf’在此范围内未声明”。当您说“试一试”时，您是否考虑到了这种情况，还是我应该采取不同的方法？ - user82216

1

它相当具有可移植性，大约5分钟后我几乎编译成功了。c++ -I ../valib/valib wavdiff.cpp $(ls ../valib/valib/.cpp | grep -v vtime.cpp) $(ls ../valib/valib/{filters,dsp,fir,parsers,sink,source}/.cpp | grep -v dsound | grep -v dshow) 会留下一些链接错误，但再花大约30分钟左右就能得到更好的结果。 - Anya Shenanigans

@Petesh，感谢您尝试使用wavdiff.cpp。我可以问一下您使用的平台是什么吗？在我的OS X 10.6.8系统上，您给出的命令根本没有产生新文件，所以我猜它并没有成功编译。 - user82216

1

它在最后一步链接失败了。因为它是一个单片式编译行（即一堆.cpp文件），它不会保留中间文件。当c++命令完成时，如果你得到一个名为a.out的文件，那么它编译成功了——a.out文件就是wavdiff二进制文件。如果你使用c++ -o wavdiff，它将生成一个名为wavdiff的文件。 - Anya Shenanigans

我没有得到一个名为a.out的文件：实际上根本没有新文件被创建。但是无论如何，还是谢谢你让我更接近解决问题 :) - user82216

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jalf · Accepted Answer

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

然而，有几个需要注意的问题：

不同平台上的行为可能会有所不同。C++标准留下了很多实现定义的东西，这意味着个体平台和编译器会决定它的行为。例如，常见数据类型的大小在不同平台上可能会变化。在64位Linux上，long通常有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++允许非const引用绑定到临时变量，这不是严格允许的，其他编译器会拒绝。GCC默认允许在堆栈上分配动态大小的数组，这又是一种非标准扩展，其他编译器将拒绝。）

所以，这真的取决于代码。干净、高质量的代码通常很容易实现可移植性。当然，直接依赖于操作系统服务的部分必须为不同的操作系统重新编写（或者可以使用跨平台封装/库，在可移植的方式下完成相同的事情）。