objective-c - 使用 .mm 文件而不是 .m 以防万一我以后使用 C++ 是个坏主意吗？

Question

假设我正在使用 Apple 最新的 Xcode 工具开发典型的 Mac 或 iOS 应用程序。进一步假设我主要使用 Objective-C 开发此应用程序并利用来自 Apple 的 Cocoa 或 Cocoa Touch 框架的所有相关 API。

假设我目前没有任何计划在我的代码库中使用 C++ 或 Objective-C++，但我怀疑在未来的某个时间我可能想要稍微洒点Objective-C++ 在这里和那里。

所以我正在考虑将我所有的 .m 文件命名为 .mm，以防万一。 (这将在我的 SCM 系统中产生更清晰的历史记录的理想效果，因为我以后不必重命名文件。)

这是个坏主意吗？当文件实际上不包含任何 Objective-C++ 时，使用 .mm 文件肯定或明显比使用 .m 差有什么原因吗？

据推测，此文件扩展名会触发编译器中的某个开关，编译器将不仅要解析 ObjC 的源代码，还要解析 C++ 的源代码。这对中型到大型代码库的构建时间是否有显着的负面影响？

我应该记住它有任何其他负面(或正面)影响吗？

注意:请不要回应任何关于 ObjC 或 C++ 哪个更好的评论。这不是这个问题的目的。

Answer 1

这不是最坏的主意，但也不是真正的好主意。

Objective-C++ 的主要目的是充当需要使用 C++ 库的 Objective-C 代码的桥梁。因此，在大多数项目中，几乎所有代码都是普通的旧 Objective-C，可能有几个 .mm 文件来创建一个“包装器”对象来与 C++ 库对话。

因此，您极不可能需要将代码的重要部分从 Objective-C 更改为 Objective-C++。您的 SCM 历史记录中不应该有很多文件重命名。

在任何地方使用 Objective-C++ 的主要问题是你将走“少有人走的路”:你阅读的教程和你使用和学习的开源代码中的 99% 都将编写成由Obj-C 编译器。使用 Obj-C++ 编译器大体上是相同的，并且在大多数情况下可能不会有什么不同，但是您最终会遇到一些问题，这是由于 Obj-C++ 的编译略有不同，但是当您发现bug 它不会很明显，并且您会花费大量时间尝试诊断它，然后才意识到这是因为您使用的是经过良好测试的编译器设置。

如果您有丰富的 C++ 经验并发现自己在代码中“需要”C++ 的特性，您可能并不真正需要它们，您可能需要多花一点时间弄清楚如何在 Objective-C 。入乡随俗。

一般来说，“以防万一”并不是偏离标准做法的好理由。您通常会在不需要的事情上花费大量精力。