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

[pu4koff]

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

vector это высокоуровневый тип данных, а не примитив. Об этом нужно думать. Это должно быть автоматизировано на уровне интерпретатора, программиста такие проблемы волновать не должны. Со строками проблем не увидел.

Высокоуровневый, еще и на шаблонах, которые сильно отличаются от похожих типов в других языках, например Generic'ов в шарпе. За делфями не слежу с 7 версии, там наверно тоже что-то типа шаблонов уже запилили, но со своими нюансами.

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

В Билдере они прекрасно работают. В Qt тоже свои, а не сишные строки (последние вообще мало где пригодны, разве что для совместимости).

И всюду они работают как отдельные типы. Нормальные программисты выбирают тип строки и его пользуют в проекте, ибо иначе будут постоянные преобразования и создания копий строк, что не очень хорошо сказывается на производительности. Если интерпретатор будет втихаря строки переделывать, то как минимум попадут паскальщики, любящие записывать в строки нулевой символ. Так что со всеми этими преобразованиями очень велика вероятность появления кучи трудноуловимых багов. Если же не делать скрытых преобразований, то какой в этом смысл? Захотел вызвать сишную функцию из делфей - пишешь сначала функцию для вызова функции, т.к. там на десяток строк преобразования типов? Даже со строками непонятно как преобразования делать правильно, а уж с классами при всём многообразии ООП (где-то есть интерфейсы, где-то свойств нет, а в каком-то языке всё на множественном наследовании построено, которого нет у других).

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

А я кстати (на правах холливара) тоже сторонник паскалевских строк. С их нулевым элементом в качестве длины. Мне это больше нравится чем ASCIIZ строка.

А мне никакие строки не нравятся. Неудобные со все сторон.

[Utkin]

Высокоуровневый, еще и на шаблонах, которые сильно отличаются от похожих типов в других языках, например Generic'ов в шарпе. За делфями не слежу с 7 версии, там наверно тоже что-то типа шаблонов уже запилили, но со своими нюансами.

Поэтому наверно все языки должны сводиться к наиболее высокоуровнему и выполняться в нем. И да, в делфях есть шаблоны и перегрузка. Возможно понадобиться некая большая универсальная библиотека для включения допустим стандартных библиотек соответствующих языков программирования (мы же пока фантазируем, а значит время на создание такой библиотеки не учитываем). Тогда если перед нами не экзотика, а стандартные библиотечные типы навроде TList, то интерпретатор будет "знать" как правильно их преобразовывать. Технически это возможно. да это дорого и делать наверно долго по времени, но никаких других препятствий я не вижу.

[mv28jam]

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

Что-то мне кажется что это ведёт к отказу от типов и передачи этой задачи на уровень некого интерпретатора.

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

А это к виртуальной машине.

Получится медленно, не? Кстати круг задач который "мы" планируем требует скорости выполнения или удобства-скорости написания кода?

[pu4koff]

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

Технически это возможно. да это дорого и делать наверно долго по времени, но никаких других препятствий я не вижу.

Сделать то оно можно что угодно, но я не вижу в этом смысла. Уже есть тот же .NET с какой-никакой унификацией и пользованием разных языков, правда в рамках разных проектов.

[MihalNik]

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

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

Нормальные в Билдере и в Qt будут использовать их типы строк - потому что они умеют все что нужно, в отличии от стандартных, но к ним же прекрасно приводятся.

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

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

А мне никакие строки не нравятся. Неудобные со все сторон.

Функции WinAPI - они в каком стандарте вызовов и передачи данных?
Там явно есть строки/указатели на строки.
А используются прекрасно и в Делфи и в С/++.

[Utkin]

Кстати круг задач который "мы" планируем требует скорости выполнения или удобства-скорости написания кода?

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

Уже есть тот же .NET с какой-никакой унификацией и пользованием разных языков, правда в рамках разных проектов.

И какой в этом смысл?

[pu4koff]

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

Нормальные в Билдере и в Qt будут использовать их типы строк - потому что они умеют все что нужно, в отличии от стандартных, но к ним же прекрасно приводятся.

Какой тип строк пользовать в проекте, который написан на делфи и С++ с использованием Qt?

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

Функции WinAPI - они в каком стандарте вызовов и передачи данных?
Там явно есть строки/указатели на строки.
А используются прекрасно и в Делфи и в С/++.

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

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

И какой в этом смысл?

В том то и дело, что смысла нет изобретать велосипед.

[Utkin]

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

Так Вы же опять ни фига не поняли. Для всех - мегаважное объявление. Никто не собирался смешивать все в одну кучу. Вы уже третий кто вместо того чтобы понять просто взял и все смешал в одну кучу . Задача наоборот - выполнять разный код в одном проекте, но РАЗДЕЛЬНО! И постараться сделать так чтобы это было красиво и всех устраивало.

Я понимаю IDE или лучше билд сервер с поддержкой многоязыковых солюшенов, которые умеют порядок сборки, скрипты и т.д. и т.п. чтобы нажал кнопку и всё пересобралось разными копиляторами в правильном порядке и раскидалось по нужным папкам.

Это вариант реализации, почему нет? Я изначально писал про интерпретаторы, потому что они мне ближе. Иными словами я раньше пробовал их сочинять и местами получалось. Вы все сразу окунаетесь в какие-то детали реализации которые неизбежно сделают идею невозможной и бессмысленной, сразу исходя из того что это невозможно. Не потому что этому препятствуют какие-то технические проблемы, а потому что этому препятствуют Ваши стереотипы. Отвлекитесь Вы от интепретаторов/компиляторов. Начните использовать слово транслятор.

[mv28jam]

Так Вы же опять ни фига не поняли.

Думаю стоит вам написать простой но подробный пример, а то будет и дальше так.

[Utkin]

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