У меня есть ситуация, когда мне нужно документировать подпись bsearch () в Doxygen. Эта подпись выглядит так:
void * __cdecl bsearch (
const void *key,
const void *base,
size_t num,
size_t width,
int(__cdecl *compare)(const void *, const void *)
)
У меня проблема в том, как составить команду @param для указателя * сравнения, так как Doxygen жалуетсяАргумент ‘сравнить’ команды @param не найден в списке аргументов bsearch«на все, что я бросаю на это.
Это отдельная реализация, поэтому она не зависит от сигнатуры библиотеки, однако я думаю, что если бы я это сделал:
typedef int(__cdecl *pcompare)(const void *, const void *);
изменив сигнатуру на pcompare, сравните, что у вызывающих, использующих стандартную сигнатуру, возникла бы проблема с типом.
Я открыт для ЛЮБОГО решения, которое позволяет мне документировать это без тревоги от Doxygen.
Однако я думаю, если бы я сделал:
typedef int(__cdecl *pcompare)(const void *, const void *);
изменение подписи на
pcompare compare
что у вызывающих, использующих стандартную подпись, будет проблема с типом.
Вы должны были попробовать это, прежде чем сдаться. typedef
не определяет новый тип, он просто создает новый идентификатор для сложного типа. Полученные подписи идентичны.
Будьте осторожны, потому что ни одна из показанных форм не является правильной подписью. Чтобы объявить функцию библиотеки времени выполнения C, например bsearch
тебе нужно extern "C"
, (как и указатель на функцию typedef — языковая связь является частью типа функции)
Все это говорит, просто установка __cdecl
поскольку предопределенного макроса в вашей конфигурации doxygen, вероятно, будет достаточно, чтобы он мог проанализировать все эти варианты, в том числе со сложным набором токенов, определяющих тип параметра.
Там нет проблем с typedef.
Вы должны использовать это в любом случае — это яснее читать.