[PW] Zadanie 3: Kryteria naliczania pkt karnych

O1: -0,1 pkt
Przesłana paczka z rozwiązaniem zawierała niepotrzebne pliki.
Znajdywaliśmy m.in. ukryte pliki, cały .git, Hello World, testy, itp.

O2: -0,5 pkt lub -1 pkt
Plik nagłówkowy (*.h) zawierał implementacje funkcji.
Rozwiązania, które zawierały 1 lub 2 definicje funkcji w pliku nagłówkowym otrzymywały -0.5 pkt, gdy więcej: -1 pkt.

O3: -2 pkt
Całe rozwiązanie zostało zaimplementowane w pliku nagłówkowym.

O4: -1 pkt
Te same struktury były zdefiniowane dwukrotnie (zapewne kopiuj–wklej) zarówno w manager.c jak i w player.c, zamiast raz w jednym pliku nagłówkowym.

O5: -2 pkt
Całe rozwiązanie zostało zaimplementowane w funkcji main().

O6: -0,1 pkt
Plik nagłówkowy nie zawierał "#ifndef HEADER_H ..." (lub innego, równoważnego rozwiązania), które zapobiegłoby ew. wielokrotnemu wstawienia tego samego nagłówka w jednej jednosce kompilacji.

O7: -2 pkt
Rozwiązanie zawierało nieczytelnie (i niepotrzebne) użycia goto.

O8: -0,5 pkt
Niemożliwe było wczytywanie dancyh z pliku przez wielu graczy jednocześnie: player wczytywał zawartość pliku mając wyłączność (mutex).

O9: -0,5 pkt
Gracz wczytywał cały plik na raz.

O10: -0,5 pkt
Plik był otwierany i zamykany przez gracza wielokrotnie.

O11: -0,2 pkt
Używanie zmiennych globalnych.

O12: -1 pkt
Implementacja gracza nie sprawdzała, czy wywołania sem_wait() i sem_post() zakończyły się sukcesem (nie zwróciły błędu).
Rozwiązania, które w przypadku błędu wypisywały tylko komunikat i kontynuowały wykonanie (z niepoprawnymi wartościami) także otrzymywały -1 pkt.

O13: -1 pkt
Implementacja gracze nie sprawdzała, czy wywołania innych funkcji systemowych zakończyły się sukcesem (nie zwróciły błędu).
Pkt karny byl naliczany, jeśli implemetacja player nie sprawdzała wywołania ani fopen(), ani shm_open().
Rozwiązania, które w przypadku błędu wypisywały tylko komunikat i kontynuowały wykonanie (z niepoprawnymi wartościami) także otrzymywały -1 pkt.

O14: -0,5 pkt
Implementacja gracza nie zamykała dekryptora pliku pamięci współdzielonej.

O15: -0,25 pkt lub -0,5 pkt
Implementacja gracza nie zamykała plików player-*.in i player-*.out.
Rozwiązania, które zamykały tylko jeden plik, otrzymywały -0,25 pkt, gdy żadnego: -0,5 pkt.

O16: -0,5 pkt
Obsługa błędu wywołania funkcji systemowej przez gracza ograniczała się do zakończenia procesu player (exit(1)).
W przypadku błędu oczekiwaliśmy przynajmniej zadbania o usunięcie wykorzystywanych komponentów nazwanych. Najlepiej byłoby poinformować także proces manager i pozostałych graczy o błędzie (takie rozwiązania też były, brawo!).

O17: -0,25 pkt lub -0,5 pkt
Proces manager nie czekał na zakończenie się wszystkich graczy.
Imolementacja zarządcy powinna wołać funkcję wait() tyle razy, ile graczy zostało stworzonych (ile było wywołań fork()).
Rozwiązania używające wait() w sposób "hakerski" (zazwyczaj działający, ale nie w pełni poprawny) otrzymywały -0,25 pkt, pozostałe: -0,5 pkt.

O19: -1 pkt // Kryterium było źle sprawdzane.
Aktywne czekanie.

O20: -0,1 pkt
Rozwiązanie włączało zbędny plik nagłówkowy zconf.h.
"Configuration of the zlib compression library" zdecydowanie nie jest potrzebne do obsługi urodzin Bajtka.

O21: -0,5 pkt
Rozwiązanie nie rozpakowywało się do wymaganego katalogu.

O23: -1 pkt
Brak CMakeLists.txt

O24: -0,2 pkt
Rozwiązanie wymagało pliku nagłówkowego zconf.h.
"Configuration of the zlib compression library" zdecydowanie nie jest potrzebne do obsługi urodzin Bajtka.

O25: -1 pkt
Niepoprawna nazwa pliku wykonywalnego po zbudowaniu rozwiązania.

O0: -0,5 pkt
Niepoprawne wczytywanie danych lub wypisywanie komunikatów, które wymagało przesłania poprawionego rozwiązania do ponownej oceny.
Dotyczy tylko rozwiązań, które otrzymały na początku 0 pkt i komentarz "T: –".


Uwagi dodatkowe, nie punktowane, nie oznaczane:
    
W większości rozwiązań wystarczyło użycie pojedynczego pliku pamięci współdzielonej.
Użycie kilku-klikunastu takich plików wiązało się zazwyczaj z nieeleganckim kopiuj-wklej-popraw kodu obsługującego ich otwieranie i zamykanie.
Odradzamy także tworzyć pliki pamięci współdzielonej dynamicznie, dla każdego/gracza/pokoju/gry/itp.: dla dużych danych wejściowych mogłoby to zakończyć się błędem "Too many open files".

Nie wszyscy autorzy rozwiązań zadbali, aby czytając implementację gracza oczywiste było, który moment urodzin Bajtka jest realizowany przez kolejne linie kodu.
Polecamy tak podzielić rozwiązanie na dobrze nazwane funkcje, aby czytający mógł łatwo zorientować się, który etap zabawy jest przez nią realizowany. Ew., jeśli to nie wystarczy, należy użyć komentarzy.