C мигрирует на C ++ (встроенный)

У меня есть проект в чистой C-й библиотеке usb, и мне нужно перенести его на c ++ и изменить те же структуры на классы. Я удалил все c ++ «защиты», такие как:

#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif

Я изменил все расширения файлов с .c в .cpp (кроме библиотеки HAL).
Я понял что с ++ .hex на 7 КБ меньше, чем с .hex, Когда я посмотрел в .map Файл, который я видел, что многие функции отсутствуют. я думал так staticфункции вызвали это, но удаление static ключевое слово не помогло. Кто-нибудь знает, что может привести к тому, что некоторые функции не были скомпилированы. Когда расширения .c Все отлично.

1

Решение

Функции C ++ получают разные сигнатуры, чем функции C. Поскольку вы потеряли функциональность, а код стал намного меньше, вполне вероятно, что функция, требующая связывания C, компилируется как C ++, а несовпадение сигнатур мешает правильному связыванию.

Вероятное место для этого — таблица векторов прерываний. Если функция обработчика скомпилирована с помощью связи C ++, адрес обработчика не превратится в таблицу, скомпилированную с C.

Дважды проверьте векторы прерываний и убедитесь, что они ссылаются на правильные функции. Если они верны, проверьте любой другой код, скомпилированный с C, который может ссылаться на внешний символ, скомпилированный с C ++.

1

Другие решения

Я могу думать о двух основных причинах:

  1. Встраивание. Компилятор может решить, что нет необходимости выдавать функцию как отдельную функцию, если все использования могут быть встроены.
  2. Неиспользуемый код Компилятор может увидеть, что функция нигде не используется в вашем коде, и принять решение исключить ее из конечного результата.

Если результат будет использоваться в качестве библиотеки, то, что ваша среда вызывает определенные функции без явного вызова в вашем собственном коде, я думаю, что лучший способ — это скомпилировать и связать ваш код как библиотеку (возможно, динамическую библиотеку) и экспортировать эти функции как интерфейс библиотеки (видимость в gcc, dllexport в MSVC) заставят компилятор / компоновщик включить их в создаваемый двоичный файл, даже если они не понимают, зачем они нужны прямо сейчас.
(Конечно, это дикая догадка о вашей целевой среде.)

Другой вариант — отключить определенные оптимизации компилятора / компоновщика для удаления мертвого кода и принудительного создания экземпляра автономной функции для встроенных функций, но я думаю, что это очень косвенный подход, имеющий более широкий эффект и впоследствии может усложнить обслуживание.

2

По вопросам рекламы [email protected]