Комментарии 74
А зачем дерево строить? Почему не построить линейную структуру, интерпретатор будет работать быстрее.
0
НЛО прилетело и опубликовало эту надпись здесь
Черт возьми, а зачем надо было самостоятельно писать парсер/лексер? Закат солнца вручную just for fun?
+9
Вообще, конечно, код ужасен. Вас интересуют комментарии по поводу его, или мне сразу идти нахуй?
+7
если хотите, можете пойти)
интересуют. всё делается just for fun.
интересуют. всё делается just for fun.
+3
Ну раз автор меня не посылают, тогда предложу:
— лексер руками не стоит писать. Это не джастфофан, это многометровый рутинный гемморой, как только грамматика разрастается. А она разрастется, у си в этом плане все в порядке :)
— вы на с++ пишете как на си. Может, ну их нафик, эти классы? Мне в самом деле непонятно. Подключите к проекту буст или КуТи — кода будет реально в 2 раза меньше, и что важно — станет гораздо меньше инфраструктурного кода => будет больше фана и времени проверять идеи, а не кодить бэйзмент для них;
— в дополнение к моменту про си и сипипи — никакой обработки ошибок. В с++ с этим более кодер-фрэндли, чем в плэйн си, но этого у вас тоже нет;
— чистоплюйский момент — у вас счас в транке бардак, куски закомментированного кода и т.п. — видно сразу, проверялась какая-то идея. Для этих целей существуют приватные бранчи, благо svn позволяет достаточно легко мержить куда более крупные проекты. Счас там ад и израИль :)
— лексер руками не стоит писать. Это не джастфофан, это многометровый рутинный гемморой, как только грамматика разрастается. А она разрастется, у си в этом плане все в порядке :)
— вы на с++ пишете как на си. Может, ну их нафик, эти классы? Мне в самом деле непонятно. Подключите к проекту буст или КуТи — кода будет реально в 2 раза меньше, и что важно — станет гораздо меньше инфраструктурного кода => будет больше фана и времени проверять идеи, а не кодить бэйзмент для них;
— в дополнение к моменту про си и сипипи — никакой обработки ошибок. В с++ с этим более кодер-фрэндли, чем в плэйн си, но этого у вас тоже нет;
— чистоплюйский момент — у вас счас в транке бардак, куски закомментированного кода и т.п. — видно сразу, проверялась какая-то идея. Для этих целей существуют приватные бранчи, благо svn позволяет достаточно легко мержить куда более крупные проекты. Счас там ад и израИль :)
+8
О, и кстати — я рекомендую вам прочесть книжку «Структура и интерпретация компьютерных программ» (SICP в английском варианте). Очень развивающее чтиво для тематики проекта
+3
char* rs=new char[13];
strcpy(rs,«unsigned int»);
rs[12]=0;
return rs;
Как аккуратненько с размерами массивов обходитесь =) Но лучше бы просто использовали std::string и не парились ;) Зачем юзая C++ кодить указатели на char без острой необходимости.
strcpy(rs,«unsigned int»);
rs[12]=0;
return rs;
Как аккуратненько с размерами массивов обходитесь =) Но лучше бы просто использовали std::string и не парились ;) Зачем юзая C++ кодить указатели на char без острой необходимости.
+5
char rs[] = «unsigned int»;
Ы?
Ы?
0
нет, так не будет. мне нужно именно выделить память чтобы она автоматом не освободилась при выходе из текущего контекста.
0
Строковые литералы в Си не освобождаются при выходе из scope. К тому же они const char *.
0
в таком виде компилятор будет ругаться
но так можно
char* foo(){ char tmp [] = {"lala"}; return tmp; }
но так можно
0
О, поздравляю с прогрессом!
+1
>Пишется продукт на С++
Советую прочитать Скотта Мейерса «Эффективное использование С++»
Советую прочитать Скотта Мейерса «Эффективное использование С++»
+1
>>А какие ваши варианты использования интерпретатора си? Где бы можно было применить этот продукт?
Как я уже говорил при симулировании/отладке микроконтроллеров, правда байт-код использовать было бы лучше- быстрее.
Как я уже говорил при симулировании/отладке микроконтроллеров, правда байт-код использовать было бы лучше- быстрее.
+2
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
0
В коде творится непонятно что. Судя по всему у вас большие проблемы при работе с памятью, в том числе использование указателей после delete, выход за границы массивов и прочее. Про утечки памяти я просто молчу, так как какой-либо логики ownership указателей я не нашёл. Указатели повсюду создаются, return'ятся и копируются.
int* J=new int; //не трогать!
По-другому я объяснить смысл таких строк не могу.
Про лексический анализатор и std::string уже сказали.
Ещё вы возможно не очень хорошо знаете сам язык. В частности это видно по тому, что вы ставите точки с запятой после закрывающих фигурных скобок. Не везде, но есть.
int* J=new int; //не трогать!
По-другому я объяснить смысл таких строк не могу.
Про лексический анализатор и std::string уже сказали.
Ещё вы возможно не очень хорошо знаете сам язык. В частности это видно по тому, что вы ставите точки с запятой после закрывающих фигурных скобок. Не везде, но есть.
0
Да, про язык — есть немного)
Проблем с памятью, а особенно «использование указателей после delete» — не замечал.
а по поводу
int* J=new int; //не трогать!
тронуть впринципе можно) это я проверял идею одну, нужно было в некоторых местах программы выделить один int. Это остатки от него.
Проблем с памятью, а особенно «использование указателей после delete» — не замечал.
а по поводу
int* J=new int; //не трогать!
тронуть впринципе можно) это я проверял идею одну, нужно было в некоторых местах программы выделить один int. Это остатки от него.
0
> Проблем с памятью, а особенно «использование указателей после delete» — не замечал.
valgrind запускали? :)
valgrind запускали? :)
0
эмм… нет) попробую)
0
Нашел и исправил большое количество однотипных ошибок. Забывал при копировании строки в конец добавлять 0 и выделять на 1 байт больше, соответственно отсюда и «использование указателей после delete», и т.д.
Если раньше valgrind выдавал около 1500 ошибок в 100 контекстах, то теперь — 17 ошибок в 17ти контекстах. Думаю, это прогресс)))
Если раньше valgrind выдавал около 1500 ошибок в 100 контекстах, то теперь — 17 ошибок в 17ти контекстах. Думаю, это прогресс)))
0
ты случайно не из МГУПИ? :)
0
нет)
0
тогда прошу прощенья — у нас один парень с 2 курса говорил что пишет интерпретатор С, я уж подумал он наконец-то дописал )
0
а вы его не спрашивали, для чего он его будет применять?:)
0
спрашивал, но он так и не сказал :D
я думаю просто так, для себя. я тоже пишу язык для себя, потому что интересно )) опыта прибавляет неимоверно, хотя вы и без меня знаете :)
я думаю просто так, для себя. я тоже пишу язык для себя, потому что интересно )) опыта прибавляет неимоверно, хотя вы и без меня знаете :)
0
Было бы здорово, если бы Вы написали про него статью!
0
Даёшь статью про свой язык!
0
пока он еще глубоко в разработке, но почитать кое-что можно тут: spark.ms/malco/
Надеюсь сайт от хабраэффекта не сляжет )
Надеюсь сайт от хабраэффекта не сляжет )
0
>«Да, уже создана чертова куча языков, в том числе и для веб-платформы: PHP, Perl, Python, Ruby, Javascript в конце концов.»
А в чем смысл смешивания серверных языков и клиентского Javascript?
>«Python: Лямбда-выражения вместо лямбда-функций»
Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Сколько я писал на Django, Tornado, GAE — никогда не применял, зато часто нужны были в GTK-приложениях ;)
А в чем смысл смешивания серверных языков и клиентского Javascript?
>«Python: Лямбда-выражения вместо лямбда-функций»
Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Сколько я писал на Django, Tornado, GAE — никогда не применял, зато часто нужны были в GTK-приложениях ;)
0
> А в чем смысл смешивания серверных языков и клиентского Javascript?
Почитайте про ServerSideJS, реализованный на V8. На хабре много статей. Да и JS — это для меня в первую очередь не «клиентское» или «серверное», а красивый и гибкий язык.
> Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Ну почему бы им не быть в таком солидном языке как Python? Ведь он не только для веба используется.
Почитайте про ServerSideJS, реализованный на V8. На хабре много статей. Да и JS — это для меня в первую очередь не «клиентское» или «серверное», а красивый и гибкий язык.
> Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Ну почему бы им не быть в таком солидном языке как Python? Ведь он не только для веба используется.
0
Собственно, их использование было сознательно ограничено. Ткнул бы в нужный ПИП, но не вспомню адреса…
0
сервер-сайд JS — то еще извращение.
изначально JS создавался для исполнения в браузере.
изначально JS создавался для исполнения в браузере.
0
JS как язык не содержит ничего, относящегося именно к браузеру. Все дело в волшебных пузырькахстандартной библиотеке — например, тот же JS используется как язык скриптинга в продуктах Adobe, которые явно не браузеры, и весьма успешно.
А учитывая скорость исполнения JS-кода виртуальной машиной V8, это не только не извращение, а вообще весьма перспективное направление.
А учитывая скорость исполнения JS-кода виртуальной машиной V8, это не только не извращение, а вообще весьма перспективное направление.
0
А это не вы?
spark.ms/about
«Родился в Москве теплым весенним днем 1989 года, с тех пор там же и живу. Сначала учился в школе английским уклоном, теперь – в МГУПИ на факультете ИТ-6 (программное обеспечение).»
spark.ms/about
«Родился в Москве теплым весенним днем 1989 года, с тех пор там же и живу. Сначала учился в школе английским уклоном, теперь – в МГУПИ на факультете ИТ-6 (программное обеспечение).»
0
Разработка интерпретатора — занятие конечно полезное, в первую очередь для себя самого. Но реальное применение ему найти будет не просто. Мой совет — либо придумывайте свой язык для конкретных задач и соответственно интерпретатор к нему, либо сводите задачу интерпретации к трансляции — то есть генерации x86/adm64 ассемблерного кода.
0
>> А какие ваши варианты использования интерпретатора си? Где бы можно было применить этот продукт?
эээ… это вы как разработчик скажите, а зачем он нужен?
эээ… это вы как разработчик скажите, а зачем он нужен?
0
ну у меня идей почти нет:) может у вас есть? =)
0
Придумайте, чем интерпретация (и тот факт, что при интерпретации доступно намного больше информации об исходном коде) может помочь написать инструмент лучше, чем valgrind.
А вообще применений куча, в основном это инструменты для программистов. Хороший компилятор самому или даже вдесятером написать невозможно.
А вообще применений куча, в основном это инструменты для программистов. Хороший компилятор самому или даже вдесятером написать невозможно.
0
За что проигнорили мою идею? В этом будет огромная польза. После Scheme, в C очень не хватает возможности просто посмореть как работает библиотека или собственный код, не создавая кучу файлов с однострочниками в main().
0
эм) я ничего не игнорировал, а сделал заметку в файлике:
naryl, 7 января
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
Так что ничего не забыто, спасибо за идею:) но всё-же я в чем же будет практическая ценность repl на си?
naryl, 7 января
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
Так что ничего не забыто, спасибо за идею:) но всё-же я в чем же будет практическая ценность repl на си?
+2
Я не вижу особо большого практического смысла. Интерпретируемый С нивелирует все плюсы и того и другого. Потому что любой компилятор С сделает бинарник, которая работает на порядки быстрее. А уже существующие интерпретатируемые языки — они все имеют более высокий уровень чем C, поэтому пользоваться ими быстрей и удобней. Только для отладки существующих программ на С, или для обучения программированию на Си «совсем с 0». Больше нет вариантов.
0
НЛО прилетело и опубликовало эту надпись здесь
А почему нельзя использовать обычный компилятор, просто проверяя изменился ли код с момента последнего запуска, и если изменился — перекомпилировать и после запустить бинарник?
0
Программисты на интепретируемых языках пишут компмляторы, а программисты на компилируемых пишут интепретаторы :)
+5
>Где бы можно было применить этот продукт?
прикольно, я думал вы мне ответите)
прикольно, я думал вы мне ответите)
+1
тем что его напишу я:)
+3
а, если честно, я его первый раз вижу)
0
CINT? Так ещё и Ch interpreter существует…
И оба вполне хороши…
Хороший интерпретатор написать — это не дульки воробьям показывать :-)
И оба вполне хороши…
Хороший интерпретатор написать — это не дульки воробьям показывать :-)
+1
добро пожаловать в интернет
0
Где бы можно было применить этот продукт?
Например студентам показывать как не нужно писать на c++ ;)
Я бы поигрался с возможностью трансляции в другие языки (например c -> php/python).
А вообще интересно было бы проследить сколько протяните в режиме «все сам» ;)
+2
Я бы посоветовал больше использовать stl. Свои деревья, сеты и листы это конечно хорошо, но с stl дело пойдет куда быстрее, а кода станет на 15кб меньше :)
Про указатели уже сказали выше. Попробуйте изучить auto_ptr, shared_ptr (или написать свой, что тоже полезно для образовательного процесса. Описаний как этот механизм устроен — множество). Или поменьше использовать указатели — сейчас память будет сильно течь.
Отсутствие code-style. Точки с запятой после объявления функций и циклов, плавающие отступы, однострочные if-else — читать такой код очень тяжело.
Система сборки. Не у всех есть CodeBlocks. Makefile был бы к месту.
И тесты. Без них проект не сможет расти.
Про указатели уже сказали выше. Попробуйте изучить auto_ptr, shared_ptr (или написать свой, что тоже полезно для образовательного процесса. Описаний как этот механизм устроен — множество). Или поменьше использовать указатели — сейчас память будет сильно течь.
Отсутствие code-style. Точки с запятой после объявления функций и циклов, плавающие отступы, однострочные if-else — читать такой код очень тяжело.
Система сборки. Не у всех есть CodeBlocks. Makefile был бы к месту.
И тесты. Без них проект не сможет расти.
0
Теперь надо прикрутить к интерпретатору JIT ;) Может получиться хорошая штука чтобы проверять покрытие, хотя это можно сделать и проще.
0
А можно поподробнее? Какое покрытие?
0
ru.wikipedia.org/wiki/Покрытие_кода → «Покрытие путей» и «Покрытие функций».
0
Я когда то писал интерпретатор близкого языка к PHP, пишите дальше, не слушайте никого, никакие умники не дадут вам того опыта, который вы получите, если будете продолжать…
0
садите свой backend на LLVM!
+1
Добавил make-файл в репозиторий
0
tcc -run
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
CPrompt — интерпретатор языка си