— лексер руками не стоит писать. Это не джастфофан, это многометровый рутинный гемморой, как только грамматика разрастается. А она разрастется, у си в этом плане все в порядке :)
— вы на с++ пишете как на си. Может, ну их нафик, эти классы? Мне в самом деле непонятно. Подключите к проекту буст или КуТи — кода будет реально в 2 раза меньше, и что важно — станет гораздо меньше инфраструктурного кода => будет больше фана и времени проверять идеи, а не кодить бэйзмент для них;
— в дополнение к моменту про си и сипипи — никакой обработки ошибок. В с++ с этим более кодер-фрэндли, чем в плэйн си, но этого у вас тоже нет;
— чистоплюйский момент — у вас счас в транке бардак, куски закомментированного кода и т.п. — видно сразу, проверялась какая-то идея. Для этих целей существуют приватные бранчи, благо svn позволяет достаточно легко мержить куда более крупные проекты. Счас там ад и израИль :)
О, и кстати — я рекомендую вам прочесть книжку «Структура и интерпретация компьютерных программ» (SICP в английском варианте). Очень развивающее чтиво для тематики проекта
Как аккуратненько с размерами массивов обходитесь =) Но лучше бы просто использовали std::string и не парились ;) Зачем юзая C++ кодить указатели на char без острой необходимости.
Там еще продолжения есть «Наиболее эффективное использование С++» и «Эффективное использование STL».
А так же, советую почитать, «Стандарты программирования С++» Г. Саттер, А. Александреску.
>>А какие ваши варианты использования интерпретатора си? Где бы можно было применить этот продукт?
Как я уже говорил при симулировании/отладке микроконтроллеров, правда байт-код использовать было бы лучше- быстрее.
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
В коде творится непонятно что. Судя по всему у вас большие проблемы при работе с памятью, в том числе использование указателей после delete, выход за границы массивов и прочее. Про утечки памяти я просто молчу, так как какой-либо логики ownership указателей я не нашёл. Указатели повсюду создаются, return'ятся и копируются.
int* J=new int; //не трогать!
По-другому я объяснить смысл таких строк не могу.
Про лексический анализатор и std::string уже сказали.
Ещё вы возможно не очень хорошо знаете сам язык. В частности это видно по тому, что вы ставите точки с запятой после закрывающих фигурных скобок. Не везде, но есть.
Да, про язык — есть немного)
Проблем с памятью, а особенно «использование указателей после delete» — не замечал.
а по поводу
int* J=new int; //не трогать!
тронуть впринципе можно) это я проверял идею одну, нужно было в некоторых местах программы выделить один int. Это остатки от него.
Нашел и исправил большое количество однотипных ошибок. Забывал при копировании строки в конец добавлять 0 и выделять на 1 байт больше, соответственно отсюда и «использование указателей после delete», и т.д.
Если раньше valgrind выдавал около 1500 ошибок в 100 контекстах, то теперь — 17 ошибок в 17ти контекстах. Думаю, это прогресс)))
Это отлично! Но нужно использовать возможности языка, C++ как раз создавался в том числе и чтобы писать как можно меньше рутинного кода (по сравнению с C).
спрашивал, но он так и не сказал :D
я думаю просто так, для себя. я тоже пишу язык для себя, потому что интересно )) опыта прибавляет неимоверно, хотя вы и без меня знаете :)
>«Да, уже создана чертова куча языков, в том числе и для веб-платформы: PHP, Perl, Python, Ruby, Javascript в конце концов.»
А в чем смысл смешивания серверных языков и клиентского Javascript?
>«Python: Лямбда-выражения вместо лямбда-функций»
Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Сколько я писал на Django, Tornado, GAE — никогда не применял, зато часто нужны были в GTK-приложениях ;)
> А в чем смысл смешивания серверных языков и клиентского Javascript?
Почитайте про ServerSideJS, реализованный на V8. На хабре много статей. Да и JS — это для меня в первую очередь не «клиентское» или «серверное», а красивый и гибкий язык.
> Неужели в _веб-разработке_ так нужны лямбда-функции/выражения?
Ну почему бы им не быть в таком солидном языке как Python? Ведь он не только для веба используется.
JS как язык не содержит ничего, относящегося именно к браузеру. Все дело в волшебных пузырькахстандартной библиотеке — например, тот же JS используется как язык скриптинга в продуктах Adobe, которые явно не браузеры, и весьма успешно.
А учитывая скорость исполнения JS-кода виртуальной машиной V8, это не только не извращение, а вообще весьма перспективное направление.
«Родился в Москве теплым весенним днем 1989 года, с тех пор там же и живу. Сначала учился в школе английским уклоном, теперь – в МГУПИ на факультете ИТ-6 (программное обеспечение).»
Разработка интерпретатора — занятие конечно полезное, в первую очередь для себя самого. Но реальное применение ему найти будет не просто. Мой совет — либо придумывайте свой язык для конкретных задач и соответственно интерпретатор к нему, либо сводите задачу интерпретации к трансляции — то есть генерации x86/adm64 ассемблерного кода.
Придумайте, чем интерпретация (и тот факт, что при интерпретации доступно намного больше информации об исходном коде) может помочь написать инструмент лучше, чем valgrind.
А вообще применений куча, в основном это инструменты для программистов. Хороший компилятор самому или даже вдесятером написать невозможно.
За что проигнорили мою идею? В этом будет огромная польза. После Scheme, в C очень не хватает возможности просто посмореть как работает библиотека или собственный код, не создавая кучу файлов с однострочниками в main().
эм) я ничего не игнорировал, а сделал заметку в файлике:
naryl, 7 января
Здорово, если у вас получится сделать REPL по образу и подобию, например, лиспового. А если он начнёт поддерживать и C++ (в чём я сомневаюсь), то вы станете моим личным героем.
Так что ничего не забыто, спасибо за идею:) но всё-же я в чем же будет практическая ценность repl на си?
Пробовать библиотечки в деле без промежуточных сущностей в виде файлов с исходниками. Ловить очевидные ошибки в собственном коде. Демонстрировать всё это людям. Выполнять код по строчкам в repl намного удобнее, чем показывать этот процесс в gdb.
Я не вижу особо большого практического смысла. Интерпретируемый С нивелирует все плюсы и того и другого. Потому что любой компилятор С сделает бинарник, которая работает на порядки быстрее. А уже существующие интерпретатируемые языки — они все имеют более высокий уровень чем C, поэтому пользоваться ими быстрей и удобней. Только для отладки существующих программ на С, или для обучения программированию на Си «совсем с 0». Больше нет вариантов.
А почему нельзя использовать обычный компилятор, просто проверяя изменился ли код с момента последнего запуска, и если изменился — перекомпилировать и после запустить бинарник?
Например студентам показывать как не нужно писать на c++ ;)
Я бы поигрался с возможностью трансляции в другие языки (например c -> php/python).
А вообще интересно было бы проследить сколько протяните в режиме «все сам» ;)
Зверское чудо получится: на Си пишем код, который транслируется в PHP, который в свою очередь будет обрабатываться интерпретатором PHP написанным на Си. Забавно, не правда ли?
Я бы посоветовал больше использовать stl. Свои деревья, сеты и листы это конечно хорошо, но с stl дело пойдет куда быстрее, а кода станет на 15кб меньше :)
Про указатели уже сказали выше. Попробуйте изучить auto_ptr, shared_ptr (или написать свой, что тоже полезно для образовательного процесса. Описаний как этот механизм устроен — множество). Или поменьше использовать указатели — сейчас память будет сильно течь.
Отсутствие code-style. Точки с запятой после объявления функций и циклов, плавающие отступы, однострочные if-else — читать такой код очень тяжело.
Система сборки. Не у всех есть CodeBlocks. Makefile был бы к месту.
И тесты. Без них проект не сможет расти.
Я когда то писал интерпретатор близкого языка к PHP, пишите дальше, не слушайте никого, никакие умники не дадут вам того опыта, который вы получите, если будете продолжать…
CPrompt — интерпретатор языка си