Nejčastější a nejvážnější chyby v zadání
U každého komitu napište smysluplný komentář o provedených změnách.
Opravené zadání je v části branches/opravene_zadani. Je potřebné pomocí volby svn/merge (na složce trunk) verze spojit – návod je ve cvičeních (cv 6) odkaz na svn a tam odkaz na prvním řádku. Tato verze by se měla stát výchozím bodem pro další tvorbu zadání (pro výslednou dokumentaci, zadání se ještě bude měnit podle skutečné realizace).
Před editací textu zadání bylo vhodné si nakreslit diagram signatury a promyslet souvislosti dat, parametrů, návratových hodnot a činností.
Číst warningy a errory (i doxygen) a snažit se je odstranit.
Číst zadání - co má být odstraněno je nutné odstranit. Nenechávat text "například", alternativy pro jednu metodu "... nebo ...", "...".
Todo a note by se v zadání již neměly objevovat. Bug v zadání ponechte – změňte je na bugfix – dopište kdo opravil a jak.
Pro připomínky k zadání byl zvolen přepínač \bug, který je v dokumentaci zvýrazněn a všechny takto označené položky jsou také zobrazeny na zvláštní stránce - buglist. Za značkou následuje [zad], které již není značkou ale již textem - poznámkou, že tato chyba vznikla při opravě zadání.
Postup opravy chyby je následující. Nejprve je nutné opravit vlastní chybu - v zadání nejčastěji dopsat správný text, u zdrojových kódu najít správné řešení. Následně se za text popisující bug doplní že byl opraven u zdrojových kódu vysvětlit v čem byl problém, v textu by měl být i autor úpravy. Nakonec změním značku \bug na \bugfix, i tento má nastavenu svou zvláštní stránku v dokumentaci, takže je možné se podívat jaké byly problémy a jak se řešily. I bugfix zůstává v textu.
Je potřebné změnit i hlavní název projektu v horní části dokumentace (mění se v doxygen konfiguračním souboru - doxyfile).
Název projektu je i v tabulce zadání.
V tabulce zadání uvádějte funkční školní maily.
Úvodní část stránky zadání se neměla (delá) mazat, je součástí zadání a mělo se zde vyznačit (zůstat přítomno), pro které další typy k řešení jste se rozhodli.
U metod nejsou uvedeny jména (monogramy) autorů, kteří je vypracují v dalších fázích vývoje projektu.
Implicitní konstruktor slouží k plnohodnotné inicializaci objektu bez informace dodané pomocí parametrů a reprezentuje tzv. minimální inicializaci objektu (tzn. Prázdný kontejner).
Vypuštěné body zadání je nutné doplnit a vypracovat. I když v hodnocení není výslovně uvedeno, je třeba přečíst a splnit všechny body zadání, počty metod .... Hodnotit se bude nadále podle počtů a typů metod ze základního zadání (pokud jste povinnou metodu smazali, je nutné ji stejně napsat – například metody pro vkládání a vybrání prvku, konverzní operátor ...) Nedostatečný počet metod v daném bodě.
Program (projekt v adresáři project) musí fungovat i pro CNode půjčené od jiné skupiny (takže se nedá manipulovat s hodnotami "uvnitř" CNode, protože to není obecná vlastnost CNode).
Co je myšleno prvkem? Je zde skiplist, CNode, obsah CNode, CSLNode, extraInt … Na začátku textu by měl být rozbor řešení, uvedení terminologie, datové členy – potom by se lépe tvořil zbytek zadání.
Měl by se precizněji provést popis návrhu včetně jednoduchého popisu implementace. Například sčítání, odečítání a násobení front jsou operace různě interpretovatelné a proto je dobré je popsat (je také nutné si uvědomit, že k hodnotám prvků seznamu nemá kontejner přístup). Kontejner má prvek CNode a int. Kontejner má definici svou definici a činnosti "otočení" či "inverze" mohou vést ke stejnému kontejneru a tedy nedává smysl je realizovat.
Při práci operátorů je nutné říci co se děje s CNode a co s "int". Není možné napsat pouze, že to je součet, průnik. Tyto operace je nutné definovat (popsat co se děje s "obsahy" kontejnerů). Pokud to jde měly by operátory dělat činnost podobnou činnosti u základních datových typů (a ne např. "vynuluje kontejner").
Zadání by mělo být definováno „laicky“ (tj. bez detailních návazností na C++), ale přitom jako požadavek na vytvoření třídy (žádané po někom jiném). Proto by zde měly být popsány činnosti metod a operátorů konkrétněji. Nemělo by se zde objevovat „bude dělat například ... nebo ... nebo ...“
Měly by se objevit metody, které k "typu" logicky patří - Push, Pop, Top, Front, u pole a mapy operator[] …
Uvést u každé funkce/metody jak se bude jmenovat (např. pro vkládání a výběr)?
Nečlenský operátor něco dělá, ale také se nějak jmenuje (který operátor bude použit). Co je to friend operátor? Jak se ke kontejneru například přičte float?
Název třídy by měl být krátký (aby se dobře psal) ale zároveň srozumitelný.
Názvy jmenných prostorů jsou bez mezer, měly by být výstižné, ale ne zbytečně dlouhé. Určitě by měly držet konvenci názvů prostorů z již hotových tříd.
Znovu přepočítejte zda dosahujete požadovaných počtů metod (nejčastěji nesplňujete unární operátory, konstruktory a operátory). Nesplněné požadavky na počet v odevzdaném souboru zadání nejsou rozhodující, důležité je jaké požadavky byly v původní šabloně zadání.
Nelze nadefinovat neexistující operátory (ty které neznáme například pro int, neexistuje operátor $, @ …) . Existují tedy pouze ty operátory, které lze použít u základních datových typů. Při přetěžování operátoru nelze také měnit jeho aritu (počet parametrů) ani prioritu. U nečlenského operátoru je nutné specifikovat typ návratové hodnoty.
v zadáních jsou vidět jisté „školy“ (= „rodiny“ přibližně stejných textů) – snažte se pracovat samostatně – kopie budou penalizovány (a nic se nenaučíte)
kombinace aaa.metoda, Funkce(aaa), které dělají totéž, jsou zamýšleny tak, aby jste si všimli rozdílu mezi voláním metody a funkce a mezi vrácením hodnoty odkazem (u metody (proč to jde?)) a hodnotou (u funkce, co se při tom děje (proč to nejde odkazem?))). Obojí by mělo vrátit prvek stejného typu jako je prvek, který tyto vyvolal (aaa).
Konstruktorem z řetězce (stringu) je myšlen klasický řetězec C (char *, neboli pole znaků ukončené znakem ´\0´). Pro zpracování řetězce napište vlastní algoritmy, ve kterých použijete funkce: xscanf, xtoa, atox – nepoužívejte pro zpracování řetězce jiné knihovní funkce). Řetězec by měl sloužit k tisku a zadávání „pochopitelnému“ pro člověka. Proto by jeho formátování mělo být takové aby se v něm člověk snadno orientoval. Řetězec musí (měl by) mít stejný tvar při všech příležitostech (konstruktor, tisk, načítání).
Jaký je formát řetězce pro tisk, načítání? Pouhé data struktur oddělené čárkami budou (například při tisku na konzolu) značně nepřehledné.
Použití dynamických dat ve třídě – skutečně uděláte kontejner bez dynamických dat?
Dědění ve třídě – prohlédli jste si pozorně dodané zdrojové texty – jak vznikají dodané třídy?
Použití výjimek - prohlédli jste si pozorně vzorové části projektu? Budete alokovat paměť?
Poslední úpravy 2015-11-19