3

Putting all aesthetic considerations aside... Which alternative is preferrable? My main concerns are build times, keeping the code readable and easy to mantain, and of course, that it compiles.

I've seen most books define everything in a .cpp file, a la C#, but... Won't that worsen build time? Ok, it might well be that unmanaged C++ rationale doesn't work with managed C++/CLI, BUT please consider a transition scenario: An unmanaged C++'s projects classes are moved into a C++/CLI project, and the whole monster builds OK, and sits there waiting for a brave guy (me, ahem) to translate the unmanaged classes to managed ones, gradually and with a backing test harness, of course.

I digressed a little, but I wanted you to consider my unusual situation (managed and unmanaged interaction) when answering.

dario_ramos
  • 7,118
  • 9
  • 61
  • 108

1 Answers1

5

A .h file is an artifact of the pre-processor. By the time the compiler starts to compile the code, it is just all one big wad of code. The use of .h files is greatly diminished in C++/CLI, you no longer need it to make declarations available to other modules. In managed code, the metadata in an assembly provides them.

C++/CLI retains the build model of C++, it compiles one source code file at a time and needs a linker to glue the code together. You may still need .h files if you have the C++/CLI code for one project spread across multiple source code files.

So, use .h files only when you need them. Advice that's no different for native projects.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536