C++

Když vám váš program padá, tak je potřeba jej odladit a nalézt příčinu. Při ladění jste se již mohli setkat se situací, kdy program padá v metodě, která byla volaná přes nulový ukazatel. Přišlo vám však divné, že k pádu dojde až v těle metody, nikoliv již při volání metody. Popřípadě volání metody přes nulový ukazatel projde bez pádu. V dnešním příspěvku se dozvíte, proč k této situaci může dojít.

V srpnu tohoto roku byl schválen nový standard jazyka C++, označovaný jako C++14. Pojďme se společně podívat, co je v něm nového oproti C++11.

Dnes se podíváme na používání proměnné s nepříliš popisným názvem: flag.

Dneska se podíváme na to, jak zjednodušit odstraňování prvků z kontejneru v C++.

Pravděpodobně víte, že u for cyklů v C (od C99) a C++ lze iterační proměnnou definovat přímo v inicializační části cyklu, tedy např. for (int i = 0; ...). Dokonce lze proměnných definovat více, např. for (int i = 0, j = 1; ...). V takovém případě ale musí mít shodný typ. Co když ale potřebujeme iterovat přes více proměnných, jejichž typ se liší? Je to možné, nebo je potřeba jednu z nich definovat před cyklem? Odpověď se dozvíte v tomto příspěvku.

V příspěvku se podíváme na vhodnější alternativu za kód stylu if (obj->getItems().size() > 0) či if (!obj->getItems().empty()).

Jak jistě víte, bezznaménková (angl. unsigned) čísla v C a C++ mohou nabývat hodnot od 0 do 2^sizeof(typ) - 1. Jejich hodnota tedy není nikdy záporná. Co se ale stane, když provedete unární mínus na bezznaménkovém čísle? Něco, co zřejmě neočekáváte.

Dnes se mrkneme na podmínky, ve kterých se explicitně provádí porovnání s pravdivostní hodnotou a ukážeme si, jak je udělat čitelnější.

Občas se v projektech setkávám s komentáři, které připomínají umělecké dílo. Většinou jsou nějakým pěkným způsobem ohraničeny a jejich obsah je zarovnán podle určitých pravidel. Taktéž mnohdy obsahují nadbytečné informace jen pro to, aby vše bylo konzistentní v rámci celého projektu. Dneska se zkusíme podívat na to, jak to udělat lépe.

V dnešním díle seriálu o chybách v návrhu se podíváme na nešvar, který znepříjemňuje práci uživatelům knihoven: nekonzistentní rozhraní.