Comments 9
Спасибо за содержательный пример TDD! Но раз уж пошла речь о интерпретации, рекомендую глянуть вот эту вот статью:
epaperpress.com/lexandyacc/download/LexAndYaccTutorial.pdf
В ней освещается хороший инструментарий, который уже имеет разделение на мощный лексер и мощный парсер, умеющий удобно разбирать грамматики, записанные в БНФ
epaperpress.com/lexandyacc/download/LexAndYaccTutorial.pdf
В ней освещается хороший инструментарий, который уже имеет разделение на мощный лексер и мощный парсер, умеющий удобно разбирать грамматики, записанные в БНФ
Благодарю за замечание. Я добавил в начало статьи параграф с объяснением, почему используется только возможности C++ и стандартной библиотеки.
Однако, замечание вообще ценное.
Слишком большое количество статей на тему реализации языков программирования большей частью состоят из рассмотрения лексического и синтаксического анализа, хотя самое интересное и сложное в реализации языков программирования лежит далеко за этими двумя этапами.
Хорошие инструменты позволяют тратить меньше времени на написание и тестирование парсеров, так как отлаживать необходимо только генератор парсеров и только его авторам. Пользователи могут считать, что генератор безошибочно переводит специфицикацию в код.
Тем не менее, суть TDD не столько в самих тестах и корректности, сколько в разработке архитектуры под тестируемость. Так что в данном случае замечения не вполне уместно. Хотя да, лично мне было бы интереснее посмотреть на разработку более поздних этапов.
Слишком большое количество статей на тему реализации языков программирования большей частью состоят из рассмотрения лексического и синтаксического анализа, хотя самое интересное и сложное в реализации языков программирования лежит далеко за этими двумя этапами.
Хорошие инструменты позволяют тратить меньше времени на написание и тестирование парсеров, так как отлаживать необходимо только генератор парсеров и только его авторам. Пользователи могут считать, что генератор безошибочно переводит специфицикацию в код.
Тем не менее, суть TDD не столько в самих тестах и корректности, сколько в разработке архитектуры под тестируемость. Так что в данном случае замечения не вполне уместно. Хотя да, лично мне было бы интереснее посмотреть на разработку более поздних этапов.
Вроде все хорошо, но почему строки по значению передаете?
А большинство push_back можно заменить на emplace_back.
А большинство push_back можно заменить на emplace_back.
TDD и прочие практики экстремального программирования мне всегда казались извращением
Программа будет писаться в Visual Studio 2013
Дальше не читал…
Всё то же самое можно сделать в Eclipse с установленным плагином C/C++ Unit, скачать Boost.Test, или GTest, скомпилировать их, прописать в путях проекта. Но в таком случае половина статьи будет касаться только настройки окружения. В Visual Studio 2012 и 2013 окружение, готовое к TDD создаётся за пару кликов. Хотя, для написания более сложных тесто, всё равно придётся ставить Boost.Test, или подобное.
Sign up to leave a comment.
Пишем простой интерпретатор на C++ с помощью TDD, часть 1