Такой объект имеет обычно  такой интерфейс:
Init(…);                                  создание итератора
Bool GetNextInfo();               перейти на следующую порцию данных
GetCurrData();              получить текущую порцию данных
Еще одной особенностью итератора является то, что кроме перебора данных, он всегда указывает на какую-то одну порцию данных.
Естественно, понятие курсора тесно связано с механизмом транзакций.
Действительно, с момента выполнения запроса по предоставлению курсора клиенту база ни как не блокируется и доступна для операций других клиентов. Использование транзакций позволило бы в случае конфликта вернуть базу в непротиворечивое состояние. Поэтому все действия с курсором должны быть обвернуты в транзакционные скобки.
3.Основные сведения  из BerkeleyDB
Berkeley DB – «open source» библиотека баз данных, которая обеспечивает масштабируемое, быстродействующее, управление данных, их защиту в приложении. Berkeley DB обеспечивает простой функциональный вызов API для доступа к данным и их управления для множества языков программирования, включая C, C++, Java, Perl, Tcl, Pyton, и PHP. Все операции с базой совершаются в библиотеке. Низкий уровень операций включает в себя механизм  блокировок, транзакционных блокировок, коллективного буферного управления, управления памяти и т. п.
По классификации BerkeleyDB является  навигационно-сетевой базой с возможностью перемещения по указателям структур. Однако эти указатели  являются указателями на оперативную память а не на жесткий диск, что несколько отличает ее от сетевых.
Библиотека является достаточно портативной. Она работает под почти всеми UNIX и вариантами Linux, Windows, и множеством других операционных систем в реальном времени. Она работает как на 32- бите так и 64-битовых системах.
Сама база данных библиотеки является чрезвычайно компактной (под 300 килобайтами текстового пространства в общей архитектуре), но она может управлять базами данных вплоть до 256 terabytes. Она также поддерживает высокий параллелизм, с тысячами пользователей, действующих на той же базе данных в то же самое время.
Приложения Berkeley DB содержат достаточное количество схем хранения данных, которые наилучшим образом подходят приложению. Berkeley DB поддерживает таблицы типа Hash, Btrees, простые очереди с числовым доступом к данным и устойчивые очереди. Программисты могут создать таблицы, использующие любую из этих структур памяти, и могут смешать операции в других типах таблиц в своем приложении.
Таблицы Hash обычно хороши для очень больших баз данных, когда необходим поиск и разумное время коррекции для произвольного доступа записей. Таблицы Hash позволяют  спрашивать, "этот объект существует?" или, чтобы выбирать запись с известным объектом. Таблицы Hash не позволяют, например, требовать записи с объектами, которые близки к известному объекту. Btree используется для поисков, базирующихся на диапазонах, когда приложению нужно находить все записи с объектами между некоторым начальным значением и концом. Btree также подходит для организации ссылочной зависимости. Структура Btree хранит близкие данные рядом в памяти (на диске), так что при выборе соседних величин обычно не требуется дисковый доступ. Очереди, основанные на числовой индексации записей. Каждая запись имеет уникальный номер. И поиск, удаление, изменение записи осуществляется через этот номер. Berkeley DB генерирует эти рекордные номера автоматически.
Berkeley DB поддерживает наиболее важные услуги управления данными, включая параллелизм, транзакционность и восстановление, страничное управление кэшем. Все они работают для любых вариантов хранения данных.
Berkeley DB не является сервером баз данных. Так как библиотека для работы с Berkeley загружается в адресное пространство приложения и доступно только для него. Хотя такое решение реализуемо.
Итак, Berkeley DB состоит из следующих объектов: Dbt, Db, DbEnv. Они связаны следующим образом

Dbt

Db таблица

DbEnv – база данных

 

4.Основные сведения по программной системе генерации языков программирования YAPP

 

YAPP представляет собой  программную систему с использованием Perl для генерации и использования синтаксических анализаторов LALR. Фактически это коллекция модулей расширения, написанных на Perl, совместимая с форматом YACC и позволяющих  генерировать perl-код.

Пользователь  формирует файл с грамматикой, описывающей некоторый желаемый язык. Этот файл подается на вход к yapp
yapp grammar_file.yp
На выходе получаем perl-модуль, выполняющий синтаксический анализатор языка, описываемого пользователем. То есть, фактически, yapp и генерирует синтаксические анализаторы.
Чтобы подключить синтаксический анализатор, пользователь должен подготовить уже своими силами лексический анализатор и использовать примерно такой код:
Файл грамматики
1)                Комментарии бывают в стиле Perl # или в стиле С // , /*  */.
2)                Признаки литералов и строк.
В любом  грамматическом файле могут появиться только  два типа символов: нетерминальные символы, назвавшие также лево-лежащие символы (имена  правил), и  терминальные символы названные также лексемами. Лексемы являются символами, получаемыми на выходе лексического анализатора.
Запрещено использование название «error» для литералов.
Структура его выглядит следующим образом (очень похожа на yacc, фактически является ее подмножеством)
Файл состоит из трех секций, разделенных %%:
Заголовочная секция содержит любой корректный код Perl, который копируется дословно в самое начало будущего модуля синтаксического анализатора. Это полезная вещь, например для объявления глобальных переменных.
Она содержит также декларации приоритета, представленных  %left, %right и %nonassoc(определяющ. ассоциативность).
%start указывает на правило(левую часть), выполняющееся первым.
Секция правил содержит грамматические правила:
Каждое правило состоит из слева лежащего символа (нетерминального), разделенного ':' и одним или несколькими возможными правилами, разделенными '|' и завершенными ';':
Правило справа может быть пустым
Для задания явного приоритета в случае неоднозначности  следует использовать директиву %divc, дающую правилу высокий приоритет.
5.Структура разрабатываемой программы
Идеология оболочки состоит в том, что пользователь будущей базы данных сначала описывает на специальном языке структуры данных, из которых  должны состоять таблицы в базе (то есть фактически интерфейсы) их ссылочные связи, индексы и т.п. Затем при помощи специального транслятора он получает готовый С++ код, реализующий интерфейс работы с базой данных, определенный пользователем, включая саму базу, ее таблицы, записи данных, транзакции и некоторые другие объекты. Код, генерируемый транслятором, на самом деле, является тоже оболочкой. Дело в том, что многие части транслятора имеют под собой общее основание. Эти  статические классы и функции можно выделить в библиотеку. Еще одна причина для этого – семантика самого транслятора должна быть как можно проще. И как следствие этого, сокращаются размеры генерируемых файлов.
 Полученный программный код остается только включить в проект  и использовать уже готовые объекты базы данных и таблиц.
Новая база данных должна располагать такими возможностями:
·                    Добавление пользовательских данных их модификация и удаление.
·                    Открытие базы в нескольких режимах: например, в нормальном многопользовательском транзакционном режиме, безопасном режиме (как правило, для монопольного доступа и используется утилитами), а также в режиме восстановления  базы данных.
·                    Импорта данных, то есть, представления данных в некотором текстовом формате, и их перемещение в пустую базу данных
·                    Экспорта данных, то есть, перемещение данных из базы, и представление их в определенном текстовом формате в файле, удобном для чтения. Является взаимно обратной операцией предыдущей.
·                    Проверки индексной целостности. Дело в том, что иногда, вследствие различных внешних факторов (например, перепад напряжения), теряется актуальность и корректность данных в индексных таблицах, и их необходимо периодически проверять и в случае необходимости восстанавливать.
·                    Проверки ссылочной целостности. То есть  проверка корректности логических зависимостей  между таблицами в базе.
Итак, вся оболочка состоит из следующих частей:
1.                          Собственно, базовая библиотека статических классов, для высокоуровневой работы с Berkeley, необходимая транслятору.
2.                          Транслятор, который, также является генерируемой оболочкой под типы данных пользователя вокруг библиотеки.
Библиотека классов
«Движок» представляет собой  библиотеку классов, которые с одной стороны являются надстройками вокруг стандартных соответствующих структур, а с другой стороны делают их интерфейс более удобным и   инкапсулируют часть работы транслятора. Основными компонентами являются:
·                    Транзакции
·                    Исключения
·                    Базовые записи
·                    Таблицы
·                    Базы данных
·                    Курсоры
Базовые записи
Базовая запись – это элементарная единица хранения в таблице. Описание ее класса:
//! базовый класс для записей с vtable pointer
class hbObj{
        Dbt   dbt;
protected:
        void dbtInit(uint s,void* d)
                {
                        dbt.set_flags(DB_DBT_USERMEM);
                        dbt.set_ulen(s);
                        dbt.set_size(s);
                        dbt.set_data(d);
                }
public:
        operator Dbt*(){return &dbt;}
        void*   getData(void)   {return dbt.get_data();};
        uint    getSize(void)   {return dbt.get_size();};
        hbObj()                                 {}
        virtual ~hbObj()                        {}
};
Этот класс не совсем удобен для непосредственного использования. Дело в том, что он ничего не знает об исходных данных, которые будет в себе содержать. Этими данными могут быть, например, размер структуры в памяти и некоторые ее методы. Простейшим решением будет введение шаблона с передачей типа хранимой структуры как его параметра.
//! реальный класс, который приводится к Dbt
template <class A> class hbRec:public hbObj
{
        A data;
public:
        A* getPnt(void)         { return &data;} // если в в A массив то можно переопределить   операцию & для А
        hbRec()                                 { memset(&data,0,sizeof(A));dbtInit(sizeof(A),&data);}
        hbRec(const hbRec<A>& a):data(a.data)   { dbtInit(sizeof(A),&data);}
        hbRec(const A& a)       :data(a)        { dbtInit(sizeof(A),&data);}
        void    SetData(const A& a)             { data = a;dbtInit(sizeof(A),&data);}
        virtual ~hbRec()                        {}
};
Таблицы
Диаграмма отношений существующих  таблиц приведена ниже:
 SHAPE  \* MERGEFORMAT

State- Queue

hbBasetbl

State- BTree

State- Hash

hbPTable

Final templated class hbTable<record type>

По аналогии с записями существует базовый класс таблиц hbBasetbl, который поддерживает работу со всеми стандартными типами таблиц (Hash, Btree, Queue). Фактически ее тип является ее состоянием и определяется в момент открытия.
class hbBasetbl
{
        // нужен для того чтобы set_flags вызывалась ровно один раз
        uint Set_flg_Counter;
        ushort state;
        // флаг, показывающ. открыта ли сама таблица, необходим для экстр. закрытия в случае некоректного
        // открытия
        bool tableopen;
        hbInit ini;
protected:
        uint recsize;
        uint keysize; //только для DB_HASH
        Db *table;
        virtual void    UsrOpen(hbTxn *tx,FileConf& conf,bool openidx,hbInitRt* irt = 0,u_int32_t op_flags = 0);
        virtual void    UsrClose();
        void SetRecSize(uint recsize1){recsize = recsize1;}
        void SetKeySize(uint keysize1){keysize = keysize1;}
        uint GetType()  {return ini.type;}
        bool IsDup()    {return (ini.st_flags & DB_DUP | ini.st_flags & DB_DUPSORT)>0;}
 public:
        hbEnv& env;
        operator Db*(){return table;}
        Db* operator ->(){return table;}
        const char* GetDbName(){return ini.dbname;}
        hbBasetbl(hbEnv& e,hbInit&);
        virtual ~hbBasetbl(){ if(state) Close();}
        void    Open(hbTxn *tx,FileConf& conf,bool openidx,hbInitRt* irt = 0,u_int32_t op_flags = 0);
        void    Close();
       
        virtual void    Create(hbTxn *tx,FileConf& conf,hbInitRt* irt = 0,u_int32_t op_flags = 0);
        virtual int     Get(hbTxn *tx,hbObj *key,hbObj *val,u_int32_t flags=0);  // в стиле С (без исключений)
        virtual int     Pget(hbTxn *tx,hbObj *fkey,hbObj *pkey,                          // в стиле С (без исключений)     
                                hbObj *val, u_int32_t flags=0);
        virtual int     Del(hbTxn *tx,hbObj *key,u_int32_t flags=0);           // в стиле С (без исключений)
        virtual int     tGet(hbTxn *tx,hbObj *key,hbObj *val,u_int32_t flags=0);                   // в стиле С++
        virtual int     tPget(hbTxn *tx,hbObj *fkey,hbObj *pkey,  hbObj *val, u_int32_t flags=0);     // в стиле С++
        virtual int     tDel(hbTxn *tx,hbObj *key,u_int32_t flags=0);                                     // в стиле С++
        virtual int     Put(hbTxn *tx,hbObj *key,hbObj *val,u_int32_t flags=0);
        bool IsOpen(){return state;}
};
Для ускорения доступа по какому-то критерию к данным в таблицах вводятся индексные таблицы. Ими могут быть любые из перечисленных, конечно в соответствии с их особенностями. Класс hbBasetbl является с одной стороны базовым классом, содержащим всю рутинную работу с флагами и основными операциями с таблицей, а с другой стороны -финальным классом для индексной таблицы.
Этот класс является базовым,  и совсем неудобен для работы, если эта таблица является индексированной (то есть имеет индексы – другие индексные таблицы). Необходим еще один класс, который будет обобщением понятия индексируемой таблицы и являться контейнером для таких индексных таблиц. Этот класс представлен ниже.
class hbPTable:public hbBasetbl{
        void ErrorClose();
        void eee();
        void    FixIdx(uint bulk_ret_buffer_size,int i,FileConf& conf);
void    FixIdxForQueue(uint bulk_ret_buffer_size,int i,FileConf& conf);
void    FixIdxForHash(uint bulk_ret_buffer_size,int i,FileConf& conf);
void    CheckMainToIdx(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
void CheckMainToIdxForQueue(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
void CheckMainToIdxForHash(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
void    CheckIdxToMain(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
void CheckIdxToMainForQueue(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
void CheckIdxToMainForHash(uint bulk_ret_buffer_size,bool fix,FileConf& conf);
inline void     ExportForQueue(uint bulk_ret_buffer_size,FILE* f, hbTxn* tx);
        inline void     ExportForHash(uint bulk_ret_buffer_size,FILE* f, hbTxn* tx);
        inline void     Import3(Dbt* key,Dbt* data);
        inline void     Import2(char* buf);
        inline void     Import1(FILE* f,char*& buf1,uint&);
                inline void     CheckForRefForQueue(uint bulk_ret_buffer_size);
                inline void     CheckForRefForHash(uint bulk_ret_buffer_size);
                inline uint     GetMaxRefRecBuf();
protected:
        int     sz;
        IdxItem *idx;
        RefItems ref;
        virtual void    UsrOpen(hbTxn *tx,FileConf& conf,bool openidx,hbInitRt* irt = 0,u_int32_t flags = 0);
        virtual void    UsrClose();
        inline  virtual void    ExportDBTemplate(FILE*,const char*,const char*) = 0;
        inline  virtual void    ImportDBTemplate(       char*   buf1,
                                                        uint            buf1len,
                                                        char*   buf2,
                                                        uint            buf2len,
                                                        hbObj*&         Key,
                                                        hbObj*&         Val) = 0;
public:
        //! конструктор принимает массив инициализаторов (в тч индексов)
        hbPTable(hbEnv& env,hbInit& ini1);
        virtual ~hbPTable();
        // проверка индексной целостности
        void    CheckIdx(uint bulk_ret_buffer_size,bool fix);
        // проверка ссылочной целостности
        void    CheckForRef(uint bulk_ret_buffer_size);
        void    Export(uint bulk_ret_buffer_size,FILE* f, hbTxn* tx);
        void    Import(FILE* f,char*& buf,uint&);
        virtual int     Pget(hbTxn *tx,int n,hbObj *fkey, hbObj* pkey, hbObj *val, u_int32_t flags=0)
                                                {return     idx[n].table.Pget(tx,fkey,pkey,val,flags);}
        hbBasetbl& GetIdx(int n)
                                                {return idx[n].table;}
        inline  uint    GetIdxCount()           {return sz;}
        inline  uint    GetRecSize()            {return recsize;}
};
Как видим, этот класс расширяет старый интерфейс путем введения утилитарных методов экспорта, импорта, различного рода проверок и операциями с индексными таблицами. Однако этот класс также не удобен в работе, так как не знает ничего о типах структур и ее характеристиках. Введение этих типов как параметров шаблона позволило бы очень упростить работу с интерфейсом индексируемой таблицы (но не расширить!). Результат приведен ниже:
template<class Key,class Val> class hbTable:public hbPTable
{
public:
        //! конструктор принимает массив инициализаторов (в тч индексов)
        hbTable(hbEnv& e,hbInit& ini1):hbPTable(e,ini1) {SetRecSize(sizeof(Val));SetKeySize(sizeof(Key));}
//SetRecSize use by QUEUE only
        virtual ~hbTable()              {}
        // более продвинутые функции
        int     Get(const bexcp& excp, hbTxn *tx,const Key &key,Val *val, u_int32_t flags=0)
                                        {
                                                        Get(excp,tx,(Key*)&key,val,flags);
                                        }
        int     Pget(const bexcp& excp, hbTxn *tx,int n,hbObj *fkey,Key *pkey, Val *val,u_int32_t flags=0)
                                        {
                                                MTRY
                                                        hbRec<Key> k;
                                                        hbRec<Val> v;
                                                        int z=Pget(tx,n,fkey,&k,&v,flags);
                                                       *pkey= *(k.getPnt());
                                                        *val= *(v.getPnt());
                                                        return z;
                                                CATCH_hbExcp
                                        }
        int     Del(const bexcp& excp, hbTxn *tx, const Key &key,u_int32_t flags=0)
                                        {
                                                        Del(excp,tx,(Key*)&key,flags);
                                        }
        int     tGet(const bexcp& excp, hbTxn *tx, Key *key,Val *val, u_int32_t flags=0)
                                        {
                                                MTRY
                                                        hbRec<Key> k(*key);
                                                        hbRec<Val> v;
                                                        int z = tGet(tx,&k,&v,flags);
                                                        *val= *(v.getPnt());
                                                        return z;
                                                CATCH_hbExcp
                                        }
        int     Put(const bexcp& excp, hbTxn *tx,const Key &key, const Val &val, u_int32_t flags=0)
                                        {
                                                        Put(excp,tx,(Key*)&key,(Val*)&val,flags);
                                        }
        uint    Append(const bexcp& excp, hbTxn *tx, Val *val)
                                        {
                                                MTRY
                                                        if(GetType() != DB_QUEUE) return 0;
                                                        hbRec<uint> k;
                                                        hbRec<Val> v(*val);
                                                        hbBasetbl::Put(tx,&k,&v,DB_APPEND);
                                                        return (uint&)*(k.getPnt());
                                                CATCH_hbExcp
                                        }
        uint    Append(const bexcp& excp, hbTxn *tx,const Val &val)
                                        {
                                                        return Append(excp,tx,(Val*)&val);
                                        }
};
Этот параметризированный класс на самом деле только переопределил сигнатуры методов более удобными и работающими с пользовательскими типами данных.
База данных или объект окружения
Этот объект фактически представляет  собой абстракцию базы данных: является контейнером для индексируемых таблиц, отвечает за их открытие, доступ, а также проводит над ними служебные операции экспорта  и т.п. На диаграмме это выглядит так:
 SHAPE  \* MERGEFORMAT

hbEnv

hbPTable indexed table

hbDict

hbBaseTbl index table

Описание класса приведено ниже:
class hbEnv
{
        DbEnv *env;
        bool is_native_log;
        Log* LogObj;
        //! Путь к файлам
        char* path;
        //! Количество баз - ломает вектором писать - тогда дольше компилится
        int sz;
        //! Инишиалайзеры (в количестве равном sz)
        hbInit *dbinits;
        hbInit *idxinits;
        int idxsz;
        char* schemaid; // уже проверяется, при открытии из словаря чит. оригин. и сравнивается
        //! Мутекс для транзакций
        pthread_mutex_t mx;
               uint dltype;
               //! in secs interval for checkpoints and logarchs
        ulong dldelay,bdbchkpoint,bdblogrem;
        static void* thf_deadrs(void*);
        static void* thf_chkpnt(void*);
        static void* thf_logarc(void*);
        pthread_t pth_deadrs,pth_chkpnt,pth_logarc;
        ushort stflags;
        ushort stflags;
        bool IsOpenflag;
        ushort state;
        TDictionary dict;
        //char* ConfFile; //имя конф. файла может переопределятся в потомках/ но зачем
        FILE*   OpenOutputStream(const char* fn,const char* mode);
        void    CloseOutputStream(FILE* f);
        // удаляет все __db.00x файлы т.к там хранится хэш, из-за которого может неверно сработать проверка индексов
protected:
        //! Сами тейблы, индексов здесь нет, они в самих тейблах
        hbPTable **dbs;
        void            SetSchemaid(const char* File)   {if(schemaid)free(schemaid);schemaid = strdup(File);}
        // тэйблы будут создаваться в конструкторе потомка ,и вноситься в dbs
        int Close(int);
        virtual void UsrClose();
public:
        Log* GetLog()   {return LogObj;}
        operator DbEnv*()       {return env;};
        DbEnv* operator ->()    {return env;}
        //DbEnv& GetDbEnv(){ return env;}
        const char*     GetSchemaId()const              {return schemaid;}
        const char*     GetUuid(const bexcp&, hbTxn *tx);
        const char*     GetPath()const                  {return path;}
        bool IsOpen()                   {return state;}
        hbEnv(const char *p,envInit& e,ushort flt = LL_DEBUG, Log* LogObj1 = 0);
        virtual ~hbEnv();
        //st_flags помещ. в DbEnv::set_flags (DB_TXN_NOSYNC)
        //op_flags помещ. в Db::open         (DB_PRIVATE/DB_THREAD - by default)
        // если режим CDS то эти флаги игнорируются за исключением op_flags = DB_PRIVATE!!
        void    OpenTDSMode(const bexcp& excp, u_int32_t st_flags = 0, u_int32_t op_flags = (DB_THREAD | DB_RECOVER) ) //DB_THREAD | DB_RECOVER_FATAL
                                {DBOpen(excp, OPEN_TDS,true,st_flags, op_flags);}
        void    OpenCDSMode(const bexcp& excp, bool opentables = true,u_int32_t op_flags = 0/*только для DB_PRIVATE*/)
                                {DBOpen(excp, OPEN_CDS,opentables,0,op_flags);}
        void    Close(const bexcp& excp);
        void    Close();
        // полная инициализация&создание базы с нуля (предварительное удаление БД)
        void    Init(const bexcp& excp, u_int32_t op_flags=DB_THREAD);
        // Проверка индексов и если надо их корректировка база должна быть в offline
        void CheckForIdx(const bexcp& excp, uint bulk_ret_buffer_size = (5 * 1024 * 1024),bool fix = false);
        void CheckForRef(const bexcp& excp, uint bulk_ret_buffer_size = (5 * 1024 * 1024));
        //! экспорт базы даных
        void    ExportDB(const bexcp& excp, const char* fn,uint bulk_ret_buffer_size = (5 * 1024 * 1024));
        //! импорт базы даных
        void    ImportDB(const bexcp& excp, const char* fn);
        void printf(ushort level,const char* fmt,...); // обвертка под Log::printf
};
Этот класс инкапсулирует работу со словарем, где может храниться информация, полезная для программиста.
Транзакции
Класс транзакций имеет следующий вид:
class hbTxn{
        hbEnv& Env;
        bexcp excp1;
        hbTxn* parent;
        DbTxn* Txn;
        void SetFlags(){}
        hbTxn(const hbTxn& Txn1):Env(Txn1.Env){} //copy constr
        hbTxn& operator=(const hbTxn&){return *this;}   // :=
public:
        operator DbTxn*()                                       {return Txn;};
 hbTxn(const bexcp& excp, hbEnv& env1,ullong flags = 0,hbTxn* parent1 = 0);      // младшие 32 бита это //обычн. беркл. флаги 33 бит отвечает за немедленный старт транзакции сразу же после создания
        hbTxn(const bexcp& excp, hbTxn* parent1,ullong flags = 0); 
                    // --- " ---
        ~hbTxn();
        bool HaveParentTxn()                                    {return parent!=0;}
        void Start(const bexcp&  excp,  ulong flags = 0);
        void Commit(const bexcp& excp, ulong flags = 0);
        void RollBack(const bexcp& excp);
        //void RollBack();
};
Его особенностью является то, что созданный объект транзакции нельзя копировать или создавать копированием. А также такой объект должен создаваться автоматически, то есть как стековая переменная:
try
{
         hbTxn tx(excp, parent_tx);
         // операции с базой
         tx.Commit();
}
catch(…){}
Как видим, первое - не надо заботиться об удалении объекта транзакции (при любой ситуации), второе – в случае исключения Rollback() вызовется автоматически в деструкторе этого объекта.
Транслятор
Как уже говорилось,  задача транслятора состоит в том, чтобы создать по желанию пользователя максимально удобную оболочку для библиотеки в соответствии с его определениями основных элементов базы.
Файл грамматики приведен ниже:
%%
#-------------------------------------------------------
#------  COMMENTS --------------------------------------
#-------------------------------------------------------
#id             идентификатор
#string         строковый литерал или идентификатор
#num            чиловой литерал
#float          литерал числа с плавающей точкой
#char           символьный литерал
#rawcode ::= любая последователность кода между '{*' и '*}'
file:           'end'                                                   {tblproc::Finish();}
            |   filetext 'end'                                          {tblproc::Finish();}
;
filetext:       item
            |   item filetext
;
item:           optionblock
            |   idxblock
            |   structblock
            |   enumblock
            |   codeblock
            |   tableblock
;
literal:        string                                                  {[$_[1],0]}
            |   num                                                     {[$_[1],1]}
            |   float                                                   {[$_[1],2]}
            |   char                                                    {[$_[1],3]}
;
#---------------------------------------------------------