Programovací jazyk

Kód rezervačního systému (klientské i serverové části) jsou napsány v jazyce C++. Ve značné míře jsou využity některé části STL, týká se to hlavně třídy řetězců, datových kontajnerů, na ně navázaných algoritmů a proudových tříd pro vstupně-výstupní operace.

Postupně (vpodstatě s pokračováním přednášky a cvičení) byly ve zdrojových souborech částečně použity i některé rysy jazyka a možnosti STL podle nové normy C++11. Při pohledu zpět by se našly další oblasti, kde by kód bylo možné vylepšit (důsledné použití nullptr, move sémantika, atd.), k přepisování hotových částí však již většinou přistoupeno nebylo.

Dle požadavku bylo zadání řešeno pro Microsoft Windows, kromě základních knihoven operačního systému a knihoven jazyka (včetně STL) nebyly použity žádné další knihovny.

Překladač

Programy byly překládány pomocí Microsoft Visual C++ verze 2012. Rezervační systém v některých částech (viz dále v sekci Operační systém) využívá přímo funkce, které nabízí Windows API. Proto ke svému běhu potřebuje příslušné knihovny operačního systému.

Bylo snahou vyhnout se konstrukcím, které by byly závislé na konkrétním překladači. Výjimku tvoří snad pouze použití makra _CRT_SECURE_NO_WARNINGS pro potlačení doporučujících varování o použití bezpečnějších Microsoft-specific funkcí jako strcpy_s místo standardního strcpy (které by však u jiných překladačů nemělo být na závadu) a použití funkce _beginthreadex, která zapouzdřuje volání API funkce CreateThread způsobem kompatibilním s běhovou knihovnou Microsoft. Stejnou konstrukci používají překladače Borland a GCC pro Windows, u jiných překladačů však pravděpodobně bude třeba úprava.

Programy lze přeložit a sestavit pro 32-bitové i 64-bitové verze operačních systémů.

Operační systém

Rezervační systém pro autobusy je určen pro operační systémy Microsoft Windows. Přesto byla snaha omezit závislost na konkrétním operačním systému na minimum a tudíž v maximální míře používat prostředky, které přináší standardizovaný jazyk. To by mělo zjednodušit případně požadovaný přenos na jiný operační systém.

Nepřenositelné záležitosti se týkají především těchto oblastí:

vlákna a jejich synchronizace - K vytváření vláken, synchronizačních objektů (ať již jde o objekty jádra nebo objekty v uživatelském prostoru) a jejich činnosti jsou využity funkce Windows API. Přestože nový standard C++11 již poskytuje přímo podporu pro vytváření vícevláknových aplikací, tyto nové rysy ještě nebyly použity.
sokety - Implementace soketů ve Windows vychází z berkleyských soketů, přesto příslušné zdrojové soubory nelze přímo přeložit např. pod UNIXovými systémy. Byla snaha vyhnout se nepřenositelným funkcím, ale již inicializace soketové knihovny (WSAStartup) tuto snahu narušuje. Odlišné je i umístění odpovídajících systémových hlavičkových souborů. Přesto by případný přenos soketové části neměl být vážnějším problémem.
meziprocesová komunikace pomocí zpráv - Z principu věci je oblast vytváření oken a vzájemná komunikace mezi nimi pomocí zpráv Windows velmi úzce spjata s tímto operačním systémem a přenos je tak vpodstatě nemožný. Na jiných operačních systémech existují podobné prostředky (např. DBus), které by mohly být použity v podobném smyslu.

Vzhledem ke skutečnosti, že kromě spustitelných souborů jsou potřeba pro činnost systému pouze konfigurační soubory (pouze pro čtení a ve stejném adresáři jako spustitelný soubor), není vyžadován ani žádný zvláštní způsob instalace (to je ostatně kromě snazší úpravy konfigurace důvodem použití takových souborů místo záznamů v registrační databázi Windows). Přizpůsobení se zvyklostem UNIXových systémů by v tomto ohledu bylo přímočaré.

Problematiky rozdílných zvyklostí při kódování znaků mimo anglickou abecedu se okrajově dotýká odstavec v následujícím oddíle.

Programy nevyužívají API funkce, které byly zavedeny po Windows XP (Service Pack 3), proto by minimálně od této verze měly správně fungovat.

Binární kompatibilita

Při meziprocesové komunikaci a při vytváření zálohy databáze se uplatňují i odlišnosti závislé na architektuře. Při případném přenosu na jinou platformu a vzájemné spolupráci částí na odlišných platformách je třeba uvážit i binární formát dat. Ten je závislý na použitém procesoru (big/little endian) i překladači a knihovnách (velikost použitých typů unsigned nebo time_t, zarovnání položek ve strukturách - RBusInfo).

Samostatnou otázkou je kódování znaků (tj. znaků národních abeced mimo anglickou abecedu). U aplikací pro Windows se závislosti na nastaveném jazykovém prostředí dá vyhnout použitím Unicode (přesněji UTF-16), u LINUXu se používá UTF-8. V případě potřeby by bylo nutné pevně stanovit stanovit i kódování znaků (UTF-8 by pak bylo pravděpodobně nejlepším řešením) pro přenos dat mezi procesy a pro zálohu databáze. Problematika na operačním systému Windows je však složitější, obecně pro non-Unicode aplikace může být kódová stránka národního prostředí odlišná od kódové stránky konzole apod. Serverová i klientská aplikace v současné době používají pro znaky typ char (a následně std::string), tedy normální (úzké) znaky. Jako dočasné provozorní "řešení" výše popsaných problémů (byl jsem např. dosti překvapen odlišným chováním konzolového kódování na Windows 7 a Windows 8) jsem otázku výběru a nastavení kódové stránky a potřebných transformací vůbec neřešil a pracuji s ceskymi názvy měst (ASCII kódy menšími než 128), snad mi to obyvatelé měst Zlin, Plzen, Ceske Budejovice a dalších dočasně odpustí.

Aplikace přeložené pomocí zmíněného Visual C++ pro 32-bitovou i 64-bitovou architekturu Intel/AMD mají stejný formát těchto dat - little-endian 4-bytový integer, 8-bytový čas (přičemž datové typy size_t pro návratovou hodnotu strlen a size_type používaný v STL např. pro počet položek v datových kontajnerech jsou v relevantních případech přetypovávány na unsigned). Díky tomu mohou vzájemně komunikovat a i soubor se zálohou databáze je vzájemně přenositelný.

V případě požadavku na vzájemnou spolupráci např. klienta na Linuxu s ARM a Windows serveru by bylo potřeba pevně stanovit binární formát dat pro meziprocesovou komunikaci a na vložené prezentační vrstvě provádět příslušné konverze (což se týká prakticky hlavně TCP přenosu). Totéž platí i pro zálohu databáze.