Neuvolneni pameti po dynamicke alokaci

[VladR]

Uff, toto je mega prasacina.

Toto je presne vec, na ktoru by si dynamicky alokovat pamat nemal.
Aj keby si tu pamat spravne dealokoval, takto si rozhasis a rozfragmentujes heap za chvilku.

A uz rozhodne nie systemom, ze si este posunies povodny pointer (a teda zaciatok si stratil - nehovoriac, ze je to nestandardne spravanie, takze riskujes ze nedealokujes nic, zavisiac od implementacie).

Predovsetkym si tie pointery vyskusaj na niecom inom, ako su bull-terminated stringy - idealne na nejakych intoch alebo nejakom structe, lebo teraz pleties 3 veci a si navyse dopleteny

[Játro.m]

VladR: ja vim , bohuzel jsem zil v domeni ze cokoliv je pres hvezdicku tak musim alokovat. Jinak diky ze jste me poslai tim spravnym smerem, snad uz si pri manipulacich s pointerama dam na toto pozor.

[VladR]

Najlepsie urobis, ak si das od tohto pauzu a v nejakom novom projekte si na par dni poriadne otestujes pracu s pointermi.

Tisickrat sa ti to vrati, ak sa ti to nebude pliest, lebo to najhorsie co mozes spravit je, ze si myslis ze uz tomu rozumies a budes pritom dalej prasit kod, ktory nepadne len cirou zhodou okolnosti.

A tiez uz som zazil v praci, ze jeden kolega podobne zazdil 2 pointere (pritom s odstupom asi tak 4 riadkov ) a v klude fical dalej ako keby nic - cim vyhral cenu najprasackejsi kod vsetkych cias.

Takze - ponahlaj sa pomaly

[VladR]

Jo, a nikde tam nevidim try/catch v tom kode.

Nemusis ho davat do release verzie, ale preboha ziveho, kym developis, tak si to otry-catchuj - ani netusis kolko trapenia ti to moze usetrit, ked sa budes snazit zistit pricinu obcasneho crashu.
Kolkokrat ti to pocas developenia rovno odhali, ze sa snazis nepatricne alokovat/releasovat.

A zvykni si na vynulovanie pointera, ked ho deletnes. Vies ako to pomoze pri debugovani ?

Asi najmenej pracny system je to mat niekde v konstruktore nulovane a v destruktore releasovane, cim zarucis, ze ked program skonci, resp. tvoj objekt vypadne z akt.bloku, tak sa to samo releasne (a pri alokacii zistuj, ci netreba releasnut najprv).

[VladR]

Ked tu uz vo velkom spamujem, tak mi neda doplnit poslednu vec, ktora patri pri pointeroch najzradnejsia a je dovodom kontrol pri praci s nimi (mimo deletovania, kedy standard zarucuje, ze je mozne korektne zavolat delete []p, pricom p==NULL).

Ty nejakym sposobom navrhnes flow programu a tomu prisposobis (de)alokaciu dyn.pamate.

Zanedlho pride novy request, ktory logicky dany flow zmeni. Ale to si uz nebudes davno pamatat, cize nechtiac zavedies do kodu leak/crash.
Proste tie kontroly ta chrania pred sebou samym, lebo C++ bolo navrhnute tak, aby si si sam vedel strelit do nohy.


A nie vzdy si clovek chce strelit do nohy ...

Jasne, su techniky ako to vylucit uplne, ale nez ta odradit uplne, tak radsej aspon toto...

[Quiark]

Ad nulování:

[JohnyDog]

delete 0 je zaruceny no-op jak uz psal VladR, takze se da zjednodusit na

[frca]

Není nakonec lepší používat staré dobré malloc a free, které nerozlišuje jeden prvek a pole? Akorát nevím, jak potom s konstruktorama... Ale tuším na to něco je.
_________________
www.FRANTICWARE.com

[Mem]

[Quiark]

[VladR]

[if.then]

Někomu vyhovuje NULL, někomu 0, někomu zas nullptr
Ale všechno je to rozhodně lepší než wild pointers
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[frca]

[VladR]

A co tym akoze ziskas, ze spravis new foo [1] ? To je praveze este nebezpecnejsie.

ad ukazovatel na pole - to je bezna chybka - lenze nazov pola je adresou prveho elementu pola.

Pole samotne nie je ukazovatel, kedze je const, takze nemozes napisat foo = bar (pricom int * bar), co pritom s regulerne zadeklarovanymi pointermi spravit ide.

[frca]

Možnost na "všechno" volat delete[], ale jak říkám, v dobře napsaném programu je to k ničemu.
PS: Když tak nad tím přemýšlím, tak s ukazatelem na pole alokovaným pomocí new[] musí být nějak spojen počet prvků, aby bylo jasné, na kolik se jich má zavolat destruktor. Nevíte, jak to překladače řeší?
_________________
www.FRANTICWARE.com