Ĺadny brzuch
Witam, mam mały problem, a mianowicie dotyczy on podanej poniżej przykładowej pętli:
for(int i =0; i < 0; i++)
{
.
.
}
Chciałbym, wiedzieć czy w zastosowanej pętli ma znaczenie po której stronie zmiennej i dam plusy(gdybym zamienił i++ na ++i)? Zmieni to przebieg albo wynik działania pętli?
i++ - dodaje po wykonaniu petli
++i - dodaje przed wykonaniem petli
Użytkownik RoboKomp edytował ten post 01 sierpień 2006, 17:01
Moim zdaniem akurat w pętli for to nie ma znaczenia i RoboComp blefuje.
for(int i =0; i < 0; i++) - oznacza to, ze przy kazdym przejsciu petli wartosc "i" zostanie zwiekoszna o 1, a w petli to nie ma znaczenia, czy przed czy po.
Użytkownik Ronswer edytował ten post 01 sierpień 2006, 17:12
MA znaczenie. Przy i++ jest tworzony obiekty tymczasowy, nadawana mu wartość obiektu głównego, wartość obiektu głównego zwiększana i zwracany obiekt tymczasowy. Jako że cała instrukcja to tylko i++, więc wartość jaką miała przed zwiększeniem idzie w powietrze.
Przy ++i powoduje zwiększenie wartości i jej zwrócenie. koniec.
Co za tym idzie zastosowanie w pętli ++i JEST szybsze, ale wzrost wydajności jest raczej zbyt mizerny, by sobie zmieniać nawyki...
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Użytkownik JaskMar edytował ten post 02 sierpień 2006, 09:53
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Ktoś nie uczył się uważnie C++ <_< sprawdźL
http://informatyka.s...a_liczbach.html
Umieszczenie operatora ++ (--) przed wyrażeniem nazywamy preinkrementacją (predekrementacją). W takiej sytuacji najpierw dokonywane jest zwiększenie (zmniejszenie) jego wartości o 1. Nowa wartość jest potem zwracana jako wynik.
Kiedy napiszemy operator ++ (--) po wyrażeniu, mamy do czynienia z postinkrementacją (postdekrementacją). W tym przypadku najpierw następuje zwrócenie wartości, która dopiero potem jest zwiększana (zmniejszana) o jeden2.
A ponieważ przy asembleracji instrukcja jest wklejana w całości do pętli, to MA znaczenie czy użyjemy pre, czy post.
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Jak możesz pisać w ogóle takie rzeczy jak nie masz pewności teog co mówisz :mad:
Według Ciebie jaka to w ogóle wygoda jest?
Chciałbym, wiedzieć czy w zastosowanej pętli ma znaczenie po której stronie zmiennej i dam plusy(gdybym zamienił i++ na ++i)? Zmieni to przebieg albo wynik działania pętli?
Możesz być spokojny, nie zmieni się wynik działania tej pętli (dla 100 % pewności sprawdziłem to przed chwilą). Tylko jak napisał to wyżej @ Real_Noname jeśli napiszesz ++i to będzie szybciej wykonywała się pętla, choć napewno tego nie zauważysz. ;)
Dodam jeszcze na marginesie coś takiego, aby była pełna jasność:
++ zwiększenie wartości o 1, np. i++ to jest to samo co i=i+1 -- zmniejszenie wartości o 1, np. i-- to jest to samo co i=i-1 Należy jednak zwrócić uwagę, że operatory te można stosować przed i po zmiennej, tzn. liczba++ lub ++liczba. Podobnie jest z operatorem dekrementacji --. Mimo, że działanie operatora w obu wypadkach jest podobne, to nie jest jednak identyczne! Aby to wyjaśnić, muszę Ci zdradzić, że w języku C/C++ prawie każde wyrażenie zwraca jakąś wartość. Np. operacja 5+6 zwraca liczbę 11, i dzięki temu int liczba=5+6; powoduje przypisanie zmiennej liczba wartości 11. Operatory ++ i -- również zwracają wartość, z tym tylko, że jeśli operator znajduje się przed zmienną, to zwraca wartość zmiennej po zwiększeniu(zmniejszeniu), a jeśli znajduje się po zmiennej, to zwraca wartość zmiennej przed wykonaniem operacji zwiększenia(zmniejszenia). Jednak wartość zmiennej w obu przypadkach będzie taka sama.
Użytkownik Dj Kamil edytował ten post 02 sierpień 2006, 14:39
Dla przykładu kod:
#include <stdio.h> void main(){ int i=5; printf("%d\n", i); printf("%d\n", i++); printf("%d\n\n", i); i = 5; printf("%d\n", i); printf("%d\n", ++i); printf("%d\n", i); }
printf z i++ wypisze 5, ten z ++i 6.
Natomiast w przypadkach takich jak np 'i++;' w kodzie, obie instrukcje sa homonimami - dokladnie identyczne. (zadna nie jest szybsza-to jest to samo i w sensie logicznym, jak i w instrukcjach procesora). Tak samo w takiej petli jak for jak w pierszwym poscie-dokladnie to samo, zadnej roznicy szybkosci czy czegos innego.
Mam nadzieje ze to juz wszystko wyjasnilo.
Użytkownik Fr3m3n edytował ten post 02 sierpień 2006, 16:48
Sprawdziłem, w tym znaczeniu w pętli for nie ma różnicy. Oto kod, możecie sami sobie skompilować:
#include <iostream> using namespace std; int main(int argc, char *argv[]) { cout << "Efekt z uzyciem i++: "; for (int i = 0; i < 5; i++) { cout << i << " "; } cout << "\nEfekt z uzyciem ++i: "; for (int i = 0; i < 5; ++i) { cout << i << " "; } }
A oto wydruk:
Efekt z uzyciem i++: 0 1 2 3 4
Efekt z uzyciem ++i: 0 1 2 3 4
Napisałem taki kod w c++:
int main(){ int a=0; for(int i=0; i<5; i++) a+=2; for(int i=0;i<5; ++i) a+=3; a=a++*++a; return a-a; }
Skompilowałem to za pomocą bcc32 z parametrem -B. A w asemblerze wygląda to wtedy tak (fragment, ale ten znaczący):
?live16385@32:; EAX = a @2: xor edx,edx ?live16385@48:; EAX = a, EDX = i @3: add eax,2 @5: inc edx cmp edx,5 jl short @3 ?live16385@80:; EAX = a @7: xor edx,edx ?live16385@96:; EAX = a, EDX = i @8: add eax,3 @10: inc edx cmp edx,5 jl short @8 ?live16385@128:; EAX = a inc eax mov ecx,eax imul ecx,eax mov eax,ecx inc eax mov edx,eax sub edx,eax mov eax,edx ?live16385@160:; @13: @12: pop ebp ret
Jak widać w tym kodzie nie ma znaczenia, cze w pętli jest ++i, czy i++. Dalej przy operacjach a++, ++a też nigdzie nie widzę, żeby była tworzona dodatkowa zmienna, zwracany wynik, czy coś takiego. Różnica polega tylko na sekwencji inkrementacji.
Ten wynik jest dla konkretnego kompilatora, więc nie twierdzę, że inne nie robią tego inaczej. Ale ten kod w asemblerze wygląda pod tym względem logicznie, więc na dzieńdzisiejszy ja pozostaję w przekonaniu, że zapis ++i nie będzie w pętli szybszy niż i++.
:) Teraz juz rozumiem dzeki serdecznie za pomoc
Natomiast w przypadkach takich jak np 'i++;' w kodzie, obie instrukcje sa homonimami - dokladnie identyczne. (zadna nie jest szybsza-to jest to samo i w sensie logicznym, jak i w instrukcjach procesora). Tak samo w takiej petli jak for jak w pierszwym poscie-dokladnie to samo, zadnej roznicy szybkosci czy czegos innego.
Mam nadzieje ze to juz wszystko wyjasnilo.
Nie prawda, '++i' wykona się szybciej od 'i++', ale napewno tego nie zauważysz.
Jeżeli mamy możliwość dokonania wyboru między dwoma położeniami operatora ++ (lub --), powinniśmy zawsze używać wariantu prefiksowego (przed zmienną). Wersja postfiksowa musi bowiem utworzyć w pamięci kopię zmiennej, żeby móc zwrócić jej starą wartość po in/dekrementacji. Cierpi na tym zarówno szybkość programu, jak i jego wymagania pamięciowe (chociaż w przypadku typów liczbowych jest to niezauważalna różnica).
Nie prawda, '++i' wykona się szybciej od 'i++', ale napewno tego nie zauważysz.
Jeżeli mamy możliwość dokonania wyboru między dwoma położeniami operatora ++ (lub --), powinniśmy zawsze używać wariantu prefiksowego (przed zmienną). Wersja postfiksowa musi bowiem utworzyć w pamięci kopię zmiennej, żeby móc zwrócić jej starą wartość po in/dekrementacji. Cierpi na tym zarówno szybkość programu, jak i jego wymagania pamięciowe (chociaż w przypadku typów liczbowych jest to niezauważalna różnica).
Nic nie musi :| Może zobacz wynikowy kod asma najpierw?...
Optymalizacja polegajaca na tym zeby kompilator 'zauwazyl' ze ++j; i j++; da ten sam wynik i nie zmieni niczego jest tak prosta, ze zaloze sie, ze nawet pierwsze kompilatory c sprzed ~30 lat ja miały...
A 'tworzenie kopii w pamieci' to juz totalna bzdura, zaden kompilator nie stworzy kopii w pamieci tylko po to zeby za chwile wlozyc ja do rejestru i o niej zapomniec (o kopii w pamieci)...
Nic nie musi :| Może zobacz wynikowy kod asma najpierw?...
Optymalizacja polegajaca na tym zeby kompilator 'zauwazyl' ze ++j; i j++; da ten sam wynik i nie zmieni niczego jest tak prosta, ze zaloze sie, ze nawet pierwsze kompilatory c sprzed ~30 lat ja miały...
... ale nie musiały, jak sam zauważyłeś. I niestety nie ma pewności co każdy kompilator wyprawia, więc zasada się nie zmienia.
A 'tworzenie kopii w pamieci' to juz totalna bzdura, zaden kompilator nie stworzy kopii w pamieci tylko po to zeby za chwile wlozyc ja do rejestru i o niej zapomniec (o kopii w pamieci)... Bym się naprawde zdziwił, gdyby assembler tworzył obiekty, a ty? A serio, to w takim razie skąd są te słynne wycieki z pamięci?? Przecież żaden kompilator nie tworzy wskaźnika, by później o nim zapomnieć... :)
Jejda no
Kombinujecie. Nowe kompilatory potrafią zoptymalizować kod takiej trywialnej pętli i przerobić i++ na ++i. Co do zmiany nawyków, to się nie zgodzę - o ile przy typach wbudowanych nie ma to takiego znaczenia, to przy iteratorach bardziej skomplikowanych pojemników STLa czy wielu innych klasach implementujących takie operatory różnica może być kolosalna.
BTW. Real_Noname, czemu linkujesz Megatutorial Xion'a z jakiegoś inszego źródła? ;) Patrząc na link w ogóle bym nie skojarzył co to, i dopiero wchodząc stwierdziłem, że to jest właśnie Megatutorial.
http://xion.gamedev....egatutorial.xml
Tu z adresu widać od razu co i czyje ;)
Pozdrawiam.
Użytkownik TeMPOraL edytował ten post 03 sierpień 2006, 15:32
Jejda no
Kombinujecie. Nowe kompilatory potrafią zoptymalizować kod takiej trywialnej pętli i przerobić i++ na ++i. Co do zmiany nawyków, to się nie zgodzę - o ile przy typach wbudowanych nie ma to takiego znaczenia, to przy iteratorach bardziej skomplikowanych pojemników STLa czy wielu innych klasach implementujących takie operatory różnica może być kolosalna.
BTW. Real_Noname, czemu linkujesz Megatutorial Xion'a z jakiegoś inszego źródła? ;) Patrząc na link w ogóle bym nie skojarzył co to, i dopiero wchodząc stwierdziłem, że to jest właśnie Megatutorial.
http://xion.gamedev....egatutorial.xml
Tu z adresu widać od razu co i czyje ;)
Pozdrawiam.
?? O kurcze - rzeczywiście O_o. Ja to znalazłem przez google (po bagatela 4 sek szukania).
Tak się trochę czepiłem :D
Xion ostatnio się odnalazł [żyje cały i zdrowy] i nawet stronę jakąś postawił, więc można spowrotem linkować do niego :)
... ale nie musiały, jak sam zauważyłeś. I niestety nie ma pewności co każdy kompilator wyprawia, więc zasada się nie zmienia.
Nie muszą 'utworzyć w pamięci kopię zmiennej'...
A zmiana nawykow itd i pisanie ++i tam gdzie i++ da to samo to idiotyzm, dzis *na pewno* kazdy nowoczesny kompilator c sobie sam z tym poradzi...
Bym się naprawde zdziwił, gdyby assembler tworzył obiekty, a ty? A serio, to w takim razie skąd są te słynne wycieki z pamięci?? Przecież żaden kompilator nie tworzy wskaźnika, by później o nim zapomnieć... :)
Jakie obiekty? :o Jaki wskaznik? :o C++ czy innego obiektowego wynalazku przypadkiem nie za dużo? ;)
Nawet jesli kompilatorowi z jakichs powodow zabraknie wolnych rejestrow, to wrzuci zmienna na stos tylko po to zeby ja za chwile zdjac... 'Wyciek' pamieci jest w tym wypadku niemozliwy...
Pokaż wynikowy kod z jakiegos kompilatora z tym 'wyciekiem', bo tak teoretyzujac co to jest mozliwe mozna dojsc do wniosku ze jutro hitler zmartwychwstanie i podbije swiat czy innej rewelacji...
Słynne wycieki pamięci biorą się z nieumiejętnego posługiwania się metodami jej zarządzania przez programistę. Owszem, w kompilatorach teoretycznie też może siedzieć błąd, ale jest to dość mało prawdopodobne.
A zmiana nawykow itd i pisanie ++i tam gdzie i++ da to samo to idiotyzm, dzis *na pewno* kazdy nowoczesny kompilator c sobie sam z tym poradzi... Mówimy o C, czy C++? W C może faktycznie; w C++ wręcz przeciwnie - jest to jedna z mądrzejszych rzeczy, którą można zrobić. O ile w przypadku typu wbudowanego kompilator może robić sztuczki optymalizacyjne, o tyle w przypadku klas - a tych się przede wszystkim używa - swobodna implementacja operatorów ++ nie daje kompilatorowi takiej swobody. Po prostu jak jest zwracany obiekt ze starą wartością, to musi być -> trzeba wywołać konstruktor kopiujący, który może mieć przecież efekty uboczne (zwiększać jakąś zmienną, etc.) i kompilator nawet NIE MA PRAWA tego zoptymalizować.
(pomijając niektóre sztuczki dopuszczane przez standard)
Pozdrawiam.
zanotowane.pl doc.pisz.pl pdf.pisz.pl zsf.htw.pl
for(int i =0; i < 0; i++)
{
.
.
}
Chciałbym, wiedzieć czy w zastosowanej pętli ma znaczenie po której stronie zmiennej i dam plusy(gdybym zamienił i++ na ++i)? Zmieni to przebieg albo wynik działania pętli?
i++ - dodaje po wykonaniu petli
++i - dodaje przed wykonaniem petli
Użytkownik RoboKomp edytował ten post 01 sierpień 2006, 17:01
Moim zdaniem akurat w pętli for to nie ma znaczenia i RoboComp blefuje.
for(int i =0; i < 0; i++) - oznacza to, ze przy kazdym przejsciu petli wartosc "i" zostanie zwiekoszna o 1, a w petli to nie ma znaczenia, czy przed czy po.
Użytkownik Ronswer edytował ten post 01 sierpień 2006, 17:12
MA znaczenie. Przy i++ jest tworzony obiekty tymczasowy, nadawana mu wartość obiektu głównego, wartość obiektu głównego zwiększana i zwracany obiekt tymczasowy. Jako że cała instrukcja to tylko i++, więc wartość jaką miała przed zwiększeniem idzie w powietrze.
Przy ++i powoduje zwiększenie wartości i jej zwrócenie. koniec.
Co za tym idzie zastosowanie w pętli ++i JEST szybsze, ale wzrost wydajności jest raczej zbyt mizerny, by sobie zmieniać nawyki...
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Użytkownik JaskMar edytował ten post 02 sierpień 2006, 09:53
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Ktoś nie uczył się uważnie C++ <_< sprawdźL
http://informatyka.s...a_liczbach.html
Umieszczenie operatora ++ (--) przed wyrażeniem nazywamy preinkrementacją (predekrementacją). W takiej sytuacji najpierw dokonywane jest zwiększenie (zmniejszenie) jego wartości o 1. Nowa wartość jest potem zwracana jako wynik.
Kiedy napiszemy operator ++ (--) po wyrażeniu, mamy do czynienia z postinkrementacją (postdekrementacją). W tym przypadku najpierw następuje zwrócenie wartości, która dopiero potem jest zwiększana (zmniejszana) o jeden2.
A ponieważ przy asembleracji instrukcja jest wklejana w całości do pętli, to MA znaczenie czy użyjemy pre, czy post.
Co wy (niektórzy) za farmazony pleciecie. Niema NIGDY ŻADNEJ różnicy. Jest tak zrobione dla wygody programowania. Operatory '++' i '--' to takie szczególne operatory, które mogą przyjmować pozycje przed, jak i po argumencie
Jak możesz pisać w ogóle takie rzeczy jak nie masz pewności teog co mówisz :mad:
Według Ciebie jaka to w ogóle wygoda jest?
Chciałbym, wiedzieć czy w zastosowanej pętli ma znaczenie po której stronie zmiennej i dam plusy(gdybym zamienił i++ na ++i)? Zmieni to przebieg albo wynik działania pętli?
Możesz być spokojny, nie zmieni się wynik działania tej pętli (dla 100 % pewności sprawdziłem to przed chwilą). Tylko jak napisał to wyżej @ Real_Noname jeśli napiszesz ++i to będzie szybciej wykonywała się pętla, choć napewno tego nie zauważysz. ;)
Dodam jeszcze na marginesie coś takiego, aby była pełna jasność:
++ zwiększenie wartości o 1, np. i++ to jest to samo co i=i+1 -- zmniejszenie wartości o 1, np. i-- to jest to samo co i=i-1 Należy jednak zwrócić uwagę, że operatory te można stosować przed i po zmiennej, tzn. liczba++ lub ++liczba. Podobnie jest z operatorem dekrementacji --. Mimo, że działanie operatora w obu wypadkach jest podobne, to nie jest jednak identyczne! Aby to wyjaśnić, muszę Ci zdradzić, że w języku C/C++ prawie każde wyrażenie zwraca jakąś wartość. Np. operacja 5+6 zwraca liczbę 11, i dzięki temu int liczba=5+6; powoduje przypisanie zmiennej liczba wartości 11. Operatory ++ i -- również zwracają wartość, z tym tylko, że jeśli operator znajduje się przed zmienną, to zwraca wartość zmiennej po zwiększeniu(zmniejszeniu), a jeśli znajduje się po zmiennej, to zwraca wartość zmiennej przed wykonaniem operacji zwiększenia(zmniejszenia). Jednak wartość zmiennej w obu przypadkach będzie taka sama.
Użytkownik Dj Kamil edytował ten post 02 sierpień 2006, 14:39
Dla przykładu kod:
#include <stdio.h> void main(){ int i=5; printf("%d\n", i); printf("%d\n", i++); printf("%d\n\n", i); i = 5; printf("%d\n", i); printf("%d\n", ++i); printf("%d\n", i); }
printf z i++ wypisze 5, ten z ++i 6.
Natomiast w przypadkach takich jak np 'i++;' w kodzie, obie instrukcje sa homonimami - dokladnie identyczne. (zadna nie jest szybsza-to jest to samo i w sensie logicznym, jak i w instrukcjach procesora). Tak samo w takiej petli jak for jak w pierszwym poscie-dokladnie to samo, zadnej roznicy szybkosci czy czegos innego.
Mam nadzieje ze to juz wszystko wyjasnilo.
Użytkownik Fr3m3n edytował ten post 02 sierpień 2006, 16:48
Sprawdziłem, w tym znaczeniu w pętli for nie ma różnicy. Oto kod, możecie sami sobie skompilować:
#include <iostream> using namespace std; int main(int argc, char *argv[]) { cout << "Efekt z uzyciem i++: "; for (int i = 0; i < 5; i++) { cout << i << " "; } cout << "\nEfekt z uzyciem ++i: "; for (int i = 0; i < 5; ++i) { cout << i << " "; } }
A oto wydruk:
Efekt z uzyciem i++: 0 1 2 3 4
Efekt z uzyciem ++i: 0 1 2 3 4
Napisałem taki kod w c++:
int main(){ int a=0; for(int i=0; i<5; i++) a+=2; for(int i=0;i<5; ++i) a+=3; a=a++*++a; return a-a; }
Skompilowałem to za pomocą bcc32 z parametrem -B. A w asemblerze wygląda to wtedy tak (fragment, ale ten znaczący):
?live16385@32:; EAX = a @2: xor edx,edx ?live16385@48:; EAX = a, EDX = i @3: add eax,2 @5: inc edx cmp edx,5 jl short @3 ?live16385@80:; EAX = a @7: xor edx,edx ?live16385@96:; EAX = a, EDX = i @8: add eax,3 @10: inc edx cmp edx,5 jl short @8 ?live16385@128:; EAX = a inc eax mov ecx,eax imul ecx,eax mov eax,ecx inc eax mov edx,eax sub edx,eax mov eax,edx ?live16385@160:; @13: @12: pop ebp ret
Jak widać w tym kodzie nie ma znaczenia, cze w pętli jest ++i, czy i++. Dalej przy operacjach a++, ++a też nigdzie nie widzę, żeby była tworzona dodatkowa zmienna, zwracany wynik, czy coś takiego. Różnica polega tylko na sekwencji inkrementacji.
Ten wynik jest dla konkretnego kompilatora, więc nie twierdzę, że inne nie robią tego inaczej. Ale ten kod w asemblerze wygląda pod tym względem logicznie, więc na dzieńdzisiejszy ja pozostaję w przekonaniu, że zapis ++i nie będzie w pętli szybszy niż i++.
:) Teraz juz rozumiem dzeki serdecznie za pomoc
Natomiast w przypadkach takich jak np 'i++;' w kodzie, obie instrukcje sa homonimami - dokladnie identyczne. (zadna nie jest szybsza-to jest to samo i w sensie logicznym, jak i w instrukcjach procesora). Tak samo w takiej petli jak for jak w pierszwym poscie-dokladnie to samo, zadnej roznicy szybkosci czy czegos innego.
Mam nadzieje ze to juz wszystko wyjasnilo.
Nie prawda, '++i' wykona się szybciej od 'i++', ale napewno tego nie zauważysz.
Jeżeli mamy możliwość dokonania wyboru między dwoma położeniami operatora ++ (lub --), powinniśmy zawsze używać wariantu prefiksowego (przed zmienną). Wersja postfiksowa musi bowiem utworzyć w pamięci kopię zmiennej, żeby móc zwrócić jej starą wartość po in/dekrementacji. Cierpi na tym zarówno szybkość programu, jak i jego wymagania pamięciowe (chociaż w przypadku typów liczbowych jest to niezauważalna różnica).
Nie prawda, '++i' wykona się szybciej od 'i++', ale napewno tego nie zauważysz.
Jeżeli mamy możliwość dokonania wyboru między dwoma położeniami operatora ++ (lub --), powinniśmy zawsze używać wariantu prefiksowego (przed zmienną). Wersja postfiksowa musi bowiem utworzyć w pamięci kopię zmiennej, żeby móc zwrócić jej starą wartość po in/dekrementacji. Cierpi na tym zarówno szybkość programu, jak i jego wymagania pamięciowe (chociaż w przypadku typów liczbowych jest to niezauważalna różnica).
Nic nie musi :| Może zobacz wynikowy kod asma najpierw?...
Optymalizacja polegajaca na tym zeby kompilator 'zauwazyl' ze ++j; i j++; da ten sam wynik i nie zmieni niczego jest tak prosta, ze zaloze sie, ze nawet pierwsze kompilatory c sprzed ~30 lat ja miały...
A 'tworzenie kopii w pamieci' to juz totalna bzdura, zaden kompilator nie stworzy kopii w pamieci tylko po to zeby za chwile wlozyc ja do rejestru i o niej zapomniec (o kopii w pamieci)...
Nic nie musi :| Może zobacz wynikowy kod asma najpierw?...
Optymalizacja polegajaca na tym zeby kompilator 'zauwazyl' ze ++j; i j++; da ten sam wynik i nie zmieni niczego jest tak prosta, ze zaloze sie, ze nawet pierwsze kompilatory c sprzed ~30 lat ja miały...
... ale nie musiały, jak sam zauważyłeś. I niestety nie ma pewności co każdy kompilator wyprawia, więc zasada się nie zmienia.
A 'tworzenie kopii w pamieci' to juz totalna bzdura, zaden kompilator nie stworzy kopii w pamieci tylko po to zeby za chwile wlozyc ja do rejestru i o niej zapomniec (o kopii w pamieci)... Bym się naprawde zdziwił, gdyby assembler tworzył obiekty, a ty? A serio, to w takim razie skąd są te słynne wycieki z pamięci?? Przecież żaden kompilator nie tworzy wskaźnika, by później o nim zapomnieć... :)
Jejda no
Kombinujecie. Nowe kompilatory potrafią zoptymalizować kod takiej trywialnej pętli i przerobić i++ na ++i. Co do zmiany nawyków, to się nie zgodzę - o ile przy typach wbudowanych nie ma to takiego znaczenia, to przy iteratorach bardziej skomplikowanych pojemników STLa czy wielu innych klasach implementujących takie operatory różnica może być kolosalna.
BTW. Real_Noname, czemu linkujesz Megatutorial Xion'a z jakiegoś inszego źródła? ;) Patrząc na link w ogóle bym nie skojarzył co to, i dopiero wchodząc stwierdziłem, że to jest właśnie Megatutorial.
http://xion.gamedev....egatutorial.xml
Tu z adresu widać od razu co i czyje ;)
Pozdrawiam.
Użytkownik TeMPOraL edytował ten post 03 sierpień 2006, 15:32
Jejda no
Kombinujecie. Nowe kompilatory potrafią zoptymalizować kod takiej trywialnej pętli i przerobić i++ na ++i. Co do zmiany nawyków, to się nie zgodzę - o ile przy typach wbudowanych nie ma to takiego znaczenia, to przy iteratorach bardziej skomplikowanych pojemników STLa czy wielu innych klasach implementujących takie operatory różnica może być kolosalna.
BTW. Real_Noname, czemu linkujesz Megatutorial Xion'a z jakiegoś inszego źródła? ;) Patrząc na link w ogóle bym nie skojarzył co to, i dopiero wchodząc stwierdziłem, że to jest właśnie Megatutorial.
http://xion.gamedev....egatutorial.xml
Tu z adresu widać od razu co i czyje ;)
Pozdrawiam.
?? O kurcze - rzeczywiście O_o. Ja to znalazłem przez google (po bagatela 4 sek szukania).
Tak się trochę czepiłem :D
Xion ostatnio się odnalazł [żyje cały i zdrowy] i nawet stronę jakąś postawił, więc można spowrotem linkować do niego :)
... ale nie musiały, jak sam zauważyłeś. I niestety nie ma pewności co każdy kompilator wyprawia, więc zasada się nie zmienia.
Nie muszą 'utworzyć w pamięci kopię zmiennej'...
A zmiana nawykow itd i pisanie ++i tam gdzie i++ da to samo to idiotyzm, dzis *na pewno* kazdy nowoczesny kompilator c sobie sam z tym poradzi...
Bym się naprawde zdziwił, gdyby assembler tworzył obiekty, a ty? A serio, to w takim razie skąd są te słynne wycieki z pamięci?? Przecież żaden kompilator nie tworzy wskaźnika, by później o nim zapomnieć... :)
Jakie obiekty? :o Jaki wskaznik? :o C++ czy innego obiektowego wynalazku przypadkiem nie za dużo? ;)
Nawet jesli kompilatorowi z jakichs powodow zabraknie wolnych rejestrow, to wrzuci zmienna na stos tylko po to zeby ja za chwile zdjac... 'Wyciek' pamieci jest w tym wypadku niemozliwy...
Pokaż wynikowy kod z jakiegos kompilatora z tym 'wyciekiem', bo tak teoretyzujac co to jest mozliwe mozna dojsc do wniosku ze jutro hitler zmartwychwstanie i podbije swiat czy innej rewelacji...
Słynne wycieki pamięci biorą się z nieumiejętnego posługiwania się metodami jej zarządzania przez programistę. Owszem, w kompilatorach teoretycznie też może siedzieć błąd, ale jest to dość mało prawdopodobne.
A zmiana nawykow itd i pisanie ++i tam gdzie i++ da to samo to idiotyzm, dzis *na pewno* kazdy nowoczesny kompilator c sobie sam z tym poradzi... Mówimy o C, czy C++? W C może faktycznie; w C++ wręcz przeciwnie - jest to jedna z mądrzejszych rzeczy, którą można zrobić. O ile w przypadku typu wbudowanego kompilator może robić sztuczki optymalizacyjne, o tyle w przypadku klas - a tych się przede wszystkim używa - swobodna implementacja operatorów ++ nie daje kompilatorowi takiej swobody. Po prostu jak jest zwracany obiekt ze starą wartością, to musi być -> trzeba wywołać konstruktor kopiujący, który może mieć przecież efekty uboczne (zwiększać jakąś zmienną, etc.) i kompilator nawet NIE MA PRAWA tego zoptymalizować.
(pomijając niektóre sztuczki dopuszczane przez standard)
Pozdrawiam.