Я где-то читал, что C ++ / CLI продвигает нас к обществу с «заголовочными файлами», как Java

Question

И если это так, должен ли я пытаться свести к минимуму использование файла заголовка при создании классов?

Answer 1

(Это может произойти с опозданием на 3 года, но оно все еще отображается в верхней части поиска Google, и информация по-прежнему действительна сегодня, как и 3 года назад).

Во-первых, да, вы правы, в C ++ / CLI вы не используете файлы .h, КРОМЕ для собственных классов C ++, структур и т. Д.

Первый вопрос, который может возникнуть, - как мне сослаться на мой класс, если я не #include "someheader.h" файл? Есть два ответа на это: 1) для классов вне вашего проекта; 2) для занятий в рамках вашего проекта.

1) Добавьте ссылку на .DLL (или на другой проект в решении) в вашем .VCPROJ (Общие свойства / структура и ссылки на страницах свойств проекта).

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), его не нужно каждый раз компилировать.

Answer 2

При вызове между классами в проекте C ++ / CLI необходимо #include. Компилятор впервые сталкивается с перекрестной ссылкой.

Вы должны быть #using ref классы между C ++ / CLI проектами, а не #include -ing. Вы вышли за пределы компилятора, и управление ссылками вступило во владение.

(Вот хорошая дискуссия по теме: Форумы MSDN )

Шаблон, который я нашел полезным в решениях, которые охватывают смешанный управляемый / нативный мир, заключается в том, чтобы перейти «без реализации», а не без заголовка. Это больше всего подходит для новых решений, которые будут иметь смесь C ++ и чисто управляемых языков, и это делает код C ++ более похожим на другой управляемый код. Напишите .h файлы с

// MyClass.h header file

#pragma once

// full class implementation

и .cpp файлы с

#include "MyClass.h"
// nothing else

Я думаю, что .cpp действительно необязателен и его можно исключить, хотя удобно иметь возможность Ctrl + F7 «создать только этот файл». Будет ли он существовать, повлияет на порядок сборки.

Я не думаю, что имеет смысл реорганизовывать существующие проекты C ++, в которые недавно был добавлен переключатель /clr.

Answer 3

Даже если C ++ и C ++ / CLI движутся к обществу без заголовков , вы работаете сейчас, и вам следует поработать над имеющимися идиомами, чтобы ваш код был читабельным и поддерживаемым. Задолго до того, как модули станут стандартом C ++, и компиляторы реализуют их, вам придется работать со своим собственным кодом и кодом других, нет причин напрягать свой мозг различными парадигмами только потому, что в какой-то момент вы можете захотеть / нужно учить их.

Просто делайте то, что идиоматично на выбранном вами языке, и следите за тем, как все продвигается, какие изменения вносятся, каким будет код в ближайшем будущем. Я не слежу за продвижением C ++ / CLI, но с простым C ++ прочитал о следующем стандарте и попытался изучить новые библиотеки, которые уже есть ( boost имеет некоторые из них, компиляторы gcc / vs / comeau / intel / borland уже реализует функции C ++ 0x в разной степени)