Теория использования разных ЯП в одной программе

[MihalNik]

Прекрасно используются? Ничего, что там преобразования строк идут к PChar, т.е. к сишному виду?
Единственный смысл объединять в одном проекте несколько языков - это когда языки разные и пользуются на разных уровнях. Помнится в универе изучали немного Isagraf, там один язык в виде блок-схем на верхнем уровне, на нём кодировалась основная логика, потом каждый блок можно было закодировать на другом языке. Смысла в один проект совать однотипные делфи и си я не вижу никакого.

И в чем проблема с этим преобразованием? Делфи вроде типы случайно не перепутает и случайно не приведет х.з. к чему.
Ок, есть большуший проект на делфи и вот захотелось туда кошерную возможность добавить, а библиотека эта на с/++. Заново переписывать?
Однотипные языки согласовать как раз проще всего - использование VCL для С++ подтверждает это прекрасно. Это не значит, что в одном модуле должно быть куча переплетений изо всех возможных языков. Но само по себе состыковать разноязыковые модули на структурном уровне м.б. очень полезно.

[Utkin]

Но само по себе состыковать разноязыковые модули на структурном уровне м.б. очень полезно.

Именно! На уровне юнитов/модулей/файлов.
При этом операции вида

z=call('Math.cpp.add(x, y)');

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

[Человек_Борща]

Ну здрасьте приехали. SQL в шоке

Всю жизнь думал, что это язык продвинутых запросов к СУБД. На нем можно писать программу? SQL просто недоязык недопрограммирования в СУБД.

Пусть мы пишем калькулятор длинных чисел на Яве фронтэнд (окошко, кнопочки) с юнитом на С++ (сама математика). У нас 2 файла (условно) - main.class и Math.cpp.
Юзер жмакает на кнопки для ввода числа и операций. Затем нажимает на кнопочку РАВНО. И тут уже каким-то волшебным образом (Стилет предлагал строкой) мы вызываем z=call('add(x, y)');
Где вместо x и y наши числа которые нужно сложить.
Все никакого смешения - все что касается чисел так и лежит в Math.cpp, все что касается кнопочек сделано на Яве. Транслятор сам умненький начинает перебирать юниты в поиске нужной функции, ну или в той же call указывать явное обращение - z=call('Math.cpp.add(x, y)'); это уже детали.

идея вызова через строки - бредовая неимоверно.

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

И снова вернулись к геморою, т.е. к мелочам. Java до мозга костей ОО-й, в C++ можно натолкать просто методов.
Как вы это решите?

не не не, никаких вызовов других ЯП через ядерные функции)
Лучше уж пре-процессор какой:

//#define LANGUAGE=JAVA

cross-import Math.h;

public static void main(String args[]) { //Java
   //#CODEBLOCK CPP
       add(args[0],args[1]);
   //#ENDCODEBLOCK CPP
}

может как-то так?

[Аватар]

SQL просто недоязык недопрограммирования в СУБД

SQL обиделся. Запросы всего лишь вершина айсберга. Вам не мешало бы посмотреть на языковые возможности для триггеров и процедур

[Stilet]

Оппоненция оппонирует
Дискуссия дискушает
Ладно, я то убеждать не буду. Я свое мнение выразил. И даже реализовал. Есть у меня целый проект, что сочетает вот такие кроссязыковые вызовы (через строку). К счастью он устраивает всех пользователей включая меня, поэтому я останусь на своем.

На нем можно писать программу?

UDF. И в запросе вызывать.

[MihalNik]

Сообщение от Человек_Борща

Всю жизнь думал, что это язык продвинутых запросов к СУБД. На нем можно писать программу? SQL просто недоязык недопрограммирования в СУБД.

Вполне скриптовый язык. Программирование - понятие очень относительное. Ключевые элементы в нем есть.

идея вызова через строки - бредовая неимоверно.

Для компилируемых языков вроде С++ и Паскаля - возможно.
Но С++ через интерпретатор запихать в PHP-какой-нибудь подойдетГ*** к г*** пристанет=)

[Stilet]

Для компилируемых языков вроде С++ и Паскаля - да.

По-моему народ до сих пор не понял что речь в этой теме идет только о интерпретаторах

запихать в PHP

Кстати ремарка: ПХП встраивается в HTML. Один ЯВУ в другом.

[MihalNik]

Сообщение от Stilet

По-моему народ до сих пор не понял что речь в этой теме идет только о интерпретаторах

Вообще-то в 2-х руслах и я лично не вижу, чем одно другому мешает

Кстати ремарка: ПХП встраивается в HTML. Один ЯВУ в другом.

И там же SQL. Только С++ для полного счастья и не хватаетЖ)

[waleri]

Сообщение от Stilet

По-моему народ до сих пор не понял что речь в этой теме идет только о интерпретаторах

С точки зрения синтаксиса языка между ними нет разницы. С точки зрения механизма вызова одного языка из другого - тоже.

[pu4koff]

Сообщение от MihalNik

И в чем проблема с этим преобразованием? Делфи вроде типы случайно не перепутает и случайно не приведет х.з. к чему.

К чему должен приводить С++ делфийскую строку? В С++ подходящего типа нет, значит будет какой-то новый, для совместимости. Это до кучи к string, QString, wxString,... если пользуются какие-то библиотеки.

Сообщение от MihalNik

Ок, есть большуший проект на делфи и вот захотелось туда кошерную возможность добавить, а библиотека эта на с/++. Заново переписывать?

Оформлять в виде dll, если разработчик библиотеки этого не сделал. Если библиотека на классах, тогда ой, всё сильно усложняется, ибо совместимость ООП в этих языках никакая, а уж бинарной точно нет. Тут уже всякие COM нужно пользовать.

Сообщение от MihalNik

Однотипные языки согласовать как раз проще всего - использование VCL для С++ подтверждает это прекрасно.

Ага. Легендарный костыль.

Сообщение от MihalNik

Но само по себе состыковать разноязыковые модули на структурном уровне м.б. очень полезно.

Примеры все что-то только про подключение сторонних библиотек. Совать чужой код в виде сорцов в свой проект - это очень странно. Всю жизнь это делали как подключение библиотеки.

Сообщение от Utkin

Все никакого смешения - все что касается чисел так и лежит в Math.cpp, все что касается кнопочек сделано на Яве. Транслятор сам умненький начинает перебирать юниты в поиске нужной функции, ну или в той же call указывать явное обращение - z=call('Math.cpp.add(x, y)'); это уже детали.

Как и кем всё это будет контролироваться и отлаживаться?
Контроль типов не нужен как я понимаю? Как быть с шаблонами С++, которые собираются на этапе компиляции и создание на лету для них трудновыполнимо, а часть кода где-то там по пути поломается? Директивы типа inline просто забудем? Что с namespace тоже ничего не понятно. Собираетесь делать на помеси плюсов, делфи, жабы,... неконтролируемые приложения, которые будут сыпать исключениями в рантайме? Из-за невозможности отладки всего этого хозяйства разработка на разных языках всё равно будет вестись отдельно.