Как стать автором
Обновить

Комментарии 74

А зачем дерево строить? Почему не построить линейную структуру, интерпретатор будет работать быстрее.
мне кажется это риторический вопрос) кому как удобнее
НЛО прилетело и опубликовало эту надпись здесь
не совсем. мне нужно и описание функции видеть кроме имени.
Черт возьми, а зачем надо было самостоятельно писать парсер/лексер? Закат солнца вручную just for fun?
Вообще, конечно, код ужасен. Вас интересуют комментарии по поводу его, или мне сразу идти нахуй?
если хотите, можете пойти)
интересуют. всё делается just for fun.
Ну раз автор меня не посылают, тогда предложу:

— лексер руками не стоит писать. Это не джастфофан, это многометровый рутинный гемморой, как только грамматика разрастается. А она разрастется, у си в этом плане все в порядке :)
— вы на с++ пишете как на си. Может, ну их нафик, эти классы? Мне в самом деле непонятно. Подключите к проекту буст или КуТи — кода будет реально в 2 раза меньше, и что важно — станет гораздо меньше инфраструктурного кода => будет больше фана и времени проверять идеи, а не кодить бэйзмент для них;
— в дополнение к моменту про си и сипипи — никакой обработки ошибок. В с++ с этим более кодер-фрэндли, чем в плэйн си, но этого у вас тоже нет;
— чистоплюйский момент — у вас счас в транке бардак, куски закомментированного кода и т.п. — видно сразу, проверялась какая-то идея. Для этих целей существуют приватные бранчи, благо svn позволяет достаточно легко мержить куда более крупные проекты. Счас там ад и израИль :)
О, и кстати — я рекомендую вам прочесть книжку «Структура и интерпретация компьютерных программ» (SICP в английском варианте). Очень развивающее чтиво для тематики проекта
НЛО прилетело и опубликовало эту надпись здесь
char* rs=new char[13];
strcpy(rs,«unsigned int»);
rs[12]=0;
return rs;

Как аккуратненько с размерами массивов обходитесь =) Но лучше бы просто использовали std::string и не парились ;) Зачем юзая C++ кодить указатели на char без острой необходимости.
char rs[] = «unsigned int»;

Ы?
нет, так не будет. мне нужно именно выделить память чтобы она автоматом не освободилась при выходе из текущего контекста.
Строковые литералы в Си не освобождаются при выходе из scope. К тому же они const char *.
в таком виде компилятор будет ругаться

char* foo(){
	char tmp [] = {"lala"};
	return tmp;
}


но так можно

да чтож такое. не пойму на какие комбинации отправляются комменты…

собсно ругань компилятора
warning C4172: returning address of local variable or temporary

а так норм
char* foo(){
    return "lala";
}
const char *f() { return «f»; }
О, поздравляю с прогрессом!
>Пишется продукт на С++
Советую прочитать Скотта Мейерса «Эффективное использование С++»
Там еще продолжения есть «Наиболее эффективное использование С++» и «Эффективное использование STL».
А так же, советую почитать, «Стандарты программирования С++» Г. Саттер, А. Александреску.
>>А какие ваши варианты использования интерпретатора си? Где бы можно было применить этот продукт?
Как я уже говорил при симулировании/отладке микроконтроллеров, правда байт-код использовать было бы лучше- быстрее.
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
В коде творится непонятно что. Судя по всему у вас большие проблемы при работе с памятью, в том числе использование указателей после delete, выход за границы массивов и прочее. Про утечки памяти я просто молчу, так как какой-либо логики ownership указателей я не нашёл. Указатели повсюду создаются, return'ятся и копируются.

int* J=new int; //не трогать!

По-другому я объяснить смысл таких строк не могу.

Про лексический анализатор и std::string уже сказали.

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

Да, про язык — есть немного)
Проблем с памятью, а особенно «использование указателей после delete» — не замечал.
а по поводу
int* J=new int; //не трогать!
тронуть впринципе можно) это я проверял идею одну, нужно было в некоторых местах программы выделить один int. Это остатки от него.
> Проблем с памятью, а особенно «использование указателей после delete» — не замечал.

valgrind запускали? :)
эмм… нет) попробую)
а вообще, чтоб не париться, используйте smart_pointer'ы и стандартные контейнеры
Нашел и исправил большое количество однотипных ошибок. Забывал при копировании строки в конец добавлять 0 и выделять на 1 байт больше, соответственно отсюда и «использование указателей после delete», и т.д.
Если раньше valgrind выдавал около 1500 ошибок в 100 контекстах, то теперь — 17 ошибок в 17ти контекстах. Думаю, это прогресс)))
Это отлично! Но нужно использовать возможности языка, C++ как раз создавался в том числе и чтобы писать как можно меньше рутинного кода (по сравнению с C).
ты случайно не из МГУПИ? :)
нет)
тогда прошу прощенья — у нас один парень с 2 курса говорил что пишет интерпретатор С, я уж подумал он наконец-то дописал )
а вы его не спрашивали, для чего он его будет применять?:)
спрашивал, но он так и не сказал :D
я думаю просто так, для себя. я тоже пишу язык для себя, потому что интересно )) опыта прибавляет неимоверно, хотя вы и без меня знаете :)
Было бы здорово, если бы Вы написали про него статью!
Даёшь статью про свой язык!
пока он еще глубоко в разработке, но почитать кое-что можно тут: spark.ms/malco/
Надеюсь сайт от хабраэффекта не сляжет )
>«Да, уже создана чертова куча языков, в том числе и для веб-платформы: PHP, Perl, Python, Ruby, Javascript в конце концов.»
А в чем смысл смешивания серверных языков и клиентского Javascript?

>«Python: Лямбда-выражения вместо лямбда-функций»
Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Сколько я писал на Django, Tornado, GAE — никогда не применял, зато часто нужны были в GTK-приложениях ;)
> А в чем смысл смешивания серверных языков и клиентского Javascript?
Почитайте про ServerSideJS, реализованный на V8. На хабре много статей. Да и JS — это для меня в первую очередь не «клиентское» или «серверное», а красивый и гибкий язык.

> Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Ну почему бы им не быть в таком солидном языке как Python? Ведь он не только для веба используется.
Собственно, их использование было сознательно ограничено. Ткнул бы в нужный ПИП, но не вспомню адреса…
сервер-сайд JS — то еще извращение.
изначально JS создавался для исполнения в браузере.
JS как язык не содержит ничего, относящегося именно к браузеру. Все дело в волшебных пузырькахстандартной библиотеке — например, тот же JS используется как язык скриптинга в продуктах Adobe, которые явно не браузеры, и весьма успешно.

А учитывая скорость исполнения JS-кода виртуальной машиной V8, это не только не извращение, а вообще весьма перспективное направление.
А это не вы?

spark.ms/about

«Родился в Москве теплым весенним днем 1989 года, с тех пор там же и живу. Сначала учился в школе английским уклоном, теперь – в МГУПИ на факультете ИТ-6 (программное обеспечение).»
Да, я из МГУПИ, поэтому и спросил — вдруг мой собрат по несчастью :)
Разработка интерпретатора — занятие конечно полезное, в первую очередь для себя самого. Но реальное применение ему найти будет не просто. Мой совет — либо придумывайте свой язык для конкретных задач и соответственно интерпретатор к нему, либо сводите задачу интерпретации к трансляции — то есть генерации x86/adm64 ассемблерного кода.
>> А какие ваши варианты использования интерпретатора си? Где бы можно было применить этот продукт?

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

А вообще применений куча, в основном это инструменты для программистов. Хороший компилятор самому или даже вдесятером написать невозможно.
За что проигнорили мою идею? В этом будет огромная польза. После Scheme, в C очень не хватает возможности просто посмореть как работает библиотека или собственный код, не создавая кучу файлов с однострочниками в main().
эм) я ничего не игнорировал, а сделал заметку в файлике:

naryl, 7 января
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.

Так что ничего не забыто, спасибо за идею:) но всё-же я в чем же будет практическая ценность repl на си?
Пробовать библиотечки в деле без промежуточных сущностей в виде файлов с исходниками. Ловить очевидные ошибки в собственном коде. Демонстрировать всё это людям. Выполнять код по строчкам в repl намного удобнее, чем показывать этот процесс в gdb.
Я не вижу особо большого практического смысла. Интерпретируемый С нивелирует все плюсы и того и другого. Потому что любой компилятор С сделает бинарник, которая работает на порядки быстрее. А уже существующие интерпретатируемые языки — они все имеют более высокий уровень чем C, поэтому пользоваться ими быстрей и удобней. Только для отладки существующих программ на С, или для обучения программированию на Си «совсем с 0». Больше нет вариантов.
НЛО прилетело и опубликовало эту надпись здесь
А почему нельзя использовать обычный компилятор, просто проверяя изменился ли код с момента последнего запуска, и если изменился — перекомпилировать и после запустить бинарник?
Как, собственно, и делает rdmd
Программисты на интепретируемых языках пишут компмляторы, а программисты на компилируемых пишут интепретаторы :)
>Где бы можно было применить этот продукт?
прикольно, я думал вы мне ответите)
А зачем его писать? Чем CINT плох? Ну или чем CPrompt лучше CINT?
тем что его напишу я:)
а, если честно, я его первый раз вижу)
CINT? Так ещё и Ch interpreter существует…
И оба вполне хороши…
Хороший интерпретатор написать — это не дульки воробьям показывать :-)
добро пожаловать в интернет
Где бы можно было применить этот продукт?

Например студентам показывать как не нужно писать на c++ ;)
Я бы поигрался с возможностью трансляции в другие языки (например c -> php/python).
А вообще интересно было бы проследить сколько протяните в режиме «все сам» ;)
Зверское чудо получится: на Си пишем код, который транслируется в PHP, который в свою очередь будет обрабатываться интерпретатором PHP написанным на Си. Забавно, не правда ли?
Я бы посоветовал больше использовать stl. Свои деревья, сеты и листы это конечно хорошо, но с stl дело пойдет куда быстрее, а кода станет на 15кб меньше :)
Про указатели уже сказали выше. Попробуйте изучить auto_ptr, shared_ptr (или написать свой, что тоже полезно для образовательного процесса. Описаний как этот механизм устроен — множество). Или поменьше использовать указатели — сейчас память будет сильно течь.
Отсутствие code-style. Точки с запятой после объявления функций и циклов, плавающие отступы, однострочные if-else — читать такой код очень тяжело.
Система сборки. Не у всех есть CodeBlocks. Makefile был бы к месту.
И тесты. Без них проект не сможет расти.
Только не auto_ptr, а unique_ptr :)
Теперь надо прикрутить к интерпретатору JIT ;) Может получиться хорошая штука чтобы проверять покрытие, хотя это можно сделать и проще.
А можно поподробнее? Какое покрытие?
Я когда то писал интерпретатор близкого языка к PHP, пишите дальше, не слушайте никого, никакие умники не дадут вам того опыта, который вы получите, если будете продолжать…
садите свой backend на LLVM!
Добавил make-файл в репозиторий
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации