Вызов функций написанных на C++ из кода C

[Ochkarik]

возможно ли?
имеется проект на Си. к нему надо подключить пару функций написанных на C++ в отдельных файлах.
("плюсов" в этих функциях - только декларация переменных в произвольных местах кода)
компилятор CodeComposerStudio  под TMS-DSP, но не суть.
он вроде позволяет в одном проекте раздельно компилить файлы С и С++....
а вот как их заставить найти друг друга?
(насчет extern "C" понятно, но у меня обратная задача)

хотелось бы поменьше заморочек)

[Алексей++]

а в DLL загнать ?

[Ochkarik]

какие еще dll?
я ж говорю DSP процессор) без ОС, без ничего. память: 64к данных + 64к программы или типа того...

[Алексей++]

эт не знаю, что такое )) Поэтому не обратил внимания. А тогда, мне кажется, пез переписывания под C - никак

Если только модуль в машинных кодах сделать (по сути, та же длл и будет )

плюсов" в этих функциях - только декларация переменных в произвольных местах кода)

тем более - вынести переменные в глобальную часть и аккуратно назвать - для каждого блока своё имя, желательно


к примеру

Код: (C++)

{
   int i;
  {
       int i;
       i=5;
  }
  i=7;
}

станет

Код: (C)

   int i_1;
   int i_2;

{
  {
       i_2=5;
  }
  i_1=7;
}

[Ochkarik]

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

[Алексей++]

Ochkarik, ну, подождём тогда специалистов

[Ochkarik]

вроде тупо обернул  cpp-функцию оберткой extern "C" - и вроде ругаться перестало, что внутри...

PS удивительно. мало что скомпилилось и слинковалось да еще и заработало.... это вообще нормально?)

[Finch]

Ochkarik, Вроде как GCC такое умеет делать. Правда я так не издевался. У тебя же там классов нет. А все остальное должно компилироваться и линковаться без проблем.

[Ochkarik]

да фактически - действительно нет...
ну чтож, буду считать что прокатит) вот только "что скажет мама...."
в смысле заказчики)))))
я б им либу отдал.. но пока не научился ее в CСS делать) интересно пройдет ли тот же фокус в VS?

[Finch]

При сопряжении нескольких языков нужно.
1) согласование вызовов функций и процедур. Как передаются и принимаются аргументы. Стек, кто очишает и востанавливает. Регистры могут меняться или нет.
2) Работа с кучей,
3) вызовы стандартных внешних функций.
Если компилятор поддерживает одинаковую политику для нескольких языков, то линковка объектных файлов должна происходить IMHO без проблем.

[resource]

Эх теория. Что-то не очень понял про "Работа с кучей", и то какое отношение она имеет к языку (любому). А что вот понимать под "стандартными" внешними функциями. в общем-то, чтобы вызвать какую бы то не было функцию, ее надо описать (последний "термин" может варьироваться). А это как раз то, о чем и говорит пункт 1. Интересно кстати, какое ключевое слово говорит о том, могут ли меняться регистры.

[Finch]

Если почитать Рихтера То у него есть одно из предупреждений, очень осторожно обрашаться с оператором new в DLL. Почему, У Рихтера лучше написано. Где то на форуме я кидал табличку, с разными правилами для функций. Надо будет ее найти

[Ochkarik]

resource, в общем виде:
"....Содержимое каких регистров процессора подпрограмма обязана восстановить перед возвратом."

PS а насчет кучи... действительно для некоторых операторов создается небольшой массив в котором хранятся служебные переменные... видимо это имелось в виду?

[resource]

Та там написано, что надо ESP и EBP восстановить. Бред какой-то.

Во всех нижеперечисленных соглашениях подпрограмма обязана обеспечить восстановление перед возвратом значений сегментных регистров процессора, а также регистров ESP и EBP.

Читаю "все нижеперечисленные".

Номер 1 - cdecl. Закрываю википедию.

[Ochkarik]

ну.... бывает)))))

[Finch]

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

[resource]

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

[Ochkarik]

функции работы с ниятми, обработка исключений помоему? что то еще...

[Finch]

resource, MSVS в дебаг версии добавляет в конце зарезервированного массива небольшой кусочек памяти и заполняет его числом 0xC7 если я правильно помню. Теперь если программа вышла за пределы массива и что то писала туда, то это число естественно будет затерто. При удалении массива, идет проверка на выход.

[Ochkarik]

Finch, помоему это не только в конце массива. MSVC в дебаге инициализирует память значением СС, в релизе - нулем. считается что это помогает бороться с неинициализированными переменными....
http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new
http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx

[resource]

Обработка исключений  на стеке располагается. В куче там вроде ничего не создается.
Про выход за пределы массива все понятно (отстойный кстати способ). Но возвращаясь к сути вопроса, куча то тут при чем.
Сдается мне, мы про какие-то разные кучи говорим. Я про ту кучу, что бывает у каждого процесса, и из которой можно выделять память. В винде по крайней мере. Вот я и не пойму какое отношение она имеет к языку программирования, особенно такому, компиляторы для которого существуют не только под винду и x86.

[Finch]

resource, Обработка исключений вообше отдельная песня. В С я насколько знаю, вообше нету механизма работы с этим. Следовательно любое падение в С++ модуле будет означать однозначный вылет всей программы. Кстати оператор new, как ты недавно меня озадачил, тоже несет в себе исключение .
Теперь насчет кучи. Так уж принято, что место, где выделяется динамическая память, называют кучей. У компилятов с разных языков, может быть разный механизм работы с кучей. Я кстати видел в нете самописные механизмы работы с кучей для С++. Там они затачивали на очень маленькие массивы в одном случае и во втором на очень большие массивы.

[resource]

То что исключения это отдельная песня, согласен абсолютно.
Вот дальше тут речь о Си или Си++? В Си вроде б нету. В плюсах то как же try-сatch? Или это только в винде? В плюсах я не силен.

resource, Так уж принято, что место, где выделяется динамическая память....

А где это место?  

У компилятов с разных языков, может быть разный механизм работы с кучей

Ого. Думаю, что выделение памяти к компилятору вообще отношения не имеет. Механизм работы с кучей в Си это malloc. Его ведь ты вызываешь, а не компилятор.

[Finch]

resource, Это в С/С++ все отдано на откуп программиста. Есть и другие языки.

[resource]

Ну Ochkarik то как раз про Си\Си++ изначально говорил 

[Ochkarik]

кстати таки получилось все) и даже заработал девайс без отладки!
сделал два проекта, один - чисто C++ с включенной оптимизацией. по его obj-файлам делаю либу. (либа - чтобы не зависеть от опций чужого проекта, у меня по производительности все впритык)
затем либу скармливаю второму(чужому) проету на Си. в этом проекте только один файл, объявленный как С++. в нем функция обернутая целиком в extern "C", и вызывающая мои функции из C++ либы. и еще вторая функция - обработка аппаратного прерывания- тоже в обертке, тоже вызывает C++ код.
а почти недельные мучения заключались в отсутствии правильного мапинга сегментов памяти процессора в чужом проекте))
 
PS а поддержки исключений в C++ этого TMS320C55xx процессора вроде и не оказалось, как класса)

[Антон (LogRus)]

Функции реализованные на C++ можно легко вызывать из C кода, но:
1. нельзя использовать перегрузку по параметрам (это надо проверить точно не помню), причина в особенностях декорированная имён компилятором
2. у функции из c++ должен быть C интерфейс
3. функции должны быть обёрнуты в extern "C"

[PredatorAlpha]

Проблем быть не должно, при обёртке extern "C". Интерфейс компилятор TMS всегда использует один и тот же. По возможности он вообще стек не использует, старается обойтись регистрами.

Прикольно смотреть код для TMS64xx. Там 64 регистра общего назначения, плюс ещё всякие специализированные. Параметры тупо рассовываются по регистрам (если не массивы или не большие рекорды), и вызывается нужная функция. Если функция не вызывает другие функции, то в стек не попадает даже адрес возврата, что тоже хранится в регистре, в конце функции компилятор тупо делает переход по адресу из регистра; если же вызывает другие функции, то пытается этот регистр сохранить в другом регистре, что бы не запортился адрес и не обращаться к стеку.

Правда, в такой стратегии компилирования есть свой минус - в начале функции обычно идёт сохранение в стеке всех регистров, что изменяет функция, а в конце - восстановление.