Совместное использование *.сpp файлов и *.c, Не компилируются совместно файлы Си и Си++ Опции

[kolobochishe]

Вот такая ошибка при вызове функции написанной в *.cpp файле из *.с файла

Linking
Error[Li005]: no definition for "plot_spectrum" [referenced from C:\ÐÀÁÎÒÀ\ÐÀÇÐÀÁÎÒÊÈ\ÏÐÎÅÊÒÛ\ÄÐÀÊÎÍ\Ðåãèñòðàòîðû\Ïðîøèâêà\
LPC3250 GUI_RTOS\arm\PowerPac\BoardSupport\NXP\LPC3250\Output\LPC3250\Debug_SDRAM\Obj\DRAGON_BS1_GUI.o]
Error while running Linker

Функция объявлена в соответствующем *.h файле. Он подключен везде, где требуется.

[dxp]

Не было времени сегодня искать пример,
щас попробую его описать.
Процессор работает на чатоте 14 Мгц
обменивается с другим процом на частоте 1Мгц.
На асме около 70 строк кода обработчика прерывания.
На С примерно в два раза больше.
Программа на С работает на пределе.
Но не сбоит.
Даже не представляю как это будет работать на С++.
Да...вся программа умещается во внутренней памяти DSP.

И где тут пример? Привели какие-то общие фразы, дескать, тут быстрее, тут медленее, а С++ тут вообще в пролёте. Где аргументы? Где доказательства? Реальный пример давайте. Например, вот написали протокол обмена по UART на С++, оказалось в два раза медленнее, чем на С. Вот и давайте оба варианта (на С и на С++) в студию. Это будет пример, который можно обсуждать.

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи.

Подход а-ля Александреску характерен для научных работ - давайте на бумаге/модели получим, хоть какой-то результат и потом подумаем, что дальше делать. У инженеров в сложных случаях тоже есть понятие НИОКР, но это именно заранее запланированный этап.

Насчёт Александреску вынужден не согласиться. У него показаны приёмы, как сделать написание кода более удобным и безопасным. Это, конечно, требует труда вникать (например, списки типов я так до конца и не вкурил - хоть и интересно, но актуальности пока нет и не предвидится, хотя имею в виду). Но у него помимо "тяжёлых" вещей вроде разработки на основе стратегий, немало просто полезных фишек вроде "распознавания конвертируемости и наследования на этапе компиляции". Конечно, подобные приёмы возникли от недостатка соответствующих средств в самом языке, но само решение очень красиво и, главное, в отличие от typeof(), выполняется на этапе компиляции. Или его менеджер памяти, который оптимизирован (скорость и компактность) для работы небольшими (десятки байт) объектами. Для AVR, конечно, не пойдёт, но на каком-нить АРМе уже вполне может оказаться кстати.

Вообще, Александреску представляет очень интересный взгляд на хорошо известные штатные языковые средства, и взгляд этот у него очень нестандартен. Даже если не подсаживаться на эти приёмы, поизучать (даже просто прочитать на разок) оказывается очень нелишним. Достойное чтиво и неплохая разминка для мозгов.

[zltigo]

Насчёт Александреску вынужден не согласиться......

Я не об этом - он реально занимается решением ДРУГИХ задач и выхватывать из его книг какие-то слова, например, о вреде преждевременной оптимизации и поминать их всуе, как минимум, не корректно.

Вот нашёл, цитата из книги:

Золотые слова - подпишусь под каждым. Только вот К ЖУТЧАЙШЕМУ моему сожалению толпы эмбеддерщиков об оптимизации на верхних уровнях думают с трудом . Зато по рассуждать о том что на десяти командах они на АSM обгонят компилятор это всегда готовы . А услышав слова о вреде преждевременной оптимизации поснимают галочки где-нибудь в IDE и скажут, что Александреску с Макконнелом так велят .
Умение оптимизировать на верхних уровнях определяется в том числе и инструментальными средствами которые человек освоил. Одно дело, когда человек пошел от сохи железа и постиг программирование в кодах (на самом деле он считает, что пишет, на ASM, но реально это настолько минималистичное использование даже ASM, что это практически кодирование ). Другое, когда уже понимает и имеет успешный опыт, например, в C++. Это другие горизонты, другое понимание и другие возможности.