Парсер-генератор ANTLR лучше всего для приложения C++ с ограниченной памятью?
Вы можете сделать следующим образом:
import SellerAdaptor from '../adaptors/sellers';
import UserAdaptor from '../adaptors/user';
import ShopEarnAdaptor from '../adaptors/shop_earn';
import ProductAdaptor from '../adaptors/product';
import JobAdaptor from '../adaptors/job';
import OrderAdaptor from '../adaptors/order';
import NotificationAdaptor from '../adaptors/notification';
import CategoryAdaptor from '../adaptors/category';
import AdminAdaptor from '../adaptors/adminAdaptor';
export {
SellerAdaptor,
UserAdaptor,
ShopEarnAdaptor,
ProductAdaptor,
JobAdaptor,
OrderAdaptor,
NotificationAdaptor,
CategoryAdaptor,
AdminAdaptor
}
И затем вы можете импортировать, как показано ниже
import { SellerAdaptor, UserAdaptor} from './<filename>'
6 ответов
ANTLR 3 не поддерживает C ++; это утверждает генерировать прямой C, но документы на заставить его на самом деле работать вроде сбивает с толку.
Он генерирует C, и, кроме того, он работает с Visual Studio и C ++. Я знаю это, потому что я делал это раньше и представил патч, чтобы заставить его работать с stdcall.
Память имеет огромное преимущество в нашем приложении и даже крошечные утечки смертельны. я нуждаюсь чтобы иметь возможность переопределить парсер Распределитель памяти, чтобы использовать наш пользовательский malloc () или, по крайней мере, мне нужно дать ему непрерывный бассейн из который он тянет всю свою память (и который я могу освободить в блоке впоследствии). Я могу сэкономить около 200 КБ для самого исполняемого файла парсера, но какую бы динамическую кучу он ни выделил в после этого парсинг должен быть освобожден.
Во время выполнения antlr3c, в прошлый раз, когда я проверял, нет утечки памяти, и используется парадигма пула памяти, которую вы описываете. Однако у него есть один недостаток в API, который автор отказывается изменить, а именно: если вы запрашиваете строку узла, он будет каждый раз создавать новую копию, пока вы не освободите весь анализатор.
У меня нет прокомментируйте простоту использования пользовательского malloc, но в нем есть макрос для определения того, какую функцию malloc использовать во всем проекте.
Что касается размера исполняемого файла, размер моей компиляции составлял около 100 КБ, включая небольшой интерпретатор.
Я предлагаю вам продолжать изучать ANTLR, потому что он все еще соответствует вашим требованиям, и вам, вероятно, нужно пожертвовать немного больше времени, прежде чем он начнет работать на вас.
Мы успешно используем Boost Spirit в нашем приложении. Повышающая лицензия является очень либеральной, поэтому нет проблем с ее использованием в коммерческих приложениях.
Spirit - это реализованная объектно-ориентированная среда генератора парсеров с рекурсивным спуском используя методы метапрограммирования шаблонов. Шаблоны выражений позволяют нам полностью аппроксимировать синтаксис расширенной формы Backus-Normal (EBNF) в C ++. Платформа Spirit позволяет писать целевую грамматику исключительно на C ++. Встроенные спецификации грамматики EBNF могут свободно смешиваться с другим кодом C ++ и, благодаря мощным возможностям шаблонов C ++, могут быть немедленно выполнены. Оглядываясь назад, обычные компиляторы-компиляторы или парсеры-генераторы должны выполнить дополнительный шаг трансляции из исходного кода EBNF в код C или C ++.
Проблема:
В Lgi.dll определен другой класс, который экспортирует экземпляр GArray.
#ifdef LGI_DLL
#define LgiClass __declspec(dllexport)
#else
#define LgiClass __declspec(dllimport)
#endif
class LgiClass GToken : public GArray<char*>
{
/// stuff...
};
Решение:
Включите этот заголовок GToken в мой EXE-файл, в частности файл FrameStore.cpp, который использует реализацию GArray, тогда компиляция будет импортировать эти символы из DLL, а не дублировать их.
Было бы неплохо, если бы компилятор мог бы дать мне больше подсказки о том, где DLL определяет символ. Простое высказывание «где-то дубликат» не очень полезно.
У вас есть настоящая грамматика для этого? Он выглядит , как будто его легче всего анализировать с помощью рукописного синтаксического анализатора рекурсивного спуска, но это не очень хороший пример.Упс, моя ошибка, поскольку ANTLR, очевидно, генерирует рекурсивный спуск. Тем не менее, у меня были проблемы с генерацией больших парсеров ANTLR.
Тогда почему бы вам не использовать flex / yacc? Он генерирует код на C, может быть запущен из MSVC, разработан с учетом эффективности, может иметь переопределение malloc (google для yymalloc), они сами являются GPL, но полученный код (код, который вы используете в своем проекте) AFAIK нет.
Или используйте ручной анализатор.
На самом деле, если ваша грамматика относительно мала и не содержит много двусмысленностей или сложностей синтаксического анализа, то не имеет значения, используете ли вы синтаксический анализатор с рекурсивным спуском или синтаксический анализатор с уменьшением сдвига.
Я бы сказал, посмотрите на ANTLR и Spirit, также посмотрите на Flex и Bison. Есть другие,
Кодированный вручную рекурсивный анализатор спуска на самом деле довольно быстр и может быть очень компактным. Единственный недостаток - нужно быть осторожным кодировать по существу LL (1) грамматики. [Если вы используете ANTLR, у вас есть аналогичные ограничения, так что это не такая уж большая проблема].
Вы можете передать такие парсеры, как простой рекурсивный код C. (См. Этот ответ для получения полной информации: Есть ли альтернатива для flex / bison, которая может использоваться в 8-битных встроенных системах? )
Если у вас действительно мало места, вы можете определить синтаксический анализ виртуальную машину и создайте крошечный интерпретатор C для ее запуска. Я так строил интерпретаторы BASIC еще в начале 70-х.
Придерживаясь очень простых соглашений, которые делают эти парсеры действительно работают, вы можете гарантировать, что есть нет утечки памяти, вызванной механизмами синтаксического анализа. (Конечно, вы можете прикрепить к парсеру произвольные действия, если он распознает предметы интереса; утечка этих действий - вопрос общего программирования, а не парсера).
Идея пришла из статьи Вэла 1964 года о метакомпиляторах. Шорре, который показывает, как создавать полные компиляторы на 10 страницах. Крошечный генератор парсера Шорре производит довольно хороший рекурсивный спуск парсеры. Сайт, описывающий эту статью и показывая, как именно создавать такие парсеры, можно найти на http://www.bayfronttechnologies.com/metaii.html
Я использовал методы Шорре для создания компиляторов Basic в конце 70-х, после того, как я устал вручную писать сложные грамматики.