5.4.2. Korzystanie z parserów konfiguracji SZARP 2.1

Biblioteka IPK musi umieć parsować wszystkie pliki konfiguracyjne SZARP 2.1. Z różnych względów nie chciałem korzystać z istniejących parserów i do wszystkich napisałem własne, korzystające z programu flex. Dzięki temu parsery mają większą szansę na brak błędów (bo kod jest generowany maszynowo przez fleksa), a poza tym są dużo łatwiejsze do modyfikacji.

Parsery można oczywiście wykorzystać niezależnie od reszty biblioteki, gdyby była potrzeba pisania programu, który z jakiś względów musi parsować któryś z plików konfiguracyjnych SZARP 2.1. Interfejsy do parserów są zawarte w plikach w katalogu libSzarp2/include, są to odpowiednio:

• ekrncor.h - parser plików z opisem okien dla programu przeglądającego (ekrnXXXX.cor i ekrnXXXX.def).

• parcook_cfg.h - parser plików parcook.cfg.

• ptt_act.h - parser plików PTT.act.

• line_cfg.h - parser plików z opisami linii dla demonów linii (lineX.cfg).

• definable_parser.h - parser plików z parametrami definiowalnymi (definable.cfg), napisany w C++.

• raporter.h - parser plików konfiguracyjnych raportera, także napisany w C++.

Wszystkie parsery napisane w C, poza line_cfg.h (a więc pierwsze cztery) mają tą wadę, że nie będą poprawnie działały jeżeli w czasie jednego przebiegu programu zostaną wywołane kolejny raz (flex zapamiętuje swój stan globalnie i potem nie chce to za bardzo działać). Jeżeli będzie to problemem, trzeba będzie zmienić interfejs parserów na C++. Docelowo jednak jedynym programem korzystającym z IPK i wczytującym konfigurację w formacie SZARP 2.1 powinien być szarp2ipk, więc raczej nie będzie to konieczne.

Kolejną wadą (choć można na to różnie patrzyć) parserów jest ich większa restrykcyjność niż parserów używanych w aplikacjach SZARP 2.1, które potrafią sparsować także pliki nie do końca zgodne z deklarowanym formatem. Jest to jednak także raczej problem okresu przejściowego, dopóki wszystkie konfiguracje nie zaczną używać IPK. Poza tym są to zwykle problemy, które łatwo poprawić.