Did I read somewhere that C++/CLI moves us towards a "header-file" less society, like Java.

Question

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

Answer 1

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)

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