od dwu dni borykam sie z leakami w swoim progsie i co gorsza ciagle
nie wiem jak to naprawic (nie zdarzylo mi sie cos takiego od kilku lat
bo normalnie pisze w statycznym c a tam nie ma takich problemow);
(przy okazji zauwazylem ze haslo 'leaks'
w wikipedii jest dobrze napisane - przyklad z winda ktora jesli kod ma
wycieki moze zatrzymac sie i nie otworzyc drzwi a po resecie ruszy znowu
choc leaki beda sie zbierac od nowa);

do glowy przyszlo mi by sprobowac poukladac sobie w glowie cala szersza
typologie bledow aplikacji, podstawowe ktore kojarze to

- leaki (wycieki)
- zwis (hang)
- crash to desktop
- crash systemu

na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;
czy moze ktos cos dorzucic i powiedziec pare slow o poszczegolnych
przypadkach, ZACHECAM



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2011-05-02 11:54, fir pisze:
> od dwu dni borykam sie z leakami w swoim progsie i co gorsza ciagle
> nie wiem jak to naprawic (nie zdarzylo mi sie cos takiego od kilku lat
> bo normalnie pisze w statycznym c a tam nie ma takich problemow);
> (przy okazji zauwazylem ze haslo 'leaks'


statyczny C powiadasz? nie znam.
Programowanie w C bez leaków? Nie wiem, jak musialo by byc proste i
specyficzne. Ostatni program w C, wiem na 100% bez leaków, popelnilem 15
lat temu. Potem juz to za duze bylo.

O dawna mam zasade: sluchaj zaawansowanych zwolenników technologii,
idealnie objasnia jakie sa wady. (w bazach Firebird - to od zwolenników
dowiedzialem sie jak cienki optymalizator itd, w fotografii zwolennicy
nikosiów i kanonicy itd)

Jak sprzedawalem 20 lat temu malucha 126p , zachwalalem jaki jest dobry,
bo kazdy moze sobie go naprawic (nabywca otrzymal caly bagaznik czesci).
To mniej wiecej ta argumentacja.


Wiec tu ciekawe jest uslyszec o awariach i padach, o jakich dawno
zapomnieli programisci innych jezyków/platform obrazeni na C :P

Wybacz nastrój dlugiego weekendu.

do góry

W dniu 2011-05-02 11:54, fir pisze:

> do glowy przyszlo mi by sprobowac poukladac sobie w glowie cala szersza
> typologie bledow aplikacji, podstawowe ktore kojarze to
>

<od18lat>
W l 1990-tych w zespole gdy za duzo fruwalo słow uwazanych za wulgarne,
umówilismy sie, ze innymi slowami bedziemy precyzyjnie okreslac
sytuacje, ze program sie 'wypier...' 'zje...' itd.
</od18lat>

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> W dniu 2011-05-02 11:54, fir pisze:
> > od dwu dni borykam sie z leakami w swoim progsie i co gorsza ciagle
> > nie wiem jak to naprawic (nie zdarzylo mi sie cos takiego od kilku lat
> > bo normalnie pisze w statycznym c a tam nie ma takich problemow);
> > (przy okazji zauwazylem ze haslo 'leaks'
>
>
> statyczny C powiadasz? nie znam.
> Programowanie w C bez leaków? Nie wiem, jak musialo by byc proste i
> specyficzne. Ostatni program w C, wiem na 100% bez leaków, popelnilem 15
> lat temu. Potem juz to za duze bylo.
>
> O dawna mam zasade: sluchaj zaawansowanych zwolenników technologii,
> idealnie objasnia jakie sa wady. (w bazach Firebird - to od zwolenników
> dowiedzialem sie jak cienki optymalizator itd, w fotografii zwolennicy
> nikosiów i kanonicy itd)
>
> Jak sprzedawalem 20 lat temu malucha 126p , zachwalalem jaki jest dobry,
> bo kazdy moze sobie go naprawic (nabywca otrzymal caly bagaznik czesci).
> To mniej wiecej ta argumentacja.
>
>
> Wiec tu ciekawe jest uslyszec o awariach i padach, o jakich dawno
> zapomnieli programisci innych jezyków/platform obrazeni na C :P
>
> Wybacz nastrój dlugiego weekendu.
>

statyczny c to c bez mallocow - c wylacznie ze statycznymi tablicami

[w parktyce _czasem_ mozna by uzyc i mallloca i w takim obecnym statycznym
c ale raczej bylby to duzy malloc - i rzadko, albo cos absolutnie tmp;]

troche stracilem kontakt z duchem c ostatnio ale ukulem powiedzenie
'statyczny c' aby podkreslic fakt ze to c o ktorym ja mowie to jest c bez
malloc/free tylko c z tablicami struktur -- moze wcale nie trzymalbym sie
pojecia statycznosci tak mocno gdyby te alloki (a jeszcze leipaj i realoki)
dalo sie zrobic szybko (tj jakby myslenie o maszyneri allokow przeniesc
by na grunt c)- teoretycznie moze i by sie dalo -

ale poki co statycznym c nazywam c ze statycznymi tablicami struktur
- podkreslam to bo niektorym jak mowie c widac wydaje sie ze c o jakim
mowie to c z mallokami i free (i wtedy nie rozumieja o czym mowie)
[gdy tymczasem jest to c w ktorym pary malloc-free uzywa sie albo raz
na rok albo literalnie nigdy - to wlasnie nazywam 'statycznym c']





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

jest kilka rodzajow tych rozmaitych bledow aplikacji -
np

- jakies bledy przewalajace sie wewnatrz (kilka rodzajow) z
rozmaitymi efektami ubocznymi ale bez crashow,
- krash (to desktop/systemu),
- hang (zwis),

to sa moze trzy podstatwowe (z ktorych poszczegolne
dziela sie na wiele typow) ale mozna np jeszcze dolozyc

- odmowa startu itd

nie mam zbudowanej dobrej typologii tych 'przypadkow' a
jest tego sporo - jak najbardziej warto sie polapac w temacie
'co tu sie tak wogole dzieje'




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

>jest kilka rodzajow tych rozmaitych bledow aplikacji -
>np

>- jakies bledy przewalajace sie wewnatrz (kilka rodzajow) z
>rozmaitymi efektami ubocznymi ale bez crashow,
>- krash (to desktop/systemu),
>- hang (zwis),

>to sa moze trzy podstatwowe (z ktorych poszczegolne
>dziela sie na wiele typow) ale mozna np jeszcze dolozyc

>- odmowa startu itd

>nie mam zbudowanej dobrej typologii tych 'przypadkow' a
>jest tego sporo


np nie jest dla mnie jasne czemu 'hangi' zdarzaja sie tak stosunkowo
czesto - wydaje sie ze krasz jest dosyc latwy do wywolania i zrozumialy
(np blad w binarce powinien wywolac raczej krasz - blad ochrony pamieci
i krasz) ale czemu hangi zdarzaja sie stosunkowo tak czesto? (moze
zreszta mi sie wydaje i 90% to porysowane plyty wnapedach - jakie szczescie
ze ten szajs (plyty cd itd) odchodzi wydaje sie na smietnik)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

fir wrote:

> od dwu dni borykam sie z leakami w swoim progsie i co gorsza ciagle
> nie wiem jak to naprawic (nie zdarzylo mi sie cos takiego od kilku lat
> bo normalnie pisze w statycznym c a tam nie ma takich problemow);
> (przy okazji zauwazylem ze haslo 'leaks'
> w wikipedii jest dobrze napisane - przyklad z winda ktora jesli kod ma
> wycieki moze zatrzymac sie i nie otworzyc drzwi a po resecie ruszy znowu
> choc leaki beda sie zbierac od nowa);
>
> do glowy przyszlo mi by sprobowac poukladac sobie w glowie cala szersza
> typologie bledow aplikacji, podstawowe ktore kojarze to
>
> - leaki (wycieki)
> - zwis (hang)
> - crash to desktop
> - crash systemu
>
> na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;

Te powyzsze to najprostsze do naprawienia :)
Sa znacznie gorsze np
program zle policzy kapuste i firma pojdzie z torbami
program zle policzy natezenie promieniowania w urzadzeniu do naswietlania
RTG
program zle policzy parametry lotu rakiety i ta p..lnie w jakies
paromilionowe miasto
itd
Czyli - ogolnie - program zle dziala :)

--
Michal

do góry

W dniu 2011-05-02 15:33, Michal Kleczek pisze:
> fir wrote:
>> na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;
>
> Te powyzsze to najprostsze do naprawienia :)
> Sa znacznie gorsze np
> program zle policzy kapuste i firma pojdzie z torbami
...

teraz wypowiedz na serio.
W latach ... juz minionych, mialem i przeczytalem kilkakrotnie ksiazke
(popularna seria z takim pascalowym zankiem podstawienia) o
niezawodnosci autor (mniej wiecej) pisal sie Myers. Ksiazka (zupelnie
poza tokiem studiow, z wlasnej inicjatywy kupiona) dla mnie formacyjna,
choc lata minely (np. ergomonia i psychologia podawania argumentow to
command line), ale m.in. co dla mnie istotne:
a) odroznienie **istnienia bledu** w kodzie a jego **ujawnienie** w
postaci incydentu, awarii (to dla tych co maja bezbledne programy 'bo
sie nie wywrócil).
Mysl bardzo wazna w kontescie tego watku.


a1) analiza statystyczna: testy A wykazaly X bledów, testy B wykazaly Y,
z tego przeciecie zbiorów X i Y ... wychodzi prawdopodobna ilosc Z nie
znalezionych bledów
b) psychologia programisty. Ten, który nie posiada watpliwosci, nie
dostrzeze oczywistego bledu w swoim kodzie (wiele lat pozniej wyrosla z
tego koncepcja przegladania kodu, XP itd)
c) fajna teoria, ze wszystkie bledy sa bledami translacji: uzytkownik
zle przetlumaczyl analitykowi, analityk projektantowi ... programista
zle wyrazil w kodzie, a kompilator zle wygenerowal kod maszynowy ;)
d) na module A w testach odnaleziono n bledow, na module B m, n<<m co z
tego wynika ... zagadka
e) co z tym robic, m.in. jak budowac jezyki programowania, organizacja
pracy itd.

oczywiscie wiele innych mysli, wiekszosci juz nie pamietam.

Cos, co ten autor uwaza za rys charakteru przydatny do szukania bledow,
cos instytut miernictwa nas przecwiczyl studentów uwalajac 80% na
rachunku bledow, a historia filozofii pokazala sens posiadania
watpliwosci... to mi sie jakos uzupelnia, twórcze watpienie sobie cenie
najbardziej.

do góry

Dnia 02.05.2011 Jacek Czerwinski <...@...z.pl> napisał/a:
> W dniu 2011-05-02 15:33, Michal Kleczek pisze:
>> fir wrote:
>>> na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;
>>
>> Te powyzsze to najprostsze do naprawienia :)
>> Sa znacznie gorsze np
>> program zle policzy kapuste i firma pojdzie z torbami
> ...
>
> teraz wypowiedz na serio.
> W latach ... juz minionych, mialem i przeczytalem kilkakrotnie ksiazke
> (popularna seria z takim pascalowym zankiem podstawienia) o
> niezawodnosci autor (mniej wiecej) pisal sie Myers. Ksiazka (zupelnie
> poza tokiem studiow, z wlasnej inicjatywy kupiona) dla mnie formacyjna,
> choc lata minely (np. ergomonia i psychologia podawania argumentow to
> command line), ale m.in. co dla mnie istotne:
> a) odroznienie **istnienia bledu** w kodzie a jego **ujawnienie** w
> postaci incydentu, awarii (to dla tych co maja bezbledne programy 'bo
> sie nie wywrócil).
> Mysl bardzo wazna w kontescie tego watku.
>
>
> a1) analiza statystyczna: testy A wykazaly X bledów, testy B wykazaly Y,
> z tego przeciecie zbiorów X i Y ... wychodzi prawdopodobna ilosc Z nie
> znalezionych bledów
> b) psychologia programisty. Ten, który nie posiada watpliwosci, nie
> dostrzeze oczywistego bledu w swoim kodzie (wiele lat pozniej wyrosla z
> tego koncepcja przegladania kodu, XP itd)
> c) fajna teoria, ze wszystkie bledy sa bledami translacji: uzytkownik
> zle przetlumaczyl analitykowi, analityk projektantowi ... programista
> zle wyrazil w kodzie, a kompilator zle wygenerowal kod maszynowy ;)
> d) na module A w testach odnaleziono n bledow, na module B m, n<<m co z
> tego wynika ... zagadka
> e) co z tym robic, m.in. jak budowac jezyki programowania, organizacja
> pracy itd.
>
> oczywiscie wiele innych mysli, wiekszosci juz nie pamietam.
>
> Cos, co ten autor uwaza za rys charakteru przydatny do szukania bledow,
> cos instytut miernictwa nas przecwiczyl studentów uwalajac 80% na
> rachunku bledow, a historia filozofii pokazala sens posiadania
> watpliwosci... to mi sie jakos uzupelnia, twórcze watpienie sobie cenie
> najbardziej.
>

G.J. Myers, "Projektowanie niezawodnego oprogramowania." I nie Pascal, a
Algol, na pewno z elementami Fortranu. Mimo że wydana dość dawno temu - polecam.


--
Pozdrawiam,
Marcin Kwiatkowski

do góry

On Mon, 2 May 2011 11:08:59 +0000 (UTC), " fir"
<f...@W...gazeta.pl> wrote:
> statyczny c to c bez mallocow - c wylacznie ze statycznymi tablicami

Przecież w takim czymś również można mieć leaki, tylko trudniej je
znaleźć.

do góry