Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?
A ty víš, co v těch funkcích je? Co když blbost(30) znamená "načti 30x po sobě hodnotu z analogového čidla"? Posuzuješ kód zcela neznámého účelu takovým způsobem, aby to sedělo na tvoje tvrzení. Já dokážu taky vymyslet případy, kdy to sedí na moje. Rozdíl je v tom, že tvůj postoj je striktní a snaží se vyloučit cokoliv jiného, zatímco já hned na začátku přiznal, že ačkoliv se přikláním k jednomu způsobu, striktně na něm netrvám a dokážu si představit i jiné situace.
Tak asi bylo zřejmé, proč jsem ten příklad dával - že takhle vypadá spousta různých věcí. Například pokud by blbost(30) bylo čtení z analogového čidla a "null" znamenalo, že došlo k chybě, tak bys ten "null" do té funkce kravina() asi poslat neměl. Způsob, jak jsi ten kód napsal, v podstatě simuluje "maybe monad" a to není v C-like jazyku zrovna přehledný způsob programování.
Zásadní problém už zmínil Tuxik - GC se nadužívá.
Co to je "nadužívá"? Ano, je pravda, že spoustu věcí klidně vyřeší RAII nebo ARC. Ale co je špatné na použití GC? V 95% aplikací použití GC žádné problémy nepřinese, na druhou stranu moje zkušenost je, že jak nějakou aplikaci rozšiřuju, tak dřív nebo pozdějc narazím na něco, coby GC velmi snadno vyřešilo.
A Tuxík tady pořád šermuje s free(), takže jeho idea asi je, že i celé RAII/ARC je taky na houby....
255 Odpovědí
46816 Zhlédnutí