programování

Konec října a začátek listopadu je sice obdobím polosemestrálních zkoušek, ale i přesto zkusím hodit do placu další hádanku. Za poslední tři hádanky byl průměr odpovědí čístá nula, takže i když se ani teď nikdo neozve, tak průměr neklesne. Je třeba myslet pozitivně :). Dneska se bude řešit korektní načítání čísel ze vstupu pomocí C++ proudů (streams).

Někteří o mně určitě ví, že mým oblíbeným způsobem vývoje softwaru je vývoj řízený testy (test-driven development, někdy také nazýváno test-first development - dále jen TDD). Jedním z důvodů, proč na tento přístup nedám dopustit, je to, že jeho aplikováním vzniká něco, co většina softwaru postrádá - čistý kód, který funguje.

Přínáším první hádanku v novém školním roce. Styl této hádanky bude podobný stylu předchozí hádanky, kdy se hledala potenciální chyba v programu, ovšem s tím rozdílem, že tato hádanka nebude ani tak o hledání "jazykových chyb", jako spíše o hledání návrhových chyb.

Při čtení "Dračí knihy" (Dragon book) jsem narazil u jednoho příkladu ruční implementace konečného automatu na poznámku, že nezáleží na pořadí uvedených case větví v příkazu switch, protože překladač to optimalizuje, a tudíž, i když tu nejméně pravděpodobnou variantu dáme na začátek, tak to nebude mít na výkon žádný vliv. Co se týče nezávislosti na pořadí (mimo speciální případy, např. vynechaný break), tak v jazycích C a C++ je to běžně známá záležitost, ale mě zaujala ona poznámka o optimalizaci a nedalo mi to, abych se nepřesvědčil, jak tomu ve skutečnosti je. Se svými výsledky, co se týče překladače gcc, bych se chtěl podělit v tomto příspěvku.

Dneska bych se chtěl mrknout na implicitní číselné typy v jazyce Haskell (podle specifikace z roku 1998, příklady odzkoušeny v GHC 6.10). Jak určitě víte, tak při použití funkcí jako je read :: Read a => String -> a je nutné specifikovat, co má být výsledným typem. Pokud zavoláte jenom read "143", tak překladač nedokáže automaticky odvodit konkrétní typ takového výrazu (netuší, že chcete z řetězce získat číslo typu Int). Řešením je typ výrazu explicitně zadat, čili read "143" :: Int. Tato nejednoznačnost se ale netýká jen takovýchto výrazů, ale i zdánlivě "jasných" výrazů.

Jelikož programuji a zajímám se i o jiné jazyky než je C a C++ (Python, Haskell, Java, SQL, PHP, HTML/XML, CSS, JavaScript, LaTeX, Vimscript, minoritně o Prolog či různé assemblery, dříve Pascal), tak jsem se rozhodl, že občas napíšu i nějakou zajímavost z ostatních jazyků. Nebude to nijak závazné, ani neplánuji žádný pravidelný seriál, ale když při studiu/programování narazím na nějakou zajímavost, tak ji sem možná napíšu :). Témata na tom budou (co se týče obtížnosti) různá - především se ale asi bude jednat o pokročilá témata.

Minule se mně sice nikdo s řešením neozval (nevím, zda to bylo náročností úlohy nebo prostě tím, že jsou prázdniny), ale nevadí, zkusíme jinou úlohu :). Tentokrát jsem si hádanku vypůjčil z jednoho zdroje, který a priori uvést nemohu, protože pak byste se místo samotného řešení pokoušeli hledat řešení v onom zdroji :), ale po zveřejnění řešení ho samozřejmě uvedu. Kód jsem ale mírně upravil, aby to bylo zajímavější, takže není úplně shodný. Tentokrát se budou moct zapojit i ti, kteří znají "jen" Jazyk C.

Po půl roce sucha (konečně) přináším další zajímavou programovací úlohu. Tentokrát se jedná o úlohu pro programátory v C++ a na své si přijdou především milovníci bitových manipulací :). A nebojte, nebude to žádná úloha stylu "vytvořte makro pro vzájemné prohození polovin předaného intu".

Valgrind je open-source nástroj, který slouží především pro ladění paměťových chyb (umí toho víc, např. profilování, ale tím se teď zabývat nebudu). V tomto příspěvu bych se chtěl ukázat jeho možnosti, co se týče detekce problémů při práci s pamětí a to tak, že vždy uvedu jednoduchý příklad kódu (omezím se na jazyk C, ale valgrind zvládá programy napsané v libovolném jazyce, ať už je výsledek kompilovaný či interpretovaný, ovšem hlavně se používá pro programy napsané v C a C++), ve kterém se nachází paměťová chyba a ukázku, jakým výstupem na tuto chybu zareaguje valgrind.

Většina programátorů ví o tom, že některé konstrukce mají tzv. nedefinované chování a že by se jim měli vyhýbat. Méně se ale už ví, že kromě nedefinovaného chování norma definuje další typy chování: "specifikované", implementačně závislé a nespecifikované. Po přečtení tohoto příspěvku byste měli mít jasno, jaký je mezi těmito chováními rozdíl a kterým z nich se vyhýbat.