Что это значит, когда вы получаете сообщение об ошибке компиляции «похоже на определение функции» для объявления класса?

Question

Я недавно столкнулся с этой проблемой. Я нашел много случаев, когда люди задавали здесь вопрос - , например - но конкретных ответов не было.

Вот пример кода, поднятого по этой ссылке:

class AFX_BASE_APPLICATION_APP_CLASS CFileExtension 
{
public:
   CFileExtension ();           
   virtual ~CFileExtension ();
};

Сгенерированная ошибка:

c:\FileExtension.h(14) : error C2470: 'CFileExtension' : looks like a function definition, but there is no formal parameter list; skipping apparent body

Answer 1

Вы почти наверняка пропустили заголовок, который определяет AFX_BASE_APPLICATION_APP_CLASS. В этом случае он будет пропущен без изменений, и VC ++ будет считать, что CFileExtension - это функция, которая возвращает class AFX_BASE_APPLICATION_APP_CLASS.

И, поскольку он думает, что это функция, ему также нужны скобки.

Вам просто нужно найти, где определено AFX_BASE_APPLICATION_APP_CLASS и #include этот файл.

Answer 2

Я столкнулся с той же ошибкой компилятора. Проблема была в пропущенном двоеточии

Мой код был что-то вроде:

int MyClass:doSomething() {

}

Это должно было быть: (Примечание '::' вместо ':'

int MyClass::doSomething() {

}

Answer 3

... и ответ, так как мне не удавалось сделать логин для любого из этих форумов, но у меня уже был OpenID: -)

В моем случае (и, вероятно, во всех найденных мной) проблема заключалась в том, что мне не хватало #include для файла заголовка, который содержал определение макроса, предшествующего имени класса. Макрос, скорее всего, используется как способ переключения конфигурации сборки для включения __declspec (dllexport).

Я обнаружил это, войдя в свойства проекта, "C / C ++" | Препроцессор и включение «Генерировать предварительно обработанный файл». Когда я посмотрел на предварительно обработанный вывод, я обнаружил, что макрос был дословно включен, а не расширен.

Answer 4

просто определите AFX_BASE_APPLICATION_APP_CLASS

Answer 5

У меня была такая же проблема, и ни одно из решений не сработало. Проблема, описанная в ОП, исходила от включения класса:

class AFX_EXT_CLASS CMyClass : public CObject
{
public  :
// ....
}

Это был класс экспорта из библиотеки DLL, который я хочу использовать в консоли exe. Если я создаю консольное приложение как 'using mfc' в мастере создания, то это Ошибка не произошла, но эта опция приводит к созданию другой структуры приложения.

В любом случае я пытался включить различные заголовки, чтобы он знал AFX_EXT_CLASS, определил его, но ничего не получалось. Короче говоря, решение состоит в том, что мы должны разрешить использовать MFC для приложения, чтобы оно понимало экспортированный класс MFC из dll. Как мы это делаем, редактируя файл .vcproj и вставляя строку UseOfMFC="2", как показано ниже:

<Configurations>
    <Configuration
        Name="Debug|Win32"
        OutputDirectory="$(SolutionDir)$(ConfigurationName)"
        IntermediateDirectory="$(ConfigurationName)"
        ConfigurationType="1"
        UseOfMFC="2" <-------------Insert this line here
        CharacterSet="1"

Также #include <afx.h> в stdafx.h (я включил его справа вверху перед первым включением).

Теперь отпустите, очистите и соберите ошибку, которая должна исчезнуть.

Не было другого способа изменить эту опцию из настроек проекта. Этот параметр отличается от Свойства проекта >> Свойства конфигурации >> Общие >> «Использование MFC» .

Обновление

Трюк UseOfMFC="2" может быть полезен в другом месте, но, очевидно, если вы просто #include <afx.h> И измените настройки project properties >> General >> 'Use of MFC' на Использование MFC в shared dll, эта ошибка исчезнет. Если вы не измените более поздние настройки, произойдет ошибка компилятора

c:\program files (x86)\microsoft visual studio 8\vc\atlmfc\include\afx.h(24) : fatal error C1189: #error :  Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]

Изменение этого значения также устанавливает UseOfMFC="2" в файле проекта, так что это правильный путь.

Answer 6

Другая возможная причина - использование __declspec (dllimport) вместо __declspec (dllexport) или вообще отсутствие declspec в качестве префикса класса / функции в Visual C ++.

Если вы все перепутаете, ваш класс также может быть не распознан как таковой, и вы получите ту же ошибку.