Did I read somewhere that C++/CLI moves us towards

问题:

And if so, should I be trying to keep header file use to a minimum when creating classes?

回答1:

(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.

回答2:

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 #using ref 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

// MyClass.h header file

#pragma once

// full class implementation

And .cpp files with

#include "MyClass.h"
// nothing else

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 /clr switch added.

回答3:

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)