Проект транслятора или интерпретатора на C++ , Ищу единомышленника для совместной работы

Homez, да. Преимущественно веб. Вполне хорошо знаю php и js, чуть хуже питон 3.2, ну и ещё хуже С++

Цитата Snej @ 23.01.12, 15:23

хорошо знаю php

Цитата Snej @ 23.01.12, 15:23

ещё хуже С++

Мда, не стого конца ты начал!

AZote
С того) Я начал от "лучшего к худшему".

Гм, я могу оскорбиться. Это C++ хуже, чем PHP?

Цитата Homez @ 23.01.12, 16:17

Гм, я могу оскорбиться. Это C++ хуже, чем PHP?

Не принимай близко к сердцу. Он ишо неопытный!

Homez, AZote
нееет))) Я про мой уровень знаний относительно этих япов. Пхп и жс я знаю лучше чем С++. А если сравнивать пхп и С++, то С++ канешн круче будет)

а, ну ясно, я спокоен тогда:)

Не заглох ли ещё проект?
Очень интересно.
Отпугивает, однако, желание коммерческой выгоды и отсутствие кроссплатформенности.
В моих проектах иногда требуется написание плагина, который позволял бы пользователю составлять простенький сценарий работы. Т. к. пользователи зачастую нубы, язык сценария должен быть максимально простым. Поэтому в каждом проекте язык свой, в семантику языка вносятся только необходимые именно для данного проекта конструкции.
Отсюда появляется прямое следствие. Требуется библиотека C++, позволяющая:
*) максимально просто задавать семантику любого языка;
*) загружать скрипт пользователя на соответствующем языке;
*) транслировать скрипт в объектный или ассемблерный код (не в exe);
*) выполнять полученный код.
Нигде ничего подходящего (ещё одно моё условие - совместимость с C++ Builder) я не нашёл, поэтому пишу такую библиотеку сам.
Транслирую скрипт в объектный код своего формата, т. к. трансляция в ассемблерный код кажется слишком заморочной. К тому же не понятно, можно ли в оперативную память скопировать код функции, а затем сделать прыжок "CALL" в этот участок памяти. По идее ради безопасности такая махинация должна быть запрещена.

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

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

Кстати, Ваше условие для интерпретатора сценариев, который нужен Вам в Ваших проектах - обязательная совместимость с C++ Builder - разве не противоречит Вашим словам, что отсутствие кроссплатформенности в моем проекте Вас отпугнуло?

Проекта как такового еще и нет, поэтому и глохнуть пока еще нечему:) Но идея еще жива. Кстати, тут вэтом же разделе у меня есть другая схожая тема, Вы ее видели?

Цитата Zaytsev Artem @ 11.04.12, 09:45

Транслирую скрипт в объектный код своего формата, т. к. трансляция в ассемблерный код кажется слишком заморочной.

ИМХО, не очень удачная, а потому могущая запутать терминология. То, что Вы назвали объектным кодом своего формата, лучше бы называть байт-кодом, как в случае Java, возможно, таким же образом именуют выходной код для .NET (здесь уже я не могу быть уверене на все сто). То, что Вы назвали ассемблерным кодом, лучше бы называть просто машинным кодом, не имели же Вы в виду код на языке ассемблер? А я последний и называю ассемблерным кодом, думаю, как и многие.

Цитата Zaytsev Artem @ 11.04.12, 09:45

К тому же не понятно, можно ли в оперативную память скопировать код функции, а затем сделать прыжок "CALL" в этот участок памяти. По идее ради безопасности такая махинация должна быть запрещена.

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

В Вашем случае, конечно, немного сложнее, но решаемо. Формирование машинного кода прямо в процессе работы программы, с последующим его выполнением, называется JIT-компиляцией (Just In-Time). На сегодняшний день это используется в таких средах, как Java и .NET, что решило проблему быстродействия в этих системах - оно теперь такого же порядка, как и у программ, сразу компилмруемых в машинный код (так, решая вычислительные задачки с Project Euler, я обнаружид, что порой равнозначный код на Java выпоняется быстрее, чем на C++ в релиз-конфигурации). Тут просто нужно выделять память для машинного кода, получающегося в результате трансляции, для это блока памяти поставить нужные разрешения - и можно запускать. Но конечно, транслировать в байт-код для собственной виртуальной машины намного проще, потом тут можно эффективно решить многие проблемы, связанный с возможными ошибками выполнения (например, выход за пределы блока памяти и т.д. Тем более это существенно, если Вы говорите, что большинство пользователей этих продуктов будут заметно низкой квалификации в программировании.

Добавлено 11.04.12, 13:39

Цитата Homez @ 11.04.12, 13:34

Отсюда появляется прямое следствие. Требуется библиотека C++, позволяющая:
*) максимально просто задавать семантику любого языка;

Насколько я понял, то не только семантику, но и синтасис, так? То есть, с помощью такой библиотеки можно бы было для одной программы сделать один язык для пользовательских скриптов, а для другой - совершенно другой язык? С таким я дела не имел. Может быть, Вам есть смысл посмотреть в сторону генераторов лексических и синтаксических анализаторов, думаю, что в виде библиотек таковые имеются - я как-то не интересовался этим вопросом, в моих интерпретаторах-трансляторах и синтаксис, и семантика были жестко заданы.

Добавлено 11.04.12, 14:14
Это по сути уже получается интерпретатор интерпретатора:) Гораздо более сложная задача, нежели написание интерпретатора фиксированного языка.

Сообщение отредактировано: Homez - 11.04.12, 14:19

Цитата Homez @ 11.04.12, 13:34

где я в этой теме писал про коммерческую выгоду?

Меня смутила фраза:

Цитата Homez @ 16.11.11, 22:14

могло бы и приносить доход с продаж копий

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

Цитата Homez @ 11.04.12, 13:34

Проекта как такового еще и нет

Ну, по аналогии с "интерпретатором интерпретатора", будем считать Вашу задумку "проектом проекта")))

Цитата Homez @ 11.04.12, 13:34

что это обязательно будет под Win32

Под "кроссплатформенностью" я подразумевал не Win32 (Вы ведь напрямую об этом и не писали). Меня смутило то, что Вы написали про MSVC и про Builder, но при этом не упомянули возможность поддержки и того, и другого одновременно.

Цитата Homez @ 11.04.12, 13:34

обязательная совместимость с C++ Builder - разве не противоречит Вашим словам

Здесь ключевое слово "совместимость". Это значит, что библиотека может работать под любую C++ IDE, но лично мне требуется, чтобы и в Builder-е работала.

Цитата Homez @ 11.04.12, 13:34

То, что Вы назвали объектным кодом своего формата, лучше бы называть байт-кодом

Не знаю, я в вопросе данной терминологии не компетентен. Наверное Вы правы, "байт-код" звучит менее странно.

Цитата Homez @ 11.04.12, 13:34

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

Вы, конечно, правы, я оговорился.

Цитата Homez @ 11.04.12, 13:34

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

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

Цитата Homez @ 11.04.12, 13:34

Насколько я понял, то не только семантику, но и синтасис, так?...

Честно говоря, слабо представляю, что такое синтаксис, а ещё слабее, как его можно задавать.
Правильно ли я понимаю, что различная семантика - это когда в одном языке "begin" а в другом "{", а различный синтаксис - это когда в одном языке "for (i = 0; i < iMax; ++i)", а в другом "for i := 0 to iMax - 1 do"?
Если так, то у меня синтаксис задан жёстко. Иначе было бы слишком сложно. А в общем случае, конечно, да, было бы здорово.

Цитата Homez @ 11.04.12, 13:34

В сторону генераторов лексических и синтаксических анализаторов

Я глядел, но ничего пригодного для использования "из коробки" не нашёл.

Цитата Homez @ 11.04.12, 13:34

интерпретатор интерпретатора

Забавно)))

Цитата Homez @ 11.04.12, 13:34

Гораздо более сложная задача

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

Цитата Zaytsev Artem @ 11.04.12, 18:38

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

Да, я когда сегодня перечитывал тему, как-то не пропутил ту фразу про возможный доход с продаж копий:) Хотя совсем рядом вычитал про промышленный уровень:) Да, я такой возможности не исключаю, но не ставлю во главу угла? Чего плохого в таком желании?

Цитата Zaytsev Artem @ 11.04.12, 18:38

Ну, по аналогии с "интерпретатором интерпретатора", будем считать Вашу задумку "проектом проекта")))

За фразу респект:) Проект проекта - как звучит-то:)

Цитата Zaytsev Artem @ 11.04.12, 18:38

Меня смутило то, что Вы написали про MSVC и про Builder, но при этом не упомянули возможность поддержки и того, и другого одновременно.

Гм, а зачем это в моем проекте проекта? Если бы я принялся, я бы всяко стал программировать в какой-то одной среде. Ну возможно, если б это был чистый проект Win32, его можно было бы клепать и там, и там, но я бы не колебаясь остановился на Visual Studio, в билдере я и не пробовал что-то делать без VCL. Я же вел речь именно об отдельном приложении-трансляторе, но не о библиотеке какой-нибудь, что начали разрабатывать Вы.

Цитата Zaytsev Artem @ 11.04.12, 18:38

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

Я Вам в PM, кажется, еще добавил своих мыслей на эту тему.

Цитата Zaytsev Artem @ 11.04.12, 18:38

Честно говоря, слабо представляю, что такое синтаксис, а ещё слабее, как его можно задавать.
Правильно ли я понимаю, что различная семантика - это когда в одном языке "begin" а в другом "{", а различный синтаксис - это когда в одном языке "for (i = 0; i < iMax; ++i)", а в другом "for i := 0 to iMax - 1 do"?

Нет, Вы неправильно понимаете. begin в одном языке, а { в другом - это разный синтаксис. При этом cемантически { в C++ равносильно begin в Delphi. По поводу же Вашего примера двух циклов for, тут, конечно, синтаксис разный. Да и семантика равнозначна только для данных двух примеров циклов. Например, в C++ можно внутри круглых скобок приращения цикла и не делать, либо поставить туда совершенно любое выражение, которое имело бы какой-то побочный эффект.

Цитата Zaytsev Artem @ 11.04.12, 18:38

Если так, то у меня синтаксис задан жёстко. Иначе было бы слишком сложно.

В свете вышесказанного можно совершенно неправильно понять эти Ваши слова. Правильно ли я понял, что Ваш анализатор имеет жесткие правила синтаксического разбора, просто, например, ему можно как-то указать, что ему считать за начало составной инструкции, какое ключевое слово обозначает оператор цикла и т.д.? Если так, то не вижу особых преимуществ. Это все равно что с помощью дефайнов заставить компилятор C++ считать begin за {, а { порождал бы какой-нибудь нераспознанный токен, с той только целью, чтобы генерировать ошибку, ведь у нас должны быть begin вместо {. Но язык-то при этом остается тем же самым, а только будут плодиться разночтения среди конечных пользователей.

Цитата Zaytsev Artem @ 11.04.12, 18:38

А в общем случае, конечно, да, было бы здорово.

Хотел сказать безоговорочное "да", но сейчас уже начал сомневаться. Я подобного никогда не делал и даже не планировал. А продумывая некоторые свои слова выше, к данному моменту я уже несколько запутался:) Семантику как раз-таки придется подгонять под один костюмчик, иначе получится "поди туда, не знаю куда, принеси то, не знаю что". Библиотека же будет одна? Следовательно, надо четко продумать виртуальную машину, операции, которые в ней разрешены. Просто совершенно разные и порой совсем не похожие конструкции в двух разных транслируемых языках могут приводить к аналогичному по сути байт-коду, который будет выполняться на этой виртуальной машине.

Цитата Zaytsev Artem @ 11.04.12, 18:38

В сторону генераторов лексических и синтаксических анализаторов
Я глядел, но ничего пригодного для использования "из коробки" не нашёл.

Мне и самому стало интересно, но сейчас просто нет времени на изыскания. В субботу, может быть, поищу чего-нибудь сам, если что найду, дам знать. Попробуйте в гугле ввести фразу "Генератор лексических анализаторов" и такую же фразу, только для синтаксических. Поройтесь в википедии.

Добавлено 11.04.12, 21:06
Советую подправить вашу терминологию, потому что если придется работать в команде, да даже если сделаете готовый продукт и напишете по нему документацию - люди просто неправильно будут интерпретировать Ваши слова.

Добавлено 11.04.12, 21:10
Кстати, Артем, уже чего-то добились? Или пока что все на стадии идей?

Добавлено 11.04.12, 21:45
Гм, прочитал про Lex и Yacc - генераторы, соответственно, лексчических и синтаксических анализаторов. Они генерируют код на C, который уже можно включить в свою программу, то есть на лету уже не получится. Попробую поискать еще, выкроил немного времени перед сном.

Добавлено 11.04.12, 21:59
Гм, а по ходу, таких тулов, которые могли бы генерировать анализаторы, которые тут же на ходу можно бы было и применять, и нету... Есть возможность сказать свое первое слово:) Кстати, за такой бы проект с удовольствием взялся. Понятно, однако, что получающийся в итоге, допустим, объект, который будет производить синтаксический или лексический анализ, будет работать дольше медленнее специально написанного аналога, так как по сути это будет интерпретатор.

Добавлено 11.04.12, 22:01
Но ха, что мешает тут сделать JIT-компиляцию этого генерируемого анализатора:) Понятно, что это еще на порядок сложнее, но тогда получится совсем мощная система, аналогов которой в мире может и вовсе не быть!

Здесь задача как раз для внешнего генератора синтаксических анализаторов и для внешнего же генератора синтаксического анализатора (например пара flex+bison), надо только научиться ими пользоваться. Они сгенерируют несколько файлов, которые, будучи подключенными к программе, будут производить компиляцию (часть функций, естественно, придется написать вручную) скрипта в байт-код. Интерпретация байт-кода производится достаточно быстро, чтобы не обращать на нее слишком много времени.

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

Добавлено 12.04.12, 10:21
Генерировать анализаторы на лету - изврат. Не думаю, что автор хочет учить пользователей еще и программированию компиляторов (учитывая, что он и сам в них еще не разбирается).

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

Для новой программы придется скорее всего дописать лишь несколько встроенных функций.
Ну и обнаруженные в старом варианте ошибки/недоделки исправить.
Новый вариант можно старым программам прилинковать.

Цитата Homez @ 11.04.12, 21:04

Чего плохого в таком желании?

Для Вас ничего плохого, даже наоборот)

Цитата Homez @ 11.04.12, 21:04

Гм, а зачем это в моем проекте проекта?

Значит я неправильно выразился. Тогда отпугивает отсутствие "библиотечности")

Цитата Homez @ 11.04.12, 21:04

В свете вышесказанного можно совершенно неправильно понять эти Ваши слова.

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

Цитата Homez @ 11.04.12, 21:04

Правильно ли я понял,

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

Цитата Homez @ 11.04.12, 21:04

Это все равно что с помощью дефайнов...

Верно, но эта возможность должна быть заявлена (т. е. её следует упомянуть в числе требований). Кстати, #define - это разве по сути не интерпретатор интерпретатора?

Цитата Homez @ 11.04.12, 21:04

Советую подправить вашу терминологию

Каюсь, есть такая проблема.

Цитата Homez @ 11.04.12, 21:04

Кстати, Артем, уже чего-то добились? Или пока что все на стадии идей?

На стадии разработки. Сделал общий каркас библиотеки. Делаю парсер. Затем останется сделать виртуальную машину.

Цитата amk @ 12.04.12, 10:20

Они сгенерируют несколько файлов

А какого формата файлы они генерируют?