On 08/17/2011 11:56 PM, m...@t...pl wrote:
>
>> Ogólnie mam wrażenie, że niektórzy żyją w generalnym chaosie, lepiej
>> wtedy w ogóle nie używać new bo i tak się zapomni zwolnić, pointery
>> mogą wskazywać gdziekolwiek "uszkadzając inty" - też lepiej nie używać.
>> Code and pray.
> Ludzie się mylą. Lepiej przewidzieć pomyłki i zastanowić się jak łagodzić
> ich skutki, niż wierzyć że się nie popełni błędu.
>
> Języków C/C++ z reguły używam do bardzo małych programów, np. w granicach
> 500-1000 linii kodu. Są one na tyle małe i niezbyt skomplikowane że wiele
> się nie zastanawiam nad estetyką, metodyką, itd, a one dobrze działają.
> Dużych albo trudnych projektów w C/C++ mam raptem cztery. Jeden z nich był
> napisany zgodnie ze sztuką. Podczas pisania programu zabroniłem na głos
> używać określenia "będzie za wolno działało".

Brutalne rozwiązanie, szkoda że czasem tak trzeba.

Program przez wiele lat
> działa i nie stwarza problemów. Pozostałe 3 programy zostały dlatego
> napisane w C/C++ żeby dokonać optymalizacji. No i od dziś nikt nie ma
> pewności czy nie został jakiś błąd.

To ja ci powiem, że został popełniony jeden generalny. Kiedyś faktycznie
optymalizacja to assembler albo bardzo blisko. Dzisiaj, fakt, jakieś
multimedia i podobne niektórzy jeszcze rzeźbią w assemblerze, czy
też wstawki typu atomiki, których dotychczas nie było, i ok. Natomiast
większość optymalizacji - o ile wiem - to umiejętne użycie kompilatora.
Czasami wydaje mi się, że niektórzy nie uświadomili sobie, że
zarówno procki i kompilatory "deczko" się zmieniły przez ostatnie
dziesięć lat. Oczywiście, niektóre rzeczy były i są kosztowne,
trzeba kod pisać inaczej, żeby kompilator mógł go optymalizować,
bo robi tylko te przekształcenia, które może zrobić mając dostępne
założenia - zazwyczaj wystarczy mu przeszkody usunąć z drogi. Nie jest
to darmo, ale nie ma to większego wpływu na pisanie poprawnego
kodu. Range check w przypadku większych pętli zazwyczaj sprowadza się
do jednorazowego >=start <end - co i tak kompilator musi zrobić,
żeby np. wygenerować prologi przekształconych pętli, więc taki check
w kodzie źródłowym paradoksalnie ułatwia mu pracę (ok, jak to zwykle
z optymalizacjami bywa: czasami, nie zawsze, zależy, itd.).

>
> Jeśli ktoś twierdzi że w C/C++ można pisać bez błędów to ja się pod tym
> podpisuję. Ale czy np. w Javie nie jest trochę łatwiej?
>

Java ma inne zalety: jest ogólnie prostsza i ma reflection. Moim zdaniem
jest za mało ekspresywna, muszę się stanowczo dużo więcej naklepać,
żeby uzyskać ten sam efekt. Przy małym i prostym kodzie tego może nie
być widać; przy frameworkach FWIW też nie.

Co do optymalizacji i Javy, to różnie mówią. Znam testy gdzie Java i C++
były podobne. Znam takie, gdzie Java była wolniejsza. Znam też takie,
że w HPC używają Javy, ale tylko ze słyszenia - kiedyś googlnę, nie
spędza mi to snu z powiek łagodnie mówiąc.

>>>> Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
>>>> dwóch tygodni, a byłby wart więcej niż te testy (które można
>>>> też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
>>>> chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.
> Valgrind to dobra rzecz, ale gdy ostatnio chciałem nim sprawdzić program,
> to były błędy... w kompilatorze. Muszę jeszcze raz spróbować. Są jakieś
> alternatywne narzędzia dla valgrinda?
> Pozdrawiam
>

Są. Ale sam valgrind ma "suppresions" czy jakoś tak to się nazywa, co
obchodzi znane problemy z libami, ma też opcję "wygeneruj suppresion",
jak już nie ma innego wyjścia pod każdym upierdliwcem wypluje, jak go
wyłączyć.

Nie znam opcji pod Win, mam malutkie doświadczenie.


>> :) sprawdza, czy "genialny szachista" nie spadnie pod stół już podczas
>> otwarcia.
> To akurat był błąd typu: brak ifa :) Pomoże jedynie walidacja krzyżowa z
> innym programem który tego ifa ma :)
> Pozdrawiam

Testy tego możliwie małego kawałka kodu też. Nie pisałem algorytmów
szachowych, nie wiem, czy dają się tak podzielić. No i fakt, valgrind
braku ifa nie wyniucha - szkoda ;) Przydałby się tool, który bierze dwa
algorytmy, powiedzmy, że różniące się nie zasadą działania, tylko
użytymi strukturami danych, i mówi, czy są równoważne.

Edek