Включая собственный заголовок C ++ из C ++ / CLI

Question

Я просто экспериментирую со смешиванием статической библиотеки C ++ (которая использует MFC) и приложения WinForms на C ++ / CLI.Когда я пытаюсь включить свой NativeClass.h, компиляция приложения C ++ / CLI завершается неудачно, потому что он не понимает AFX_EXT_CLASS, используемый для экспорта класса для библиотеки.

Просто чтобы заставить его работать, я смогчтобы собрать собственную библиотеку, затем удалите AFX_EXT_CLASS из заголовка, затем соберите C ++ / CLI, связанный с собственной библиотекой.Приложение C ++ / CLI запустится, появится диалоговое окно и выведет какое-то фиктивное значение из моего метода NativeClass :: NativeFunction ().Кажется, все работает отлично, за исключением того, что я не могу собрать приложение C ++ / CLI без удаления AFX_EXT_CLASS.Есть идеи, как заставить это работать без необходимости редактировать заголовок?Я бы предпочел пошаговую сборку.

// NativeClass.h
class AFX_EXT_CLASS NativeClass {
    public:
        NativeClass();
        ~NativeClass();

        int NativeFunction();
};

Это ошибка, которую я получаю при сборке приложения C ++ / CLI, когда AFX_EXT_CLASS находится в заголовке:

NativeClass.h(3): error C2470: 'NativeClass' : looks like a function definition, but there is no parameter list; skipping apparent body

Answer 1

Вы не получаете большую диагностику от компилятора, простая проблема в том, что он не знает, что означает AFX_EXT_CLASS.Не оставляйте это, макрос расширяется до __declspec (dllimport).Просто исправьте свою проблему, включив <afx.h>.Требуется общая версия библиотеки MFC, она будет жаловаться, если вы забудете ее выбрать.

Answer 2

Просто чтобы это заработало,

Вот диаграмма, которая поможет вам узнать, как CLR выполняет собственный код C ++:

Answer 3

Я скомпилировал и запустил его, добавив #define AFX_EXT_CLASS в stdafx.h моего приложения на C ++ / CLI. Я полагал, что поскольку приложение C ++ / CLI на самом деле не касается макроса, его не нужно беспокоить, поэтому его определение делает компилятор счастливым и, по-видимому, не вызывает каких-либо вредных последствий.

Answer 4

Не думаю, что вам нужен классификатор в этом классе. Так как ваш класс не наследует от чего бы то ни было, в этом нет необходимости. Управляемый компилятор C ++ / CLI может компилировать нативные классы под управлением #pragma, но при этом не требует, чтобы у этих нативных классов были какие-либо специальные модификаторы.

Также я бы остерегался думать, что MFC - это весь мир C ++ ... это не так. Многие люди, включая меня, компилируют множество собственных классов C ++ с включенным переключателем / clr, и мы никогда не использовали этот странный макрос AFX_EXT_CLASS.

Так что было бы неплохо попробовать небольшой автономный проект, который содержит только этот класс (без макроса) и вообще не зависит от MFC. Затем выполните компиляцию с помощью управляемого C ++ / CLI. Как только вы все заработаете, добавьте функциональность к классу постепенно, пока вы не заработаете, как вам нравится. Наконец, я думаю, вы увидите, что MFC, вероятно, имеет некоторый багаж, который вы должны выбросить, чтобы успешно работать с / clr.