Wymagania podlegają ciągłej aktualizacji, zapraszam do regularnego sprawdzania strony.
Rozwiązanie może być napisane w stylu C jak i C++. Wymogiem jest by kod był poprawnym programem C++ oraz kompilował się przy użyciu g++.
Programy mają wczytywać dane ze standardowego wejścia, a wypisywać na standardowe wyjście.
Dla programistów "C" oznacza to m.in.:
zarządzanie pamięcią przy użyciu: "new","delete"
stosowanie się do include-ów zgodnie z treścią zadania (np. cstdio zamiast stdio.h)
stosowanie rozszerzenia ".cpp"
testowanie programu, kompilując go przy użyciu g++, a nie gcc
Zalecamy ograniczenie się do podstawowej składni, tak by kod był możliwie przenośny (docelowe środowisko testowe: Unix,Linux).
Kod ma działać niezależnie od architektury (koniecznie zarówno na maszynie 64bitowej, jak i 32bitowej.)
Tylko i wyłącznie pliki nagłówkowe: cstdio, cmath oraz wymienione w treści zadania. (lista plików nagłówkowych w wymaganiach technicznych, będzie podlegać aktualizacjom)
Tylko i wyłącznie funkcji w nich zdefiniowanych (np. np. korzystamy z funckji we/wy z cstdio, a nie iostream itd)
W zadaniach domyślnie mamy do czynienia z liczbami całkowitymi, chyba, że napisano inaczej.
Jeżeli w treści zadania, na konsultacjach, albo w trakcie zajęć, pamięć zostanie określona jako KB,MB,GB,TB,PB... mamy na myśli jednostki KiB,MiB...
Zalecenia
Przy testach wydajnościowych warto testować, własny kod, jak również, funkcje z których się korzysta - w szczególności wejścia/wyjścia (np. co jest szybsze? fscanf? czy scanf?)
Lepiej korzystać z pól pamięci (memory pools) niż ciągle alokować i dealokować małe fragmenty. Np. wiedząc, że w najgorszym przypadku będziemy potrzebować n elementów, lepiej zaalokować tablicę o danej wielkości i brać z niej elementy. Zapobiegamy w ten sposób fragmentacji pamięci, oraz zyskujemy na wydajności przy dużych testach (lepiej dokonać raz, dużej alokacji, niż mnóstwo małych w pętli).
Podczas testów, warto sięgnąć po narzędzia typu valgrind