• prezentace: b0b36prp-lec06-slides.pdf
• zkrácená verze: b0b36prp-lec06-handout.pdf
• zkrácená verze 2×2: b0b36prp-lec06-handout-2x2.pdf
• zkrácená verze 3×3: b0b36prp-lec06-handout-3x3.pdf
• přiložené demonstrační programy: b0b36prp-lec06-codes.zip

— Jan Faigl 2025/09/19 19:04

Doplnění k HW06 “přetypování” dynamického pole na statické pole

V domácím úkolu 6 na matice je povinné zadání možné realizovat pouze s využitím proměnných typu pole (VLA). V zásadě nám stačí postupně načíst dvě matice a spočítat výsledek. Matice můžeme načíst tak, že nejdříve načteme rozměry matice a následně alokujeme matici na zásobníku jako dvourozměrné VLA pole. Problém tak dekomponujeme na funkce pro

• Načtení rozměrů matice
• Načtení matice danných rozměrů
• Tři funkce pro součet, rozdíl a násobení.

Celkově je implementace do cca 150 řádků a méně. Nemusíme řešit alokaci/dealokaci a procvičíme si práci s polem VLA.

Při implementaci volitelného zadání vystačíme se čtyřmi proměnnými pro matice a postupně načítáme matice a co je možné spočítat můžeme rovnou vyčíslit, např. v případě tří matice v součtu můžeme první dvě sečít, v případě násobení můžeme dvě matice rovnou vynásobit. Nicméně zde se nám už může hodit dynamická alokace a funkce pro načtení matice nám přímo alokuje paměť na haldě což je pohodlnější, jen pak nesmím zapomenout na uvolnění paměti voláním free(). Jestliže jsme použili pro povinné zadání VLA pole, nemusíme funkce přepisovat, ale můžeme využít faktu, že pole i vícerozměrné je souvislý blok paměti. Proto pokud alokujeme matici dynamicky jako souvislý blok paměti o velikosti počet řádku krát počet sloupců můžeme využít faktu, že proměnná pole ukazuje na první prvek podobně jako hodnota ukazatele dynamického pole.

void print(int rows, int cols, int m[cols][rows])
{
   for (int r = 0; r < rows; ++r) {
      for (int c = 0; c < cols; ++c) {
         printf("%4d", m[r][c]);
      }
      print("\n");
   }
}
...
int *matrix_p = malloc(cols * rows * sizeof(int));
int (*matrix)[cols] = (int (*)[cols]) matrix_p; 
 
print(rows, cols, matrix); // s proměnnou matrix můžem pracovat jako s dvojrozměrným polem
 
free(matrix_p);

Výhoda tohoto přístupu je, že použijeme většinu implementace z předchozího řešení povinného zadání. Celkově se implementace vejde do 180 řádků.

V případně bonusové úlohy, ale také i volitelného zadání lze s výhodou použít složený typ struct, který bude obsahovat položky definující velikost matice a vlastní data. V tomto případě se dynamické alokaci nevyhneme, proto může být výhodné kromě struktury, implementovat též funkce pro alokaci případně dealokaci. Můžete si též vyzkoušet dynamickou alokaci jako jednorozměrnné pole (souvislý blok paměti) nebo dynamickou alokaci dvourozměrného pole jako pole ukazatelů na dynamické pole hodnot. V tomto případě však nebude matice reprezentována jako souvislý blok paměti a celkově je potřeba také více paměti, tj. rows * sizeof(int*) + rows * cols * sizeof(int), protože pole řádku je pole ukazatelů na int.

Dotazy z přednášky

Q: Je nutné nebo vhodné explicitně typovat ukazatel návratové hodnoty z volání funkce malloc()?

Vyloženě nutné to v současných verzích Cčka není, přestože pro některé kompilátory (zvláště pak před standarem) to nutné bylo. V současné době je typ void* chápan jako generický ukazatel, jehož přetypování na konktrétní typ ukazatel na proměnné příslušné typu je zřejmé dle typu proměnné a není tak nutné explicitní přetypování uvádět. Jestli je vhodné explicitně přetypovat, tak na to se názory různí. Například v knize S.G.Kochan: Programming in C (3rd Edition), Sams Publishing, 2005 je uváděn malloc vždy s explicitním přetypováním:

int *a = (int*)malloc(10 * sizeof(int));

Naproti tomu v knize K.N. King: C Programming A Modern Approach, Second Edition. W. W. Norton & Company, Inc., 2008 je preferována varianta bez přetypování:

int *b = malloc(10 * sizeof(int));

Obě varianty jsou přípustné, argumenty proti explicitnímu přetypování jsou uváděny například: přehlednější kód a je to zbytečné, neboť dochází k přetypování automaticky. Na druhé straně relativně silné argumenty pro explicitní přetypování uvedené v diskusi http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc jsou například:

You do cast, because:

• It makes your code more portable between C and C++, and as SO experience shows, a great many programmers claim they are writing in C when they are really writing in C++ (or C plus local compiler extensions).
• Failing to do so can hide an error: note all the SO examples of confusing when to write type * versus type **.
• The idea that it keeps you from noticing you failed to #include an appropriate header file misses the forest for the trees. It's the same as saying “don't worry about the fact you failed to ask the compiler to complain about not seeing prototypes – that pesky stdlib.h is the REAL important thing to remember!”
• It forces an extra cognitive cross-check. It puts the (alleged) desired type right next to the arithmetic you're doing for the raw size of that variable. I bet you could do an SO study that shows that malloc() bugs are caught much faster when there's a cast. As with assertions, annotations that reveal intent decrease bugs.
• Repeating yourself in a way that the machine can check is often a great idea. In fact, that's what an assertion is, and this use of cast is an assertion. Assertions are still the most general technique we have for getting code correct, since Turing came up with the idea so many years ago.

Je to tak spíše věc osobního vkusu, preferencí, případně používaného kódovacího stylu.

Q: Jak funguje ukazatelová aritmetika v případě void*?

Přičítá se hodnota jednoho bajtu, například pro hodnotu ukazatele void *a = 0x100; bude je hodnota (a+1) rovna 0x101.

Q: Proč se říká, že reprezentace 0.1 má největší chybu?

V případě reprezentace dle IEEE-754 je strojová přesnost dána rozdílem mezi 1 a dalším reprezentovatelným číslem, která je 2^{-52}, která je v knihovně <float.h> definována jako symbolická konstanta DBL_EPSILON. S využitím např. https://www.h-schmidt.net/FloatConverter/IEEE754.html uvidíme, že hodnota 0.1 je binárně reprezentovaná jako 0-01111011-10011001100110011001101 (znaménko 1 bit, exponent 8 bitů a mantisa 23 bitů), což odpovídá nejbližšímu reprezentovatelnénu číslu 0.100000001490116119384765625. Chyba reprezentace je tak 1.490116119384765625E-9. Například v případě hodnoty 0.15 je chyba reprezentace 5.9604644775390625E-9, takže chyba reprezentace 0.1 není zas tak zásadně velká. Spíše může být překvapivé, proč číslo 0.1 má takovou chybu, když reprezentujeme hodnotu mantisou a exponentem. Důvod hledejme v reprezentaci v soustavě o základu 2. Binární reprezentaci hodnoty 0.1 najdeme dělením 2, jenže brzo zjistíme, že v rozvoji se opakuje 0011, takže přesnost reprezentace je dána počtem bitů v mantise. Proto 0.1 bude reprezentovano jinak v případně float než double. Obecně tak při přetypování dojde k chybě a proto není příliš moudré spoléhat na porovnání hodnot necelých čísel operátorem ==. Na druhou stranu, pokud do jedné proměnné double a do druhé hodnoty double přiřadíme stejné číslo, tak pochopitelně bude binární reprezentace identická a operátor == zafunguje podle očekávání. Více o reprezentaci číselných hodnot čekejte v předmětu APO.

Převod 0.1 do dvojkové soustavy (desetiná čísla dělíme 2^{-i} kde i je desetinná část což odpovídá násobení 2).
0.1 * 2 = 0.2 -> 0
0.2 * 2 = 0.4 -> 0
0.4 * 2 = 0.8 -> 0
0.8 * 2 = 1.6 -> 1
0.6 * 2 = 1.2 -> 1
0.2 * 2 = 0.4 -> 0
0.4 * 2 = 0.8 -> 0
0.8 * 2 = 1.6 -> 1
0.6 * 2 = 1.2 -> 1
0.2 * 2 = 0.4 -> 0
...

Z převodu vidíme, že 0.1 odpovídá 1.6*2^{-4} a také to, že se opakuje vzor 0011, tedy číslo 0.1 ve dvojkové soustavě nereprezentujeme přesně na konečný počet digitů.