> 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". 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.

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?

> >> 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

> :) 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



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