C do AVR

optymalizacji prędkości i zajętości RAMu. Rekurencja oczywiście pomaga czasami skrócić kod, ale często iteracja jest nawet bardziej zwarta.

Waldek

Zawsze mozna znaleźć lepszy .

Skąd ta pewność ? Dla mnie wyszło zadowalająco.

Wystarczyło że poświęciłem czas na porównania . Jak wolisz wstawiać wywołania tej samej funckji n-razy to twoja sprawa . Ja tylko chciałem cię przekonać, że od razu nasuwa się skorzystanie z pętli .

To jest test algorytmu a nie projekt na zaliczenie.

Pierwsza zasada optymalizacji - nie robić jej (bez dokładnie uzasadnionej potrzeby), szkoda czasu.

zgadzam się, że rekurencja ma swoje miejsce bytu. W szczególności nie chciałoby mi się implementować trawersacji drzew czy grafów iteracyjnie, bo można przy tym supełek na członku dostać :-) Ale tam, gdzie iterację widać gołym okiem (np. konwersja int -> ascii) nie używałbym rekurencji. Wielu ludzi programując rekurencję "zapomina" o porządnym kryterium końcowym, a kontrola przepełnienia stosu też nie zawsze funkcjonuje. Co do kompilatorów, to różne są i niekoniecznie optymalizują w dobrą stronę.

Waldek

Testować to sobie możesz w domu . Tu jeśli ktoś o "słabszym" pojęciu o programowaniu w C/C++ prosi o konkretne rozwiązanie to nie podsyłasz mu algorytmu do testowania, tylko algorytm w 100% działający .

Ty o ile sobie przypominam napisałeś funkcje która zwraca string, ale kolejność cyfr jest odwrotna i piszesz koledze, żeby sobie "odwrócił" !?! A jeśli nie potrafi ? On po prostu prosił o gotowe rozwiązanie na talerzu, a nie jakieś testy .

temat uważam za zakończony

A przejrzystość kodu się też nie liczy ? Powiedz, co ty wiesz o programowaniu ?

Weźmy np. sortowanie bąbelkowe - ma chyba najbardziej przejrzysty kod z całej klasy algorytmów sortujących i jednocześnie najgorszą (tzn. największą) złożoność obliczeniową. Poza tym nie kto inny jak sam D. Knuth powiedział że "premature optimalization is the root of all evil". Ja się z tym zgadzam.

Regards, /J.D.

ok zgadzam się z Tobą , bo nie chce się kłócić :) Ale na przyszłość przysyłaj działające w 100% programy .

Jestes pewny ? Jak traktowal studentow ktorzy mu program z goto przyniesli to nie wiem, ale w Pascalu goto jednak wsadzil.

Moze to tylko "opinia publiczna" mu przypisuje ?

Ksiazki juz nie pamietam - w przykladach goto chyba nie bylo, ale czy kombinowal jak kon pod gore zeby je ominac, czy tendencyjnie dobieral przyklady - nie pamietam :-)

J.

Hmmmm... Napisałem sporo dużych aplikacji w języku, w którym goto oznacza skok do rekordu w bazie i nic poza tym. I jakoś żyję bez goto pomimo tego, że jako przedstawiciel starszego pokolenia ;-) wychowałem się na Basicu.

Ale już w Basicu goto mi przyszkadzało i przy pierwszej okazji dorwania się do implementacji bardziej rozbudowanej (BetaBasic 3.0 na Spectrumnie) zrezygnowałem ze stosowania goto.

Ale rozsadnemu programiscie goto nie przeszkadza. A jak masz za zadanie znalezc pierwszy niezerowy element w dwuwymiarowej tablicy, to omijanie goto jest zaiste zabawne ..

J.

A musisz używać do tego celu sztywnej pętli FOR? WHILE wystarczy i warunek końca da się zrobić poprawnie. Skąpisz na zmiennych?

I to wlasnie jest zabawne ... po co tak kombinowac ?

Masz prosty, efektywny i czytelny program z uzyciem goto - po kiego ch* przerabiac go na cokolwiek innego ?

J.

Kombinować? Czytelny warunek końca nazywasz kombinacją?

GOTO nigdy nie poprawiało czytelności. Sam czasem z obrzydzeniem używam EXIT do ucieczki z pętli FOR ale wcale nie uważam, że to poprawia czytelność.

Ja myśle że wszystko jest jednak dla ludzi. Nie ma powodu na zbytnie przeteoretyzowywanie dyskusji bo każdy ma tu racje, należało by jednak pamiętać o renesansowym złotym środku i nie brzydzić się goto i nie robić karkołomnych zapisów na kilka linii tylko po to żeby nie użyć goto.