Dnia Sun, 17 Oct 2010 14:57:09 +0200, Sebastian Biały napisał(a):

>> o tym właśnie mowa, po co ma sie rzucać w oczy?
>
> Żeby mozna było wyszkuać gdzie je robisz. Casty to zło jesli je uzywasz
> masz coś nie tak z designem. Dzieki przydlugiej składni można je znaleźć
> skuteczniej (bez analizy jezyka) niz casty z C i innych podobnych.

Czyli jak w programie jest błąd to pierwsze co robisz to szukasz gdzie są
casty? To taki sam argument że jak w programie jest błąd to pierwsze co
robie to wyszukuje pętle for (wstawić cokolwiek).

Cast to jest narzędzie, ono nie jest złe, nie ma w nim diabła, ono może być
źle użyte.

--
Jarek

do góry

On 2010-10-17 18:54, Jarek wrote:
> Czyli jak w programie jest błąd to pierwsze co robisz to szukasz gdzie są
> casty?

Nie. Ale pierwsze co robie na code review to pytam autora po co. I
prawie zawsze można znaleźć lepsze rozwiązanie które w przyszlości
będzie łatwiejsze w utrzymaniu. A szczegolnie jak to jest dynamic_cast.

> Cast to jest narzędzie, ono nie jest złe

Nie zgadzam się. Błedy produkowane przez casty są jednymi z
najtrudniejszych do znalezienia w kodzie produkcyjnym.

Cast to obejście silnych typów. Jak się dobrze pomysli to zazwyczaj nie
trzeba obchodzić.

do góry

W dniu 17.10.2010 20:41, Sebastian Biały pisze:
> On 2010-10-17 18:54, Jarek wrote:
>> Czyli jak w programie jest błąd to pierwsze co robisz to szukasz gdzie są
>> casty?
>
> Nie. Ale pierwsze co robie na code review to pytam autora po co. I
> prawie zawsze można znaleźć lepsze rozwiązanie które w przyszlości
> będzie łatwiejsze w utrzymaniu. A szczegolnie jak to jest dynamic_cast.

No ale przyznaj, że "prawie" robi jednak różnicę. No i czy wszystkie
casty są jednakowo złowróżbne ? Piszesz o dynamic_cast jako szczególnie
groźnym, ale wg. mnie jest to jeszcze względnie bezpieczne - złe
castowanie od razu wychodzi.
Co innego reinterpret_cast. To już groźny żywioł, niestety rzadko
używany. W tych źródłach, które najczęściej oglądam jest po prostu
w tym kontekście castowanie w stylu C.

Wpadłem na pomysł, że możnaby przeszukiwać źródła pod kątem void* - na
ogół rzutowaniu reinterpret towarzyszy właśnie coś takiego.

>> Cast to jest narzędzie, ono nie jest złe
>
> Nie zgadzam się. Błedy produkowane przez casty są jednymi z
> najtrudniejszych do znalezienia w kodzie produkcyjnym.
>
> Cast to obejście silnych typów. Jak się dobrze pomysli to zazwyczaj nie
> trzeba obchodzić.

Czasem trzeba. Nie sposób przewidzieć wszystkich możliwych funkcji
wirtualnych w klasie bazowej - czasem jest to niemożliwe.
Czasem dostajemy gotową biblioteke, w której brakuje określonych
funkcji wirtualnych i trzeba sobie radzić - wtedy dynamic_cast

do góry

On 2010-10-18 11:06, Mirosław Habarta wrote:
>> Nie. Ale pierwsze co robie na code review to pytam autora po co. I
>> prawie zawsze można znaleźć lepsze rozwiązanie które w przyszlości
>> będzie łatwiejsze w utrzymaniu. A szczegolnie jak to jest dynamic_cast.

> No ale przyznaj, że "prawie" robi jednak różnicę.

Jezyk to nie religia. Jak sie nie da to się izoluje, opisuje i stawia
duzo asertów i unit testów i dalej świadomie unika.

> casty są jednakowo złowróżbne ? Piszesz o dynamic_cast jako szczególnie
> groźnym, ale wg. mnie jest to jeszcze względnie bezpieczne - złe
> castowanie od razu wychodzi.

Nie wychodzi od razu. Wychodzi w runtime. To jest ta różnica. A runtime
nie zawsze przechodzi każdą ściezką nawet jesli poświęcisz czas na
zrobienie porządnych testów kryjących większość kodu to gdzieś coś
przeoczysz.

> Czasem trzeba. Nie sposób przewidzieć wszystkich możliwych funkcji
> wirtualnych w klasie bazowej - czasem jest to niemożliwe.
> Czasem dostajemy gotową biblioteke, w której brakuje określonych
> funkcji wirtualnych i trzeba sobie radzić - wtedy dynamic_cast

Widze dwa rozwiazania:

a) wizytacje (o ile możesz zmienić klasy bazowe).

b) pseudo-wizytacje gdzie double-disptach zamieniony jest na
dynamic_cast ale *wyizolowane* w jednym łatwym do utrzymania miejscu w
kodzie a reszta kodu jest chroniona kontrolą typów. Łaczy zalete
wizytorów w sensie kontroli typów compile-time a jednocześnie nie
ingeruje w obcy kod.

Ogólnie 15 minut poświęcone na usuniecie gówna w postaci casta moga
zaprocentować w postaci nie straconych 3 dni na szukaniu problemu u
klienta w Kambodży.

do góry

> zrobiłem sobie 6 tygodni przerwy z drugiej strony czasem gdy coś mi się
> niespodziewanie uda wpadam w stan który można oddac słowem 'maniac' (rodzaj
> zadowolenia ktory mozna by np wyrazić bićiem pięsciami w szafę)

moze lekka przesada bo to bardzo nieprecyzyjnie powiedziane ale
gdy cos sie faktycznie uda (nic specjalnego po prostu coś fajnie działa)
to ogarnia mnie wtedy takie swoiste poczucie zadowolenia

warto oczywiscie mowiac o programowaniu jako zajeciu oddzielić 'czyste'
programowanie (gdy programuje sie jak chce i co chce) od programowania
w robocie (to drugie niesie za sobą szereg głupot i bezsensow (np zwyczaj
by programowac az 8 godzin dziennie, wypelniac kretynskie timesheety
itp)) - bardziej warto mz skupic sie na tym 'czystym' programowaniu

fir


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Dnia Sat, 16 Oct 2010 21:54:35 +0200, Sebastian Biały napisał(a):

> W Delphi? Widzialem raz w życiu poważny projekt bo ktoś go zaprojektował
> (swoją drogą od 2 lat jest już przepisany do C#). Reszta to same
> onkliki. Poteżne w sensie KLOC ale tylko onkliki. Z chęcią
> zainteresowałbym się czymś rozsądnie duzym, open source w Delphi (chyba
> że możesz opowiedzieć o jakims closed). Jest coś do pooglądania? Pytam
> całkiem serio, chciałym raz przed smiercią zobaczyć kawalek solidnego i
> ładnego obiektowo kodu w Delphi.


http://code.google.com/p/delphi-spring-framework/

--
pozdrawiam
Norbert

do góry

Użytkownik "Norbert" napisał:

> > bardzo lubie pisac soft blisko sprzętu, blisko OS itd.

Ty coś piszessz? Bo po polsku nie za bardzo Ci idzie.

Remek

do góry