Вот такая ошибка при вызове функции написанной в *.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 файле. Он подключен везде, где требуется.

В хедерах си-шных модулей надо вставить скобки

, где


Компилировать и линковать в режиме "плюсов"

Проще прямо написать

Компилится. Только не в хэдерах си-шных модулей, а в хэдере си++ модуля. У меня только так заработало.

Можно ставить с любых заголовочных файлах, которые включаются в проект для с и cpp.

в принципе если извратица то можно из сишной программы вызывать с++ модули.
у вас проблема в том, что С++ делает такую хрень как name mangling.
то есть при линковке имена ваших функций становятся такими что их сишный линкер
не может понять.
решение которое вам подсказали вверху заставляет линкер не искажать имя функции.
но если вы попробуете предложить несколько функций с одинаковым названием-перегруженные,
то опять получите ошибку.

Если вы можете компилировать с++ модули (компилятор позволяет), то никто не мешает сказать ему, чтобы для компиляции .с модулей тоже вызывался С++ компилятор. На худой случай, просто переименовать *.с в *.срр.

С и С++ два разных языка - сколь-нибудь объемный и что-то делающий исходник на 'C' (не "Hello World!" ) плюсовым компилятором не откомпилится. Потребуются правки. В большей частью мелкие, но местами и принципиально все меняющие.

Хоть один пример.

Берете свой проект, компилите плюсовым. Получаете примеры

Область видимости констант, неявное приведение void * к любому указателю в С. Это так, навскидку.

для С++ NULL не типизирован явно, как в Си, так что приходиться делать так:

/* Define NULL pointer value */
#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif

Декларация и инициализация стуктур и константных объектов, тип литералов типа 'abcd', объявления типов в sizеof, , функции с переменным количеством аргументов, еще некоторые до сих пор не польззуются прототипами функций и C а не C99,..... В общем лучше попробовать компильнуть
Вообще-то в С++ стандарте, помнится, было целое приложение посвященное проблемам несовместимости.

P.S.
Да. Посмотрел - Annex C Compability. Единственно, что там явно не C99. Да и многие 'С' компиляторы будут на некоторые конструкции хоть не ошибки, но warnings выдавать.

Ещё работа с перечислимыми типами.

А наоборот может быть - ошибка при вызове из си++ файла функции, объявленной в простом си исходнике?

Ошибка такая же - Li005 - линкер не может найти определение функции...

Вы хоть эту ветку читаете? Про extern "C"?

А вы хоть читаете, о чём я спрашиваю?
Одно дело, когда обычный си модуль не может найти си++ функцию, имя которой, по понятным причинам, видоизменено.
Но когда наоборот - си++ модуль в упор не видит обычную си функцию?

В этом случае ведь name mangling не работает?

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

Именно для этого случая и нужно в заголовочных файлах от си функций писать extern "C". Иначе C++ ожидает функции с замангленными именами.

Понятно. Значит, всегда, когда плюсы имееют дело с ассемблерными или обычными сишными модулями (или наоборот) необходимо юзать этот костыль.
Спасибо

А это вовсе не костыль, а возможность из С++ использовать С/ASM модули. Вам эта возможность не нравится?

Я об этом знал, но считал, что это работает только в сторону от си++ к си.
Не думал, что плюсы будут манглить даже обычную сишную функцию, подключенную через хидер

Если компиляете в С++ режиме, то все функции будут кодироваться по-плюсатому. Ведь в плюсах обычное дело та же перегрузка имён функций, и как компилятор должен догадаться, какие функции у вас имеют С-связывание, а какие С++ связывание. Для этого и введена спецификация связывания extern "<Lang>", где <Lang> - отличный от С++ язык (там не обязательно должен быть С, хотя этот вариант встречается в подавляющем большинстве случаев).

А откуда С++ знать, что это 'обычная С функция'? Для этого extern "C" и предназначен

Спасибо.
Интересно, а какие ещё есть идентификаторы <Lang>?


Так тело-то этой функции - в обычном .c файле!
Компилер что, манглит сразу имя функции по её объявлению в хидере, не заглядывая даже в определение?
Вот шустрый какой!

А как компилятор в процессе компиляции файла А узнает о теле функции в файле Б? Он же их отдельно компилирует
Разумеется. Тело функции его не интересует (его вообще может не быть)

Понятно, теперь буду знать. Спасибо!

Мне попадалось FORTRAN.

И PASCAL

Кстати, никогда не делайте программы для DSP и контроллеров на С++
выгоды которые вы получите весят меньше чем недостатки и косяки
которые вы встретите и не сможете устранить.
То есть делайте свои программы исключительно на C
а не С++.
Безо всяких "extern C"/
Все таки язык С++ был разработан совсем для других целей.
Ну там базы данных писать и что-то подобное большое.
В качестве системного языка он не подходит.
По моему скромному мнению.
Хотя находятся герои которые для QNX что-то на С++ ваяют.

Вам сюда.

Для меня достаточно просто посмотреть на код С++ в асме-
что он там плодит, чтобы больше так никогда не делать.
Все это красиво получается в исходниках, но не в работе.

Вот сразу видно - пришёл человек знающий, глубоко разбирающийся в предмете. Всё чётко разложил по полочкам, разоблачил мифы, расписал недостатки, прямо и без обиняков. Теперь мы будем знать, какая кака этот C++. Спасибо вам, уважаемый inventor!

Заинтриговали. И что же он там такое плодит? Можно пример?

А, полагаю, все как обычно, например, то, что видит человек сумевший написать 100 команд (условно) на ASM, при виде листинга С/C++ программы хотя-бы на десяток килобайт. А видит он количество команд выходящее за рамки его разумения, вот и все . Занавес. Однажды я наблюдал шоковое состояние когда считающемуся достаточно опытным ASM писателю предъявил вместо его программы на ASM, которая,
1) была размером под 8K;
2) генерировала иногда в ответ не такой, сигнал, какой хотел заказчик;
3) не тянула генерацию оного сигнала выше 12KHz (заказчик уже соглашался ставить другой контроллер ).
Сишную, писанную за воскресенье, на пару килобайт меньше, правильно работающую, и к тому-же успевающую где-то под 40KHz работать.
Он думал, а может и сейчас так думает, что его просто дурят прокручивая ему на экране LeCroy какую-то обманку . Поскольку доподлинно знал, что С есть гуано , поскольку тоже что-то вроде "просто посмотреть на код С++ в асме что он там плодит,"

Угу, видели видели. Начинается с воплей 'какое С/С++ гуано', а заканчивается открытием, что у С/С++ компиляторов оказывается есть разные уровни оптимизации и дебаггерные режимы

код написанный на С++
исполняется дольше кода написанного на С или на asm
хоть ты усрись с оптимизацией

Да и на здоровье.
Ну вот какая, к примеру, разница, находится процессор в IDLE 99% или 98,9% времени?
То же самое в большинстве случаев можно сказать и про объём.

Это такой закон природы или что? Пример покажите?

Нет.
Это объективная реальность
Сейчас нет под рукой примера, завтра что-нибудь нарою.

Угу, угу. Вспоминается (с баша вроде) -

Желаю успехов в написании программ на ассемблере, ну к примеру, для Itanium'а

Это с опытом обычно проходит

Уж сколько понаписано про преждевременную оптимизацию, а воз и ныне там. При программировании на С++, после некоторого периода времени по его освоению и написания собственного прикладного инструментария (библиотек необходимых классов), голова освобождается от необходимости "борьбы с мелочами". Занимаешься собственно решением поставленной задачи, а не поиском какого-нибудь побочного эффекта из-за преобразования указателя к (void *).

Думается уважаемый inventor долго нам будет пример искать.

глупостей

Не все правда глупости, но 95% процентов воспринимают подобные речи о "преждевременности" таким образом, что в результате делают глупости .

А причем тут преждевременная оптимизация вообще-то???

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

А что, вопли про громоздкий код С++ по сравнению с С не есть пример "преждевременной оптимизации"? Нет пока не одного реального примера сравнения быстродействия задачи при реализации там и там, а вопли есть. По моему - типичный пример

После этого я совсем перестал понимать смысл вкладываемый Вами в словосочетания "преждевременная оптимизация".
Ну да ладно, переживу.

По-моему, вполне понятно о чем идет речь. Заявляется (голословно), что С++ язык медленный, а С и, уж конечно, ASM, намного быстрее. Посему, задача изначально проектируется не на С++. Ровно про это писал Александреску со-товарищи, а именно, сначала сделайте работоспособное решение, а потом, изучайте узкие места и их оптимизируете. Вроде я "мастерам" не противоречу, говоря о "преждевременной оптимизации"-

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи. Думать о построении системы и узких местах нужно СРАЗУ, а не потом рассматривая что такое выросло и как "оптимизировать" сие ЗАПЛАТКАМИ. Все узкие места должны быть ИЗВЕСТНЫ на этапе проектирования, и сделаны ОЦЕНКИ критичности этих мест до того, как будет написана левой ногой кучи кода.

Ну ладно. Александреску нам не авторитет. Мне тоже не все его мысли и рецепты нравятся, хотя встречаются и очень изящные решения. Посмотрим с другой стороны. Имеем в начале работы процессор, компилятор и стандартную библиотеку. Начинаем работать? Начинаем. Прикидываем все, где чего и как по-лучше написать. Сделали. И вдруг (или не вдруг) натыкаемся на то, что стандартная memcpy полная г...о (на форуме мы это неоднократно обсуждали), а мы ее пользуем в хвост и в гриву. Затем выясняется, что и memset такая же. А потом понимаем, что вся куча написана через жо...у. Мы про это тоже СРАЗУ должны были знать на начальном этапе проектирования? Откуда? Нам фирма-изготовитель компилятора "любезно" рассказала?

Вы всегда можете предсказать какой именно алгоритм сортировки окажется самым быстрым на вашем конкретном типе данных? Ой ли.

С другой стороны, может и с этими хреновыми (не оптимальными) функциями все вполне бы катило и заказчика устраивало? Мы тогда жили бы себе в спокойном чувстве полного самоудовлетворения и над всей этой ерундой и не задумывались.

Резюме (мое личное, может и неправильное) - невозможно все заранее предусмотреть (кое что можно), хотя бы из-за ограниченности собственных временнЫх возможностей и сил. Проект всегда итерационен (почти).

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

Именно так и есть, обычно все библиотеки САМ перекопилируешь-выкидывая оттуда
все ненужное и исправляя ихние ошибки.
Что в этом неправильного?