On Thu, 11 Jun 2009 20:53:28 -0400, T.M.F. wrote:
>>>>> Inaczej kompilator musi utworzyc kopie obiektu tRect i ta kopie dopiero
>>>>> przekazac do funkcji.
>>>> W C++ moze to byc faktycznie kosztowne.
>>> W C tez powinno byc kosztowne. Bo skad kompilator ma wiedziec, ze Rysuj
>>> nie modyfikuje struktury tRect?
>> Nie musi wiedziec. Ma wrzucic cala na stos, co powinno pojsc dosc
>> szybko.
>
>Tak sie nie da. Jesli tRect jest gdzies dalej wykorzystywany to
>kompilator musi utworzyc jego kopie, zeby zagwarantowac, ze Rysuj jej
>nie zmodyfikuje - to wynika ze standardu.

"wrzucenie na stos" to wlasnie utworzenie kopii.

Tylko ze w zwyklym C bez obiektowej nadbudowy jest to operacja dosc
prosta i szybka, jesli struktura krotka. A jak jeszcze procek ma 16
czy 32 bitowe operacje push ...


>Oczywiscie optymalizator moze
>zauwazyc, ze nasze tRect jest dalej niewykorzystywane i z tego etapu
>zrezygnowac - no ale to juz zaklada, ze optymalizator jest dosc
>sensowny.

Musialby byc IMO az za bardzo sensowny.

>Ale mowimy konkretnie o AVR i AVR-gcc.

Ja tam patrze troche szerzej.
Jak juz sie pisze w C to dobrze by bylo nie pisac pod jeden procesor,
ktory w dodatku nie ma alternatywnego dostawcy :-)

J.