Kezdőlap › Fórumok › Programozás › miért zabálom a memóriát?
- This topic has 21 hozzászólás, 6 résztvevő, and was last updated 18 years, 4 months telt el by
lacix.
-
SzerzőBejegyzés
-
2007-02-18-19:52 #2088790
Az fgv_2 semmilyen területet nem foglal le! Csak egy cím. (Noha ez a gyakorlatban 32 bit… összesen.)
Ami helyet foglal az a statikus_fgv_2-d… az viszont nem fog felszabadulni. (Kiv., ha ez egy objektum. De ez rád nem vonatkozik, mert c objektumot nem hozol létre.)Részletezve a problémádat:
Code:stat_fgv: (ez egy cím a memóriában)
…(a függvény kódja a memóriában)Code:Típus* fgv_2();
Ez speciel ennyit jelent:
int fgv_2 = 0x00000000; // a fgv_2 egy cím a memóriában (egy 32 bites adathalmaz címe)Ahhoz, hogy értelme legyen kell egy statikus függvény címét megadni.
fgv_2 = stat_fgv; // a stat_fgv egy cím a memóriában (itt kezdődik a függvényed)1.
Code:fgv_1( fgv_2() );
Ez a következő műveletekből áll:
fgv_2 cím elmentése a stacken (push fgv_2)
ugrás a fgv_1 címre (call fgv_1)2.
Code:Típus *x = fgv_2();
fgv_1(x);
Ez meg:
32 bit a kódban, mely a fgv_2 címre mutat (x dd fgv_2) (vagy ha tetszik int x = fgv_2)
x cím elmentése a stacken (push x)
ugrás a fgv_1 címre (call fgv_1)Tehát ez utóbbi 2 byte-tal hosszabb.
2007-02-18-20:24 #2088791Azt hiszem nem voltam világos, és nem egyről beszünk. A fgv_2 helyére képzeld ezt:
[url][/url]http://developer.gnome.org/doc/API/glib/glib-string-utility-functions.html#G-STRDUP-PRINTF
Tehát az fgv_2() lefoglalal egy területet, aminek visszaadja a címét és nem tudom, hogy az fgv_1( fgv_2() ) esetben felszabadul-e.2007-02-18-20:28 #2088792Ok, értem már. :))))
(Nem fgv_1( fgv_2() ), hanem fgv_1( fgv_2_visszateresi_erteke )…)
A fgv_2 által lefoglalt memória, természetesen nem fog felszabadulni a fgv_2 végén, csak, ha a fgv_2 egy objektum és az objektum megszűnik…
(Ebben az esetben is akkor, ha statikus elem az objektumban, vagy a destruktorában felszabadításra kerül.)
Noha ez a legkényelmesebb módja, viszont a C-ben munkás dolog objektumot létrehozni. (Ha érdekel, akkor GObject-ben tudok segíteni.)
Egyszerűbb, persze a másik módszer, viszont könnyen el lehet feledkezni róla… ilyenkor szivárog a memória.2007-02-18-20:52 #2088793Na, akkor írok egy konkrét példát, nincs semmi értelme, de a problémám remélhetőleg ebből látszódni fog:
1.
gchar *date = g_strdup_printf(„date: %s”, g_strdup_printf(„%04d.%02d.%02d”, year, month, day) );
g_free(date);2.
gchar* text = g_strdup_printf(„%04d.%02d.%02d”, year, month, day);
gchar *date = g_strdup_printf(„date: %s”, text);
g_free(date);
g_free(text);Tehát az első esetben van-e memory leak?
2007-02-18-21:11 #2088794Na már módosítottam a hozzászólásomat…csak azután írtál, hirtelen… csak megzavart a fgv_1 (fgv_2()) megjelölés…
Az 1-esben van szivárgás…
Ez miért nem jó?
g_strdup_printf(„date: %04d.%02d.%02d”, year, month, day);2007-02-18-21:18 #2088795Objektum esetén:
objektum = objektum_new (….
g_free ( objectum.valami ), vagy az objektum valamely függvénye által lefoglalt terület felszabadítása válik feleslegessé… így nem kell rá figyelni, mert a szülő objektum megszünésével az összes gyerek által lefoglalt terület automatikusan felszabadul.2007-02-18-21:30 #2088796Kösz!
vizsla wrote:Ez miért nem jó?
g_strdup_printf(„date: %04d.%02d.%02d”, year, month, day);Természetesen jó, írtam is, hogy ennek nincs értelme, csak nem jutott jobb példa az eszembe.
vizsla wrote:a szülő objektum megszünésével az összes gyerek által lefoglalt terület automatikusan felszabadul.Igen ezt tudom pl. egy konténer törlésével a benne lévő widgetek is pusztulnak. 🙂
vizsla wrote:Noha ez a legkényelmesebb módja, viszont a C-ben munkás dolog objektumot létrehozni. (Ha érdekel, akkor GObject-ben tudok segíteni.)
Egyszerűbb, persze a másik módszer, viszont könnyen el lehet feledkezni róla… ilyenkor szivárog a memória.Kár, hogy ilyenkor szivárog…
Legjobb, hogy gtk-s példaprogramokban is láttam ilyeneket.2007-02-18-21:42 #2088797„Igen ezt tudom pl. egy konténer törlésével a benne lévő widgetek is pusztulnak.”
De ezt egy saját objektummal is el lehet érni.„Legjobb, hogy gtk-s példaprogramokban is láttam ilyeneket.”
Mert azok nem arról szólnak. (De a függvény leírása kiterjed arra, hogy a) gondoskodni kell a felszabadításról, b) esetleg a lefoglalásról is, c) objektum esetén, esetleg csak a létrehozásról)2007-02-18-21:57 #2088798„Mert azok nem arról szólnak. (De a függvény leírása kiterjed arra, hogy a) gondoskodni kell a felszabadításról, b) esetleg a lefoglalásról is, c) objektum esetén, esetleg csak a létrehozásról)”
Attól még normálisan is meg lehetne írni őket. Először azokból próbáltam okosodni…
Néhol elég hiányos a leírás…
Objektumok esetén is kell néha egy g_object_unref, mert máskülönben csúnya dolgok történnek.2007-02-18-22:57 #2088799Bocs, de ez nekem még mindíg homályos!
tipus *fgv1()
{
return ( malloc(0x100) );
}void fgv(tipus *ptr)
{
free(ptr);
}ha most azt mondom
fgv2(fgv1());akkor nyilván nincs memoria probléma, hiszen amit az egyik fügvénnyel lefoglaltál azt a másik a pointer segítségével felszabadítja (a pointert vagy stack vagy regiszterben kapja).
Ennek a példának nincs sok értelme, ez a gondod? -
SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz