Abyste si vyzkoušeli ukázkové příklady či zkompilovali vlastní program uvádím zde doporučení, která se týkají kompilace. Jelikož jste pravděpodobně zatím žádný program v jazyce C nenapsali, uvádím zde kód na nalezení maxima v poli dle definice (to není efektivní řešení, jistě vymyslíte lepší, případně si jej ukážeme později).
Zdrojový kód: pa1-getmax.c (ideone: http://ideone.com/SZF6lF)
Tento kód lze zkompilovat například následovně:
cc zdrojak.c -o binarka. Tento příkaz zkompiluje
zdrojak.c
do binární formy, kterou uloží do souboru
binarka
, pokud bychom neuvedli výstupní soubor, bude binární
forma uložena nejspíše do souboru a.out
.
Tímto způsobem nikdy zdrojové soubory nekompilujte,
většinou se doporučuje použít další přepínače, pro odhalení
potenciálních chyb. Tyto doporučené přepínače jsou například:
-Wall -pedantic -Wextra
. Pro účely debugování se hodí použít
navíc přepínač -g
, který přidává takzvané debugovací
znaky (proto jej budeme pro naše programy používat ve většině
případů).
Své domácí úkoly budete odevzdávat do systému Progtest (krycí název „ráj pro vaše programy“). Ten využívá kompilátor pro jazyk C++, nikoli C. Proto pro kompilaci používejte kompilátor
g++
. Drobné rozdíly jsou vidět například při alokaci dynamické paměti nebo při používání klíčového slova const.
g++ -Wall -pedantic -Wextra zdrojak.c -o binarka
Nyní umíte zkompilovat jednoduchý zdrojový kód skládající se z jednoho souboru. Kompilaci modulárního projektu můžete najít například v knize Učebnice jazyka C (Pavel Herout), případně se s ní seznámíte v navazujícím předmětu BI-PA2.
Říkáte si, že je zbytečné psát pokaždé všechny přepínače? Nejde
to jinak? Samozřejmě, že jde, ale i přesto je nutné si tyto přepínače
pamatovat. Můžete využít nějaké vývojové prostředí a nebo si můžete
vytvořit alias, který přepíše klasické chování g++
, aby
automaticky doplnil všechny parametry, kromě vstupního a výstupního
souboru. Tento alias je nutné uložit do souboru .bashrc
, jinak se
při dalším spuštění alias smaže.
Uvědomte si, že alias má ušetřit naši klávesnici, nikoli náš mozek. Musíme mít stále na vědomí, co se pod aliasem skrývá.
Nemá smysl učit se všechny chybové hlášky, ale je nezbytné umět tyto chyby číst a interpretovat. Pokud je opravdu chyba „divná“ použijeme Google. Ve skutečnosti většinou vznikne více chyb než jedna, ale často právě další chyby jsou zapříčiněny chybou první či kombinací několika chyb. Proto vždy opravujeme první chybu ve výpisu a další jen pokud jim rozumíme, zkusíme překompilovat a doufáme, že výstup bude jiný, případně poradí strýček Google.
Občas se může stát, že výpis je větší než paměť konzole. Pak je dobré přesměrovat chybový výstup do nějakého souboru.
g++ -Wall -pedantic -Wextra zdrojak.c -o binarka 2>errors.txt
Běžný uživatel či programátor by spustil program pomocí příkazu
./binarka
nebo ./a.out
. Jenže my nechceme být
běžní programátoři. Proto většinou spouštíme náš program
s ladícími (debugovacími) nástroji, které nám lépe popisují co se děje
pokud program nedělá co má.
address sanitizer
Pokud chceme použít ladící nástroje (a to my chceme vždy), tak ve
většině případů budeme muset připojit parametr -g
nebo
příslušnou knihovnu debugeru.
Žádný zdrojový kód není absolutně dokonalý, a je důležité, aby si tuto věc programátor uvědomil a věděl jak zdrojový kód vylepšit. Není cílem napsat absolutně dokonalý zdrojový kód, ale tak dobrý aby byl skoro dokonalý. Mezi chyby můžeme počítat jak prohřešky proti coding style, tak neošetřené podmínky či faktickou nefunkčnost. V neposlední řadě také můžeme hodnotit jeho použitelnost. My se budeme zabývat pouze typickými chybami, které způsobují nefunkčnost programu.
Jistě jsme zkompilovali zdrojový kód s přepínačem pro výpis debugovacích symbolů a spustili pod valgrindem. Valgrind nám na 99% řekne, kde se stala chyba, a my to jen opravíme.
Prostě se s tím smiř. Progtest není od toho, aby tě buzeroval, ale aby ti ušetřil práci. Každý správný programátor by si měl sestavit podobný testovací systém jakým je Progtest. Otestovat tedy krajní podmínky, zvláštní situace a náhodná data. Za vás to dělá Progtest, jeho nevýhodou je, že vám nezobrazí, při jakých vstupech nastala chyba. To znamená, že byste si měli sepsat vlastní „jednotkové testy“.
Základem je, že složité vstupy trvají déle, tím pádem je dobré sepsat naivní řešení, o kterém budete s jistotou tvrdit, že funguje. Například sepsání dle matematické definice. Testy mohou probíhat delší dobu, proto vám naivní řešení nevadí, ale je třeba aby testovaný kód byl rychlejší.