C++定义接口
#define interface class
（这里有更多 - http://www.codeproject.com/KB/cpp/CppInterfaces。 aspx ）
这有意义吗？这是否澄清了接口和实现它们的类之间的区别？或者这很令人困惑，因为很明显纯虚拟类是接口？
你用它吗？或者“宏是邪恶的”？
#define interface class
(here is more - http://www.codeproject.com/KB/cpp/CppInterfaces.aspx )
Does that make sense? Does this clarify the difference between interfaces and implementing them classes? Or it's confusing, because it's obvious that pure virtual classes are interfaces?
Do you use it? or "macros are evil"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我想说这没有意义。那篇文章中提出的“解决方案”看起来一团糟——按原样使用 C++ 有什么问题吗？当你需要一个纯抽象类并完成它时就可以定义一个纯抽象类，为什么要引入一些蹩脚的宏呢？
看起来像一个具有 C#/Java 背景的人试图在 C++ 中找到自己的出路，但却迷失了方向。当真正熟悉 C++ 的开发人员遇到它时，它只会引入错误和混乱。
I'd say it makes no sense. The "solution" proposed in that article looks like a horrible mess - what's wrong with using C++ as it is? Why introduce some crappy macros when you can just define a pure abstract class when you need one and be done with it?
It looks like someone with C#/Java background was trying to find his way in C++ and got lost. It would only introduce bugs and confusion when encountered by developers actually familiar with C++.
像这样的宏是邪恶的，因为它隐藏了真实的语言，如果你不知道其中的秘密，就很难辨别出来。
定义接口的更好方法是使用通用约定，例如使用“I”作为第一个字符来命名它们。
A macro such as this is evil, because it hides the true language behind a facade that is not easily discerned if you don't know the secret.
A better way of defining interfaces is to use a common convention such as naming them with an "I" as the first character.
我真的不建议使用这些技巧，我认为smartass。宏并不是邪恶的，但是如果有人包含您的代码并使用
interface作为变量名（为什么不呢？），为什么他/她必须花费 1 小时进行调试gcc -E因为有人认为“接口”（不是 C++）会更聪明？我不喜欢那样。
I really don't suggest to use these tricks, I consider smartass. Macros are not evil, but if someone includes your code and uses
interfaceas a variable name (why not?), why does he/she have to spend 1 hour debugging withgcc -Ebecause someone decided "interface" (which is not C++) would be smarter?I dislike that.
C++ 从业者已经想出了有用的惯用的做事方式。这些习语成为其他实践者理解并轻松使用的通用方言的一部分。
你在街上雇佣的 C++ 程序员会知道，具有所有纯虚方法且没有实现的基类是一个接口。他们会知道它的公共继承意味着它实现了该接口。他们不会知道那篇文章中指定的疯狂宏语言。
我还要补充一点，习语在 C++ 中尤其重要，因为如果你不小心的话，你可能会被吓到。事实上，C++ 中常用的习惯用法可能是 C++ 最强大的功能。
C++ practitioners have come up with useful idiomatic ways of doing things. These idioms become part of the general, common dialect that other practitioners understand and easily work with.
The C++ programmer you hire off the street will know that a base class with all pure virtual methods and no implementation is an interface. They will know that public inheritance from it means its implementing that interface. They won't know the crazy macro language specified in that article.
I'd also add that idioms are especially important in C++ due to the ability to really shoot your foot off if you're not careful. In fact the generally used idioms in C++ may be C++'s most powerful feature.
我永远不会重新定义或替换现有的关键字 - 它只会导致除了作者之外的所有人的困惑......
I would never redefine or replace an existing keyword - it only leads to confusion by everyone but the author...
这很糟糕。我永远不会使用它。
按照惯例：C/C++ 中的定义通常全部采用大写字母，以使任何读者都清楚它是一个定义，并避免与函数或变量名称发生名称冲突。
实际上：“接口”是一个非常常见的名称，仅在此基础上使用它就会很危险。但是，当然，您可以使名称更加明显，例如 MY_PLATFORM_INTERFACE 或类似的名称。
从哲学上来说：这显然是一次蹩脚的尝试，旨在将 C++ 转变为更纯粹的 OOP 语言（如 Java 或 C#），并试图以某种方式让 Java/C# 世界的新手更熟悉 C++ 语法。编程语言就是这样。如果您希望进行深刻的改变，请向标准委员会提出申诉，并准备好提供强有力的证据。我认为对语法进行如此小的改变是荒谬的。我不认为任何人都无法转向C++，因为他无法习惯C++中不存在interface关键字的想法。
惯用语是：当您使用 C++ 编程时，您应该期望 C++ 程序员查看或审查您的代码。如果您引入类似的东西，可能看起来像是一个晦涩的 C++ 编译器特定扩展，那么您可能会抛弃真正的 C++ 程序员，他可能会花费宝贵的时间来思考使用什么编译器或扩展来启用此“接口”关键字。尽可能坚持 C++ 惯用语法。否则，您必须在每次使用“interface”旁边注释该关键字只是“class”的定义，在这种情况下，您不妨只注释该类是一个接口的类声明，并且只需像平常一样使用“class”关键字即可。
It is bad. I wouldn't use it, ever.
Conventionally: Defines in C/C++ are typically all in capital letters to make it obvious to any reader that it is a define, and to avoid name-clashes with function or variable names.
Practically: It is a very common name "interface" and this use of it will be dangerous just on that basis. But, of course, you could make the name more distinct, e.g., MY_PLATFORM_INTERFACE or something like that.
Philosophically: This is clearly a lame attempt at turning C++ into a more purist OOP language like Java or C#, and trying to somehow make the C++ syntax more familiar to newcomers from the Java/C# world. A programming language is what it is. If you want deep changes to be made, appeal to the standard committee, and be prepared to provide strong evidence. I think that such a small change to the syntax is ridiculous. I don't think anyone would not be able to switch to C++ because he can't get used to the idea that the interface keyword doesn't exist in C++.
Idiomatically: When you program in C++, you should expect C++ programmers to look at or review your code. If you introduce a thing like that that could look like an obscure compiler-specific extension of C++, you might throw a real C++ programmer off and he might spend his precious time wondering what compiler or extension is used that enables this "interface" keyword. Stick to C++ idiomatic syntax whenever possible. Otherwise, you will have to comment, next to every use of "interface", that this keyword is just a define for "class", in which case, you might as well just comment on the class declaration that this class is an interface and just use the "class" keyword as you normally would.
我不明白这样做的意义。它如何帮助开发人员提高代码的可读性？或者甚至避免让它变得更加晦涩难懂？
最好使用类命名约定，例如
IClassName，它应该是清晰的，不会混淆开发人员的代码。I don't get the point of doing this. How does it help make the code more readable to developers? Or even avoiding making it more obscure?
Better to use a class naming convention such as
IClassName, that should be clear without obfuscating the code from developers working on it.考虑
使用 Visual C++ 关键字 __interface相反，并像这样编写您的#define：
同时为您的接口类添加前缀“I”，以提高清晰度，如 @jonathan-wood 建议的那样。
使用这种方法，您可以在 Visual Studio 下获得对接口模式的真正编译器支持，并且所有内容仍然可以顺利地跨平台编译。由于双下划线，您还可以避免@gd1提到的符号命名冲突的潜在问题。
Instead of
Consider using the Visual C++ keyword __interface instead, and write your #define like this:
Also prefix your interface classes with the conventional "I" for additional clarity as @jonathan-wood suggested.
Using this approach, you get true compiler support for the interface pattern under Visual Studio, and everything still compiles happily cross-platform. Because of the double underscore, you also avoid the potential problem of symbol naming collision mentioned by @gd1.