Самый эффективный способ проанализировать подобные C строки определения?
Избегайте замков, где это возможно. Вместо этого используйте уникальный индекс и просто вставьте пользователя. Если пользователь или электронная почта существует, ваш запрос вернет ошибку, похожую на:
Код ошибки: 1062. Дублирующая запись 'john.doe@example.org' для ключа 'unique_email'
Это должно быть сделано с 2 отдельными индексами . Один для электронной почты, а другой для пользователей. Это имеет следующие преимущества и почти нулевые недостатки:
- Обеспечивает согласованность базы данных. Ни в коем случае 2 пользователя не будут иметь одинаковый адрес электронной почты или имя пользователя.
- Это позволяет избежать ненужных замков.
- Это позволяет избежать технического долга . Допустим, в конце вы добавите пользовательский импортер. В импортере вы не можете проверить дубликаты учетных записей или добавить блокировки, или забыли проверить, существует ли имя пользователя или адрес электронной почты. Ваш импортер будет работать, и ваша база данных теперь будет содержать записи, которые дублируют друг друга.
5 ответов
Обычно используется ANTLR (как и Lex \ Yacc).
ANTLR, еще один инструмент для языка Признание, это языковой инструмент, который обеспечивает основу для построения распознаватели, переводчики, компиляторы, и переводчики с грамматического описания, содержащие действия в разнообразие целевых языков.
Это полностью зависит от вашего определения «эффективный». Если у вас есть все время в мире, самый быстрый парсер будет рукописный парсер. Они занимают много времени для отладки и разработки, но сегодня ни один генератор синтаксического анализатора не сравнится с рукописным кодом с точки зрения производительности во время выполнения.
Если вам нужно что-то, что может анализировать действительный C в течение недели или около того, используйте генератор синтаксического анализатора. Код будет достаточно быстрым, и большинство генераторов синтаксических анализаторов поставляются с грамматикой для C, которую вы можете использовать в качестве отправной точки (избегая 90% распространенных ошибок).
Обратите внимание, что регулярные выражения не подходят для анализа рекурсивных структур. Этот подход будет медленнее, чем использование генератора, и более подвержен ошибкам, чем рукописный синтаксический анализатор.
Существует также Lemon Parser , который имеет менее строгую грамматику. Недостатком является то, что вы женаты на лимоне, переписываете грамматику парсера на что-то другое, когда обнаруживаете какое-то отстойное ограничение. Верх - это действительно простой в использовании .. и самодостаточный. Вы можете оставить его в дереве и не беспокоиться о проверке на наличие других.
SQLite3 использует его, как и несколько других популярных проектов. Я не говорю использовать его, потому что SQLite делает, но, возможно, попробуйте, если позволит время.
actually, it depends how complex is your language and whether it's really close to C or not...
Still, you could use lex as a first step even for regular expression ....
I would go for lex + menhir and o'caml....
but any flex/yacc combination would be fine..
The main problem with regular bison (the gnu implementation of yacc) stems from the C typing.. you have to describe your whole tree (and all the manipulation functions)... Using o'caml would be really easier ...
Для того, что вы хотите сделать, наши DMS Reengineing Toolkit вероятно, очень эффективное решение.
DMS разработан специально для поддержки анализаторов / генераторов кода клиентов типа, который вы обсуждаете. Он обеспечивает очень прочные средства для определения анализаторов / анализалей произвольных языков (проверены на 30+ реальных языках, включая несколько полных диалектов C, C ++, Java, C # и Cobol).
DMS автоматизирует конструкцию ASTS (так что вам не нужно ничего делать, кроме как получить грамматику, чтобы иметь возможность использовать AST), обеспечивает строительство пользовательских анализов ровноНаправленная проверка. Предварительно существующие определения C для DMS, вероятно, могут быть согнуты, чтобы покрыть ваш C-похожий язык.