Pytania pomocnicze - INF.04

Metoda push_back() dodaje nowy element na końcu wektora. Po każdym wywołaniu rozmiar vectora zwiększa się o 1.

Metoda `push_back()` dodaje nowy element na końcu wektora. Nie usuwa żadnych istniejących elementów.

Do wektora trafią kolejne liczby parzyste: 0, 2, 4, 6, 8, 10, 12, 14, 16, 18. Pętla wykona się dla i od 0 do 9.

Pętla wykona się 10 razy, dla wartości `i` od 0 do 9 włącznie.

Ponieważ użyto metody push_back(), która zawsze dopisuje element na końcu kontenera. Dodawanie na początku wymagałoby innej operacji, np. insert().

Zostaną dodane kolejne parzyste wartości: 0, 2, 4, 6, 8, 10, 12, 14, 16 i 18.

Pętla wykona się 10 razy, ponieważ zmienna i przyjmuje wartości od 0 do 9. Warunek i < 10 przestaje być spełniony dla i = 10.

`vector` może dynamicznie zmieniać rozmiar podczas działania programu. Zwykła tablica ma najczęściej ustalony rozmiar.

Oblicza wartość dodawaną do wektora w każdej iteracji. Dzięki temu do vectora trafiają kolejne wielokrotności liczby 2.

Do usuwania ostatniego elementu służy metoda `pop_back()`. W odróżnieniu od `push_back()` nie dodaje ona danych, tylko je usuwa.

Vector może dynamicznie zmieniać swój rozmiar i wygodnie dodawać elementy metodą push_back(). Zwykła tablica ma stały rozmiar ustalony przy tworzeniu.

Rozmiar wektora będzie równy 10, ponieważ w każdej z 10 iteracji dodawany jest jeden element.

Trzeba prześledzić kolejne wartości zmiennej sterującej i zliczyć każde wejście do bloku decyzyjnego. Liczy się także ostatnie sprawdzenie, które kończy pętlę.

Należy prześledzić kolejne wartości zmiennych dochodzących do bloku warunkowego. Liczy się każde sprawdzenie warunku, także to ostatnie, które daje wynik fałsz.

Zmienne startują od n=1, ale warunek jest sprawdzany dopiero po wykonaniu instrukcji s+=n i n++. Do bloku warunku trafiają więc kolejno wartości n: 2, 3, 4, 5, 6, 7, czyli 6 sprawdzeń.

Po każdej instrukcji `n++` sprawdzane są kolejno wartości `n`: 2, 3, 4, 5, 6 i 7. Ostatnie sprawdzenie `7 < 7` jest fałszywe, ale nadal jest weryfikacją warunku.

To pętla z warunkiem na końcu, czyli odpowiednik do...while. Jej cechą jest to, że ciało pętli wykona się co najmniej raz.

Wykonanie pętli oznacza realizację instrukcji w jej ciele. Sprawdzenie warunku to osobny krok decyzyjny, który może wystąpić również wtedy, gdy pętla już się nie wykona.

Zwiększa wartość zmiennej sterującej o 1 po każdej iteracji. Dzięki temu algorytm zbliża się do momentu, w którym warunek n<7 przestanie być spełniony.

Zapis `n++` oznacza zwiększenie wartości zmiennej `n` o 1. Jest równoważny instrukcji `n = n + 1`.

Nie, bo warunek zależy tylko od zmiennej n. Zmienna s jest tu obliczana pomocniczo, ale nie steruje zakończeniem pętli.

Zapis `s += n` oznacza dodanie wartości zmiennej `n` do zmiennej `s`. Jest równoważny instrukcji `s = s + n`.

Najlepiej zrobić tabelę z kolumnami: numer iteracji, n przed wykonaniem, n po n++, wynik warunku. Taki zapis pozwala łatwo zobaczyć, ile razy nastąpiło sprawdzenie.

Ponieważ warunek jest sprawdzany dopiero po wykonaniu wcześniejszych instrukcji. W tym przykładzie `n` zostaje najpierw zwiększone, a dopiero potem porównane z liczbą 7.

Schemat przypomina pętlę z warunkiem sprawdzanym po wykonaniu instrukcji, podobną do konstrukcji `do...while`. Najpierw wykonywany jest blok instrukcji, a dopiero potem następuje decyzja o powtórzeniu.

Kompilator tłumaczy cały program przed uruchomieniem na kod wynikowy, natomiast interpreter wykonuje kod na bieżąco, instrukcja po instrukcji. Kompilator zwykle tworzy plik wykonywalny lub kod pośredni.

Opis wskazuje na narzędzie, które sprawdza kod pod kątem błędów i generuje moduł do wykonania. To typowe zadanie kompilatora, a nie interpretera czy debuggera.

Kompilator wykrywa głównie błędy składniowe, np. brak średnika, oraz niektóre błędy semantyczne, np. niezgodność typów. Nie wykryje wszystkich błędów logicznych programu.

Debugger służy do śledzenia działania programu i znajdowania błędów podczas wykonania. Nie tłumaczy kodu źródłowego na postać zrozumiałą dla maszyny.

Kod źródłowy to program zapisany przez programistę w języku programowania, np. C++, Java lub C#. Jest czytelny dla człowieka, ale zwykle wymaga przetłumaczenia, aby mógł zostać wykonany przez maszynę.

Dekompilator próbuje odtworzyć kod wyższego poziomu z pliku wykonywalnego lub kodu pośredniego. Nie służy do tworzenia programu wykonywalnego z kodu źródłowego.

Moduł wykonywalny to wynik kompilacji, który może zostać uruchomiony przez system operacyjny albo środowisko wykonawcze. Przykładem może być plik `.exe` w systemie Windows.

Debugger służy do śledzenia działania programu i znajdowania błędów podczas jego wykonywania. Nie jest narzędziem odpowiedzialnym za tłumaczenie kodu źródłowego na kod maszynowy.

Oznacza to utworzenie pliku wynikowego, np. programu wykonywalnego albo kodu obiektowego, który może zostać uruchomiony bez ponownego tłumaczenia całego źródła.

Dekompilator wykonuje proces odwrotny do kompilacji: próbuje odtworzyć kod źródłowy lub jego przybliżoną postać na podstawie kodu wynikowego. Nie służy do tworzenia programu wykonywalnego z kodu źródłowego.

Kluczowe cechy to porównywanie sąsiednich elementów, zamiana miejscami, gdy są w złej kolejności, oraz wielokrotne przechodzenie przez zbiór aż do braku zmian.

Charakterystyczne jest cykliczne porównywanie par sąsiadujących elementów i zamiana ich miejscami, jeśli są w złej kolejności. Proces trwa do momentu, gdy w całym przebiegu nie wystąpi żadna zamiana.

Sortowanie przez wybór polega na wyszukiwaniu najmniejszego lub największego elementu w nieposortowanej części i wstawianiu go na właściwe miejsce, a nie na zamianie sąsiadów.

Ponieważ największe elementy stopniowo „wypływają” na koniec tablicy, podobnie jak bąbelki unoszące się ku górze. Przy sortowaniu rosnącym po każdej pełnej iteracji jeden z największych elementów trafia na właściwe miejsce.

W bąbelkowym zamienia się sąsiednie elementy wielokrotnie w kolejnych przebiegach. W sortowaniu przez wstawianie bierze się element i wstawia go w odpowiednie miejsce w już uporządkowanej części tablicy.

Sortowanie bąbelkowe porównuje i ewentualnie zamienia elementy sąsiadujące. Sortowanie przez wybór wyszukuje najmniejszy lub największy element w nieposortowanej części i zamienia go z elementem na aktualnej pozycji.

Quicksort działa według zasady dziel i zwyciężaj, wybiera element osiowy i dzieli zbiór na części. Nie opiera się na cyklicznym porównywaniu par sąsiadujących elementów.

Sortowanie przez wstawianie bierze kolejny element i wstawia go w odpowiednie miejsce w uporządkowanej części tablicy. Sortowanie bąbelkowe działa przez wielokrotne zamiany sąsiadujących elementów.

Oznacza to, że algorytm wykonuje kolejne przebiegi tak długo, jak długo w którymś przebiegu nastąpiła choć jedna zamiana. Brak zamian oznacza, że zbiór jest już posortowany.

W typowej wersji złożoność czasowa wynosi O(n²). W wersji zoptymalizowanej, gdy tablica jest już posortowana i algorytm wykrywa brak zamian, najlepszy przypadek może mieć złożoność O(n).

Najczęściej podaje się złożoność czasową O(n²), więc dla dużych zbiorów działa wolno. Nadaje się głównie do nauki lub bardzo małych danych.

Algorytm kończy działanie, gdy podczas pełnego przejścia przez zbiór nie zostanie wykonana żadna zamiana. Oznacza to, że wszystkie elementy są już ustawione zgodnie z kryterium sortowania.

Tak, w standardowej wersji jest stabilne, ponieważ elementy o równych wartościach nie muszą zmieniać wzajemnej kolejności.

Nie, ponieważ ma złożoność O(n²), więc dla dużej liczby elementów działa wolno. W praktyce dla większych danych częściej stosuje się algorytmy wydajniejsze, np. quicksort lub mergesort.

Bo osłabia zaufanie, utrudnia współpracę i powoduje, że cele indywidualne zaczynają być ważniejsze niż cel całego zespołu. W efekcie spada efektywność pracy.

Osłabia zaufanie, utrudnia współpracę i może prowadzić do konfliktów. Zespół działa skutecznie wtedy, gdy jego członkowie dbają o wspólny cel.

Przede wszystkim wzajemne wsparcie, terminowa realizacja zadań, dobra komunikacja i branie odpowiedzialności za własne decyzje. Takie postawy budują zaufanie i porządek pracy.

Odpowiedzialność oznacza terminowe wykonywanie zadań, przyznawanie się do błędów, informowanie o problemach i ponoszenie konsekwencji własnych decyzji.

To gotowość do ponoszenia skutków swoich działań, przyznawania się do błędów i reagowania na problemy. Odpowiedzialna osoba nie unika konsekwencji i nie przerzuca winy na innych.

Wzajemne wsparcie pozwala szybciej rozwiązywać problemy i zmniejsza ryzyko opóźnień. Pomaga też budować dobrą atmosferę pracy.

Ponieważ zadania członków zespołu są często ze sobą powiązane. Opóźnienie jednej osoby może zablokować pracę pozostałych i zagrozić realizacji całego projektu.

Opóźnienie jednego zadania może zablokować pracę innych osób, np. testerów lub programistów zależnych od danego modułu. Terminowość ułatwia utrzymanie harmonogramu projektu.

Pomaga szybciej rozwiązywać problemy, zmniejsza liczbę błędów i poprawia atmosferę współpracy. Dzięki temu zespół działa sprawniej i skuteczniej.

W pracy indywidualnej osoba odpowiada głównie za własny wynik. W pracy zespołowej ważne są komunikacja, koordynacja działań i odpowiedzialność za wspólny rezultat.

Najczęściej po braku współpracy, ignorowaniu ustaleń, unikaniu odpowiedzialności i koncentrowaniu się tylko na własnym interesie. Takie zachowania utrudniają osiąganie wspólnych celów.

Dobra komunikacja ogranicza nieporozumienia, pozwala szybciej wykrywać problemy i ułatwia podział zadań. Brak komunikacji często prowadzi do błędów i opóźnień.

Funkcja jest rekurencyjna, gdy w swoim ciele wywołuje samą siebie. Musi też mieć warunek zakończenia, aby nie wykonywała się w nieskończoność.

Rekurencję rozpoznaje się po tym, że funkcja wywołuje samą siebie. W przykładzie `fn` rekurencja występuje, gdy wewnątrz funkcji pojawia się wywołanie `fn(a - 1)`.

Ponieważ funkcja fn wywołuje samą siebie w instrukcji return: fn(a-1)+2. To jest bezpośrednie wywołanie rekurencyjne.

Przypadek bazowy to warunek, który kończy dalsze wywołania funkcji. Bez niego rekurencja mogłaby działać bez końca.

W Bloku 2 nie ma wywołania funkcji fn wewnątrz jej ciała. Wykonywane jest tylko zwykłe obliczenie arytmetyczne.

Ponieważ funkcja `fn` zawiera wywołanie samej siebie: `fn(a - 1)`. Dodatkowo ma warunek zakończenia `if(a == 1) return 1;`.

Funkcja fn wywołuje tam fun, a nie samą siebie. Rekurencja zachodzi tylko wtedy, gdy funkcja odwołuje się do własnej nazwy lub uczestniczy w rekurencji pośredniej.

W bloku 2 funkcja nie wywołuje samej siebie. Wyrażenie `(a - 1) + 2` jest zwykłym obliczeniem arytmetycznym.

To warunek stopu, czyli przypadek bazowy. Dzięki niemu kolejne wywołania kończą się i funkcja może zwrócić wynik.

W bloku 3 wywoływana jest funkcja `fun(a - 1)`, a nie `fn(a - 1)`. Nie jest to więc bezpośrednie wywołanie tej samej funkcji.

Funkcja wywoływałaby się bez końca albo do wyczerpania pamięci stosu. W praktyce prowadzi to do błędu przepełnienia stosu.

Funkcja będzie wywoływać się coraz dalej, aż może dojść do przepełnienia stosu wywołań. Program może wtedy zakończyć się błędem.

fn(3) wywołuje fn(2)+2, a fn(2) wywołuje fn(1)+2. Ponieważ fn(1)=1, otrzymujemy fn(2)=3 i fn(3)=5.

Każde wywołanie funkcji rekurencyjnej trafia na stos wywołań. Gdy osiągnięty zostanie przypadek bazowy, kolejne wywołania są zdejmowane ze stosu i zwracają wyniki.

Activity to podstawowy komponent aplikacji Android odpowiedzialny za pojedynczy ekran i interakcję z użytkownikiem. To właśnie ona najczęściej wyświetla interfejs i obsługuje działania użytkownika.

Activity reprezentuje pojedynczy ekran aplikacji i umożliwia użytkownikowi interakcję z programem. Odpowiada za wyświetlanie widoku oraz obsługę zdarzeń.

Activity reprezentuje samodzielny ekran aplikacji, natomiast Fragment jest tylko częścią interfejsu osadzaną zwykle wewnątrz Activity. Fragment nie działa jako główny, niezależny ekran bez powiązania z Activity.

W Androidzie podstawowym pojęciem ekranu aplikacji jest Activity. `Windows` nie jest standardową klasą używaną w Androidzie jako główny element komunikacji z użytkownikiem.

Fragment służy do budowy modularnych części interfejsu, które można wielokrotnie wykorzystywać w różnych ekranach. Ułatwia to organizację kodu i dostosowanie widoku do różnych urządzeń.

Activity oznacza cały ekran aplikacji, natomiast Fragment jest częścią interfejsu działającą zwykle wewnątrz Activity. Fragment nie jest podstawowym samodzielnym ekranem aplikacji.

Activity wyświetla układ interfejsu, reaguje na zdarzenia, takie jak kliknięcia, oraz zarządza logiką ekranu. Dzięki temu pośredniczy między użytkownikiem a działaniem aplikacji.

`onCreate()` jest wywoływana podczas tworzenia Activity. Najczęściej ustawia się w niej layout ekranu za pomocą `setContentView()` i inicjalizuje elementy interfejsu.

Nie, screens to jedynie ogólne określenie ekranów aplikacji. W Androidzie klasą odpowiedzialną za ekran jest Activity.

Cykl życia Activity to zestaw metod wywoływanych w różnych stanach ekranu, np. przy tworzeniu, uruchamianiu, wstrzymaniu i niszczeniu. Pozwala poprawnie zarządzać zasobami aplikacji.

Windows nie jest podstawową klasą aplikacji Android służącą do komunikacji z użytkownikiem. W Androidzie rolę ekranu aplikacji pełni Activity.

Tak, aplikacja może składać się z wielu Activity, z których każda reprezentuje inny ekran, np. ekran logowania, listę danych lub szczegóły rekordu.

Cykl życia Activity określa, co dzieje się z ekranem podczas uruchamiania, wstrzymywania, zatrzymywania i zamykania. Jest kluczowy dla poprawnego zarządzania zasobami i stanem aplikacji.

Activity wyświetla interfejs użytkownika i reaguje na zdarzenia, takie jak kliknięcia przycisków, wpisywanie tekstu czy wybór elementów listy.

Postinkrementacja najpierw zwraca obecną wartość zmiennej do porównania, a dopiero potem zwiększa ją o 1. Dlatego w warunku używana jest stara wartość, ale wewnątrz pętli zmienna ma już wartość większą.

Najpierw używana jest aktualna wartość zmiennej w wyrażeniu warunkowym, a dopiero potem zmienna jest zwiększana o 1. Dlatego w ciele pętli wartość może być już większa niż ta porównywana w warunku.

Ponieważ w warunku użyto a++, więc po sprawdzeniu warunku zmienna a zostaje zwiększona. Gdy program wchodzi do ciała pętli po pierwszym sprawdzeniu, a ma już wartość 2.

`a++` zwraca starą wartość i potem zwiększa zmienną. `++a` najpierw zwiększa zmienną, a potem zwraca nową wartość.

Trzeba dla każdej iteracji zapisać wartość a przed sprawdzeniem warunku, wynik porównania oraz wartość a po inkrementacji. To pozwala zobaczyć, jakie liczby są wypisywane i kiedy pętla się kończy.

Warunek używa `a++`, więc po sprawdzeniu warunku zmienna `a` jest już zwiększona. Pierwszy warunek sprawdza `1 < 6`, ale wypisywana jest już wartość `2`.

Pętla kończy się, gdy porównanie a++ < 6 zwróci fałsz. Dzieje się to przy sprawdzeniu starej wartości 6, choć po inkrementacji a staje się wtedy równe 7.

Kończy się, gdy porównywana stara wartość `a` nie spełnia warunku `< 6`. Dla `a = 6` warunek `6 < 6` jest fałszywy, więc ciało pętli nie wykona się.

a++ zwraca starą wartość i potem zwiększa zmienną, a ++a najpierw zwiększa zmienną, a potem zwraca nową wartość. W warunkach pętli ta różnica często zmienia wynik programu.

Po zakończeniu pętli `a` ma wartość `7`. Ostatnie sprawdzenie warunku używa wartości `6`, ale operator `a++` zwiększa ją jeszcze do `7`.

Wtedy zmienna byłaby zwiększana przed porównaniem, więc wypisane zostałyby liczby 2 3 4 5. Pętla zakończyłaby się wcześniej niż w wersji z postinkrementacją.

Najlepiej rozpisać kolejne iteracje w tabeli: wartość przed warunkiem, wynik warunku, wartość w ciele pętli i wartość po iteracji. To ogranicza pomyłki przy operatorach `++`.

Tabela pomaga uniknąć pomyłek przy operatorach inkrementacji, warunkach i zmianach wartości zmiennych. To najprostszy sposób na poprawne ustalenie wyniku działania programu.

To przekazywanie informacji za pomocą słów, czyli mowy lub pisma. W tym pytaniu przykładem komunikacji werbalnej jest mówienie.

Komunikacja werbalna wykorzystuje słowa, np. mówienie lub pisanie. Komunikacja niewerbalna przekazuje informacje bez słów, np. przez gesty, mimikę i postawę ciała.

Mówienie polega na przekazywaniu informacji za pomocą słów wypowiadanych ustnie. Dlatego jest podstawowym przykładem komunikacji werbalnej.

Wyraz twarzy przekazuje emocje i nastawienie bez użycia słów. Jest więc elementem komunikacji niewerbalnej.

Gestykulacja wykorzystuje ruchy ciała, a nie słowa. Jest więc elementem komunikacji niewerbalnej.

Postawa ciała może pokazywać pewność siebie, stres, dystans lub zainteresowanie, ale nie wykorzystuje słów. Dlatego należy do komunikacji niewerbalnej.

Programista musi jasno omawiać wymagania, zgłaszać problemy, wyjaśniać rozwiązania i współpracować z zespołem. Nieprecyzyjna komunikacja może prowadzić do błędów w projekcie.

Gestykulacja wspiera wypowiedź lub samodzielnie przekazuje znaczenie bez słów. Z tego powodu jest zaliczana do komunikacji niewerbalnej.

Są to rozmowy na spotkaniach, prezentowanie postępów pracy, zadawanie pytań, pisanie wiadomości e-mail oraz tworzenie dokumentacji.

Pomaga lepiej rozumieć intencje rozmówcy i unikać nieporozumień. W zespole liczy się nie tylko to, co ktoś mówi, ale też jak się zachowuje.

Tak. Komunikacja werbalna obejmuje nie tylko mowę, ale też przekaz pisemny, ponieważ w obu przypadkach używane są słowa.

Jeśli odpowiedź dotyczy gestów, mimiki, postawy ciała, kontaktu wzrokowego lub wyglądu, najczęściej chodzi o komunikację niewerbalną.

Pole tekstowe to prostokątne miejsce do wpisywania danych przez użytkownika. W tym zadaniu służy do wprowadzenia liczby, więc w WPF będzie to TextBox, a w Swing JTextField.

TextBox służy do wprowadzania i edycji tekstu przez użytkownika. Może być używany np. do wpisania liczby, loginu lub krótkiej informacji.

Obie kontrolki służą do wprowadzania tekstu, ale pochodzą z różnych bibliotek i mają inną składnię użycia. TextBox stosuje się w aplikacjach WPF, a JTextField w aplikacjach Java Swing.

JTextField to jednowierszowe pole tekstowe w bibliotece Swing. Użytkownik może w nim wpisać dane, które program odczytuje metodą getText().

Window i JFrame oznaczają całe okno aplikacji, a nie pojedyncze pole do wpisywania danych. Text nie jest standardową kontrolką wejściową do edycji tekstu przez użytkownika.

TextBox umożliwia użytkownikowi wpisywanie danych, a Label zwykle służy tylko do wyświetlania opisu lub informacji. Etykieta nie jest typowym polem wejściowym.

TextBox umożliwia użytkownikowi wpisanie danych, np. liczby, imienia lub hasła. Program może potem odczytać tę wartość i dalej ją przetwarzać.

Tekst odczytuje się z właściwości Text, np. txtLiczba.Text. Wynik jest typu string, nawet jeśli użytkownik wpisał liczbę.

Użytkownik wpisuje wartość do pola tekstowego, a po kliknięciu przycisku program odczytuje zawartość kontrolki. Następnie może sprawdzić poprawność danych lub wykonać obliczenia.

Należy użyć metody getText(), np. txtLiczba.getText(). Zwrócona wartość jest tekstem typu String.

W WPF używa się znacznika TextBox w XAML, np. <TextBox Width="120"/>. W Swing tworzy się obiekt JTextField, np. JTextField pole = new JTextField(10);

Pole tekstowe przechowuje dane jako ciąg znaków. Jeśli program ma wykonać obliczenia, tekst trzeba przekonwertować na typ liczbowy, np. int lub double.

Pole tekstowe zwykle wygląda jak pusty prostokąt przeznaczony do wpisania danych. Często znajduje się obok lub pod etykietą z instrukcją, np. „Wprowadź liczbę”.