我是否在某处读到过 C++/CLI 让我们走向“头文件”？ 更少的社会，比如Java
如果是这样，我在创建类时是否应该尽量减少头文件的使用？
And if so, should I be trying to keep header file use to a minimum when creating classes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 C++/CLI 项目内的类之间调用时，必须
#include。 编译器第一次遇到交叉引用。您应该在 C++/CLI 项目之间
#using引用类，而不是#include。 您现在已经超出了编译器的范围，并且托管引用已经接管。（这里有一个关于该主题的很好的讨论：MSDN 论坛）
我发现在跨越混合托管/本机世界的解决方案中有用的模式是“无实现”而不是无标头。 这对于混合 C++ 和纯托管语言的新解决方案来说最有意义，它使 C++ 代码“感觉”更像其他托管代码。 使用 编写 .h 文件
和 .cpp 文件 使用
我认为 .cpp 确实是可选的并且可以消除，尽管能够方便地使用 Ctrl+F7“仅构建此文件”。 它是否存在都会影响构建顺序。
我认为重新组织最近添加了
/clr开关的现有 C++ 项目没有意义。When calling between classes within a C++/CLI project, you have to
#include. The compiler is encountering the cross-reference for the first time .You should be
#usingref classes between C++/CLI projects, rather than#include-ing. You're now beyond the compiler and managed referencing has taken over.(Here's a good discussion on the topic: MSDN forums)
A pattern I have found useful in solutions that straddle the mixed managed/native world is to go "implementation-less" rather than headerless. This makes the most sense on new solutions that will have a mix of C++ and pure managed languages, it makes the C++ code "feel" more like the other managed code. Write .h files with
And .cpp files with
I think the .cpp is really optional and can be eliminated, though it is convenient to be able to Ctrl+F7 "build this file only." Whether or not it exists will affect build order.
I do NOT think it makes sense to re-organize existing C++ projects that have recently had the
/clrswitch added.即使 C++ 和 C++/CLI 正在走向无标头社会，您现在正在工作，您应该使用适当的习惯用法，以使您的代码可读、可维护。 在模块成为标准 C++ 和编译器实现它们之前，您将必须使用自己的代码和其他人的代码，没有理由仅仅因为在某些时候您可能会因为不同的范例而使您的大脑紧张想要/需要学习它们。
只需按照您选择的语言进行惯用操作即可，并密切关注事情的进展、进行了哪些更改以及代码在不久的将来将如何。 我不遵循 C++/CLI 的进步，而是使用普通的 C++，阅读下一个标准并尝试学习已经存在的新库 (boost 有一些，编译器 gcc /vs/comeau/英特尔 /borland 已经在不同程度上实现了 C++0x 功能）
Even if C++ and C++/CLI were moving towards a header-less society, you are working now and you should work with the idioms in place for your code to be readable, maintainable. Way before modules become standard C++ and compilers implement them you will have to work with your own code and the code of others, there is no reason to strain your brain with different paradigms just because at some point you may want/need to learn them.
Just do what is idiomatic in your language of choice and keep an eye on how things advance, what changes are made, how code will be in the near future. I do not follow the advance of C++/CLI, but with plain C++, read about the next standard and try to learn the new libraries that are already in place (boost has some of them, compilers gcc/vs/comeau/intel/borland are already implementing C++0x functionalities to a different extent)
（这可能晚了 3 年，但它仍然显示在谷歌搜索的顶部附近，并且该信息今天仍然有效，就像 3 年前一样）。
首先，是的，你是对的，对于 C++/CLI，除了本机 C++ 类、结构等之外，你不使用 .h 文件。
可能想到的第一个问题是，如果我不 <代码>#include "someheader.h" 文件？ 对此有两个答案：1）对于项目之外的课程； 2) 对于您项目内的课程。
1) 在 .VCPROJ 中添加对 .DLL（或解决方案中的另一个项目）的引用（项目属性页中的公共属性/框架和引用）。
2）添加一个
#using otherclass.obj，那就是在目标文件上#using！在您的项目中，假设每个类都有自己的源文件，当您想在另一个类中引用它时，我们使用
#using "a_compiled_file"它可以是 .dll 或 .obj 文件。在项目属性页的 C/C++ / General 下，您将看到：Resolve #using References，只需添加 MACRO 字符串
$(IntDir)。 这解析为已编译源代码的中间目录。编译器读取 .obj 文件中的元数据（就像 .dll 文件中的元数据一样）并使用它来获取所需的所有信息，无需 .h 头文件！
我们这样做是因为 C++/CLI 编译器太愚蠢了，无法像 C# 编译器那样记住同一项目中的类。
注意：使用
$(IntDir)时，您可能会遇到共享违规，在这种情况下，请预编译文件并将它们放在自己的目录中。 编译器只需要元数据，因此除非您更改类结构（想想 .h 的东西），否则不需要每次都进行编译。(This may come 3 years late, but it still shows up near the top on a google search, and the information is still valid today as it was 3 years ago).
First, yes you are correct, with C++/CLI you don't use .h files EXCEPT for native C++ classes, structures, etc.
The first question that may come to mind is how do I reference my class if I don't
#include "someheader.h"file? There are two answers to this: 1) for classes OUTSIDE your project; 2) for classes WITHIN you project.1) Add a reference to the .DLL (or to another project within the solution) in your .VCPROJ (Common Properties / Framework and References in the project property pages).
2) Add a
#using otherclass.obj, thats right #using on an object file!Within your project, assuming each class has its own source file, when you want to reference it in another class we make use of the
#using "a_compiled_file"which can be a .dll or a .obj file.In your Project Property Pages, under the C/C++ / General you will see: Resolve #using References, just add the MACRO string
$(IntDir). This resolves to the intermediate directory for compiled source code.The compiler reads the metadata within the .obj file (just like the metadata within a .dll file) and uses that for all the information it needs, no .h header file!
We do this because the C++/CLI compiler is TOO STUPID to remember our classes within the same project the way the C# compiler does.
NOTE: you may run in to sharing violations when using
$(IntDir), in which case, pre-compile the files and put them in their own directory. The compiler nedds ONLY the meta data, so unless you are changing the class structure (think of .h stuff) it doesn't need to be compiled every time.