játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5471
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2525

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] > 65 < [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]
proof88 - Törzstag | 530 hsz       Online status #116877   2009.09.01 09:28 GMT+1 óra  
textúra amúgy is főként a vramban van, de mi most az általános memóriáról beszélünk.
nem tömbről beszélek, mert az túl specifikus.
egy memóriaterületről, ahova azt raksz, amit akarsz. persze a tömbös példádat értem, de nem így gondoltam. Hanem úgy, hogy írsz egy memóriakezelőt, ami együttműködne az alap memóriakezelővel, pontosabban azzal együtt. Ilyen modellek meg textúrák mennének a szokásos módon, de azok a dolgok, amiket képkockánként kell létrehozni meg törölni, azok egy már előre lefoglalt területen mennének. Olyan ez, mint amikor saját fájlrendszert írsz. Tehát van egy fájl a winyón, ami maga is egy fájlrendszer, benne fájlokkal, amiből a játékod kiszedi a fájlokat. Ott is az az előny, hogy egy helyben van minden, és az eredeti fájlrendszerben nem szétszórva található meg. Létrehozni is könnyebb és törölni is könnyebb egy nagyobb fájlt, mint 1000 db kicsit, hiába ugyanakkora az összterület. Itt is a központi memóriát kíméljük, pontosabban az oprendszert is, mert hozzá nem kell szólni olyan mély szinten képkockánként, ez jó hatással van a sebességre is és stb...
   
dvorgaz - Törzstag | 576 hsz       Online status #116863   2009.09.01 04:01 GMT+1 óra  
De modellek/textúrák nem jönnek létre meg semmisülnek meg olyan gyakran mint füstrészecskék vagy lövedékek.
   
Orphy - Törzstag | 1893 hsz       Online status #116860   2009.09.01 01:37 GMT+1 óra  
Arra gondolsz,

hogy pl egy részecskerendszernél azt mondom, hogy van egy mondjuk 10000 elemű tömböm, amibe kerülhetnek a részecskék (by value), aztán a holtakat újrahasznositom?

Ez egy jó megoldás, csak mindig, mindenhol meg kell csinálni.
Sajnos elég specifikus is, mert a részecske objektumok mind ugyanakkorák méretre.
Ha csak a textúrákat nézzük, akkor ott már lehet több felbontás, és akkor máris minden felbontásra külön kell menedzselni a dolgot... És akkor még van millió féle egyéb game objektum, pl ha csak a modelleket vesszük, ne ott ahány modell, annyi különböző objektumméret...

Csak részecskékre jó, de valahogy jobbnak tűnne egy általános megoldás...
   
proof88 - Törzstag | 530 hsz       Online status #116846   2009.08.31 12:53 GMT+1 óra  
ja hát nem hülyeség az, hogy van egy fixen lefoglalt memóriaterületed, amit aztán te menedzselsz és azokat a dolgokat kezeled benne, amik játék közben sokszor létrejönnek gyorsan és elvesznek... pl. ha füst van, és rengeteg négyszöget generálsz a füstnek (amik ugye füst textúrával vannak textúrázva, átlátszóan, stb...), akkor ott ez jó lehet, és ezek persze törlődnek is egy idő után. De legalább nem kell a rendszernek a memória kezelőjével húzni az időt, mert van egy fixe helyed, amit te menedzselsz viszonylag egyszerűen.
   
fpeti - Törzstag | 1295 hsz       Online status #116843   2009.08.31 12:14 GMT+1 óra  
Én is mostanában memóriakezeléssel (is) foglalkozom, de mindenhol azt olvastam, hogy nincs tökéletes algoritmus, vagy lassú lesz, vagy fragmentál, vagy a leírója lesz óriási, vagy nemtom.
Kedvenc alapesetem, amire gondolva egyből el szoktam vetni a további ez irányú kódolás ötletét:
Van egy nagy ciklus benne egy 4 byteos memóriafoglalás, majd a ciklus végén felszabadul minden második, ekkor hiába üres a memória fele, 5 byte-nak sincsen már hely. Állítólag ez még a windows-nak is lehet probléma (extrém hülye eset mondjuk).

Alapból én kétfelé vettem a problémát, élettartam szerint van az 'állandó memória' manager, ami mindig lapokat foglal le, ha kifogy, és ezt szabdalja akármilyen méretűre, de törölni nem lehet, csak egyszerre az egészet (új pálya töltésekor pl) - nem jegyez üres helyeket.
A rövid élettartamú objektumoknál meg a boost-ban is meglévő pool rendszer lehet a legjobb, azaz külön területet felbontani egyenlő részekre, az üres helyeket pedig láncolt listában tartani, amelynek elemei az üres helyeken vannak (4 byte elég egynek, csak egy index a következőre).

Ezeket nagyon gyorsan meg lehet írni (azért csináltam ), általános megoldással mondjuk sokat lehetne később nyerni- nem kell pool-okat külön létrehozni- de sokkal nehezebb (gondolom).

Engem is érdekel a téma, gondolkoztam már fix kis méretű darabokban pl 16 byte, 256 byte, ezt könnyű nyilvántartani (lista-bittömb), ez meg memóriapazarló lehet ha kevesebb kell - vagy mindig egy byte-tal több - mondjuk lehetne többféle tömb kisebb és nagyobb objektumokban, esetleg a nagyobbakban helyet foglalni a kisebbeknek, pl a 256-os ban helyet foglalni a 16-osoknak. Meg ugye ott vannak az align-olással kapcs. dolgok, ezekkel egyre bonyolódik, ezért választottam a kevésbé rugalmas, de gyors "megoldásokat".
   
proof88 - Törzstag | 530 hsz       Online status #116841   2009.08.31 09:34 GMT+1 óra  
úgy tudom a realloc() is töredezést csinál, gyakorlatilag mindenképp ez lesz, ha rengeteg kis memóriaterületet foglalsz, ez nagy projektnél fontos lehet. valamelyik játéknál volt az, h saját memóriakezelőt írtak, mert belassult a játék egy idő után, mert töredezetté vált a memória...

szerk.: gyakorlatilag mé ne csinálna töredezést, ezt nem tudom minek írtam le...

Ezt a hozzászólást proof88 módosította (2009.08.31 09:53 GMT+1 óra, ---)
   
Orphy - Törzstag | 1893 hsz       Online status #116839   2009.08.31 08:34 GMT+1 óra  
hmm, köszi, megnézem
   
Asylum - Törzstag | 5471 hsz       Online status #116836   2009.08.31 07:12 GMT+1 óra  
Kód:
realloc()
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #116835   2009.08.31 06:59 GMT+1 óra  
Boost-ból tényleg van előreforditott, de csak MSVC-hez találtam, GCC-hez nem...

Memóból amit irtál azt szeretném elkerülni, mert ahhoz, hogy érjen vmit az egész, összefüggő memóriaterület kell. Ergó ha kifutok az első 10MB-ból, akkor kell foglalnom 20MB-ot, és az előbbi 10-et átkopizni oda, hogy sorfolytonos legyen, aztán a régi 10MB-ot kidobni... Ez egyrész nagyobb memóriaterületeknél nem lesz gyors, másrészt ugyanúgy fragmentációt okoz.
   
Asylum - Törzstag | 5471 hsz       Online status #116833   2009.08.31 06:46 GMT+1 óra  
boost-ból van elöre forditott lib is.
Memória: szerintem indulj el mondjuk 10 MB-al, ha ezt túllépi akkor foglalj le még 10 et (ha gyakran csinálja ezt akkor legközelebb mondjuk 20-at). Ha meg nagyon nagyot akar akkor nagyon nagyot.
A defragmentálásra meg találj ki valami hatékony algoritmust (ugyis a memmove fogja telibesz*rni).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
screat - Tag | 382 hsz       Online status #116831   2009.08.31 05:55 GMT+1 óra  
nekem a visual assist x-el vannak problémáim:
Van egy leírás, hogy mit kell csinálni. A 6. pont a következő:
"6. Start Visual Studio and enter the following serial:"
Én ahogy elindítottam, nem volt semmi változás. Nem kért sehol semmiféle serialt, stb. Valahol be kell lőni? ha igen, akkor hol?
még csak padawan...
Dont worry, be hippy - Fanni :)
   
Orphy - Törzstag | 1893 hsz       Online status #116830   2009.08.31 05:48 GMT+1 óra  
Még 1 kérdés:

Gondoltam, megnézem a Boost lib-et, sokan mondtátok már, hogy egész jó...

MingW (CodeBlocks, Eclipse) szeretném belőni, de vannak vele kisebb gondjaim:
- A feltelepitett Python-t nem találja
- A bjam-et le tudom forditani MingW-vel, de ha a boost-ot nem (bjam toolset=mingw hibát dob)
- Sima bjam-el forditva vc-vel fordit, de néhány cucc nem fordul le (failed to compile, internal compiler error). Részletesebbet sajnos nem nagyon tudok, hála a csodás MS konzolnak... Egyszerűen elfelejti a régebbi kiirt szöveg nagy részét...

Szóval ha valaki tud benne segiteni, nagyon örülnék valami mini guide-nak, hogy mit kell tenni vele, hogy minden szuperül menjen... Előre is köszi
   
Orphy - Törzstag | 1893 hsz       Online status #116827   2009.08.31 04:21 GMT+1 óra  
Lenne egy kérdésem


Azon goldolkozom, hogy a Cpp-s framework-ömhöz készitek egy saját memóriamenedzsert, és ezen keresztül szeretném utána az összes memóriafoglalást/felszabaditást csinálni.

A lényeg az lenne számomra, hogy a memóra-fragmentációt valahogy elkerüljem - ha valamit felszabaditok, vagy akár kézzel inditva tudjam defragmentálni a heap-emet. Később esetleg megfejelem még a dolgot refcount-okkal is, hogy kapjak egy mini GC-t.

A kérdés az lenne, hogy erre a feladatra mi a best practice?
Foglaljak le inditáskor egy X méretű memóriát, aztán abba pakoljak (defragnél meg memmove)?
Ha igen, akkor mennyi memóriát érdemes foglalni? Mi van, ha esetleg futás közben kifutok ebből a limitből?

Jó lenne az is, ha gyorsan működne...

Hogyan érdemes ennek nekifutni?
   
sirpalee - Tag | 1282 hsz       Online status #116787   2009.08.30 07:42 GMT+1 óra  
Agreed. Én sem tudom miről beszélek.
raytraceisten és übermedic
   
WToma - Szerkesztő | 635 hsz       Online status #116786   2009.08.30 07:36 GMT+1 óra  
Nincs körkörös include, mert a headerekbe nem kell includolni egymást (esetleg csak azt a headert, ami a fwd deklarált osztályokat tartalmazza) csak a cpp-kbe. Az include gráf körmentes lesz. Vagy b) nem értelek.
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
screat - Tag | 382 hsz       Online status #116784   2009.08.30 07:32 GMT+1 óra  
Sose tudtam mire jó a forward deklaráció. Ez így jó lesz, köszi a választ mindenki
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #116781   2009.08.30 07:22 GMT+1 óra  
A forward deklaráció ugyanúgy nem old meg mindent, ugyanúgy körkörös include... Amit nem ártana kerülni. Amit én javasoltam abban ilyen nincsen.
raytraceisten és übermedic
   
WToma - Szerkesztő | 635 hsz       Online status #116780   2009.08.30 07:19 GMT+1 óra  
Mi a baj a forward deklarációval? Kettős hivatkozás esetén nem lehet megúszni. Az általad javasolt BaseManager-es megoldás is csak továbbrakja a problémát, az interface deklarációt látni kell mindenképpen.
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
sirpalee - Tag | 1282 hsz       Online status #116777   2009.08.30 07:04 GMT+1 óra  
Forward deklaráció? Fúúúj...
raytraceisten és übermedic
   
Asylum - Törzstag | 5471 hsz       Online status #116775   2009.08.30 06:41 GMT+1 óra  
pfff nemkell ide semmi ilyen baromság, ahogy nézem pointereket használsz, ezért bőven elég ha a header fájlban forward deklarálod


Kód:
class Game;

class ContentManager
{
public:
    ContentManager(Game* game);
};


és a cpp fájlban inkludolod be a headert.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #116772   2009.08.30 05:20 GMT+1 óra  
Akkor nem írtad egyértelműen. Csinálj egy ősosztályt egy statikus pointerrel, és azt állítgasd be.
raytraceisten és übermedic
   
screat - Tag | 382 hsz       Online status #116771   2009.08.30 05:07 GMT+1 óra  
Így majd minden esetben ha használni akarom a Game-t, és a Game.h-ba is akarom az illetőt includeolni, mindig kell egy külön osztály, ahogy a lenti példádban?

nekem a game csak annyira kéne, hogy azon keresztül érem el a device-t, meg miegymást.
tehát:

Game.cpp
Kód:
void Game::Initialize()
{
    //....
    contentManager = new ContentManager(this);

    contentManager->Nemtudom();
}

ContentManager* Game::GetContent()
{
    return contentManager;
}


ContentManager.cpp
Kód:
ContentManager::ContentManager(Game* game)
{
    this->game = game;
}

void ContentManager::Nemtudom()
{
    this->device = game->GetDevice(); //vagy akármi...
}


és ugyan így például a modellnél:
Kód:
model = game->GetContent()->LoadModel("zy.x");
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #116770   2009.08.30 05:04 GMT+1 óra  
Valami ilyesmi kéne neked

BaseContentManager.h
Kód:
#pragma once

__declspec(novtable) class BaseContentManager{ // use this before interfaces
public:
virtual void func() = 0;
};


Game.h
Kód:
#pragma once

#include "BaseContentManager.h"

class Game{
public:
void init(BaseContentManager* cm)
{
cm->func();
}
};


ContentManager.h
Kód:
#pragma once
#include "Game.h"
#include "BaseContentManager.h"

class ContentManager : public BaseContentManager{
public:
ContentManager(Game* game)
{
// init code
game->init(this);
}

virtual void fnc()
{
// Do Something
}
};
raytraceisten és übermedic
   
screat - Tag | 382 hsz       Online status #116769   2009.08.30 04:50 GMT+1 óra  
ezekkel az include dolgokkal mindig is bajban voltam.
Kód:
//Game.h
#include "ContentManager.h"

class Game
{
};

//ContentManager.h
#include "Game.h"

class ContentManager
{
public:
    ContentManager(Game* game);
};

erre ugyebár egy akkora hibaüzenetet kapok, mint a ház. Erre mi a megoldás?
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #116575   2009.08.27 12:54 GMT+1 óra  
Idézet
TheProGamer :
Jah meghívódik, csak nem csinál semmit ha NULL pointerre hívjuk meg, szóval szépen itt kiütötték az emberi hülyeséget mint lehetőséget.



De-de csinál , kisérletképpen felülírtam, és megnéztem mi történik. Csak a free meghívva nullára nem fagy ki. (vagy deallocate)
raytraceisten és übermedic
   
Asylum - Törzstag | 5471 hsz       Online status #116572   2009.08.27 12:51 GMT+1 óra  
megoldás:

Kód:
boost::scoped_ptr<T>


C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #116570   2009.08.27 12:49 GMT+1 óra  
Idézet
fpeti :
Idézet
Asylum :
Kód:
alma* alma;




Ilyenkor jön elő az, hogy a debug verzában null-ra iniciál a VS, és szépen működik a gamma, release-ben meg szíjjelfagy.


És az ilyen bugok levadászásátől szoktam agyfaszt kapni.
Reality is almost always wrong. - House

   
fpeti - Törzstag | 1295 hsz       Online status #116569   2009.08.27 12:49 GMT+1 óra  
gaborlabor:
Téényleg, epikusan rossz példa
   
TPG - Tag | 3402 hsz       Online status #116567   2009.08.27 12:48 GMT+1 óra  
Idézet
sirpalee :
De ettől függetlenül a delete meghívódik. Csak nem fagy szét.

Asylum én is úgy tudom hogy van.


Jah meghívódik, csak nem csinál semmit ha NULL pointerre hívjuk meg, szóval szépen itt kiütötték az emberi hülyeséget mint lehetőséget.
Reality is almost always wrong. - House

   
gaborlabor - Moderátor | 4449 hsz       Online status #116566   2009.08.27 12:48 GMT+1 óra  
Idézet
fpeti :
Idézet
Asylum :
Kód:
alma* alma;




Ilyenkor jön elő az, hogy a debug verzában null-ra iniciál a VS, és szépen működik a gamma, release-ben meg szíjjelfagy.


(nem, igazából ilyenkor jön elő az hogy x darab errorral leáll a fordítás olyat sem írunk, hogy int* int)

   
fpeti - Törzstag | 1295 hsz       Online status #116564   2009.08.27 12:46 GMT+1 óra  
Idézet
Asylum :
Kód:
alma* alma;




Ilyenkor jön elő az, hogy a debug verzában null-ra iniciál a VS, és szépen működik a gamma, release-ben meg szíjjelfagy.
   
gaborlabor - Moderátor | 4449 hsz       Online status #116563   2009.08.27 12:46 GMT+1 óra  
nem tud más területre nyúlni _elméletileg_ (acces violation)...
de hogy t_alma *alma NULL-e, az szerintem a tárolási osztálytól is függ... egy globális változó jó eséllyel lesz null szerintem (localnál lesz benne memóriaszemét)... meg ha jól tévedek, még attól is függ, hogy debug avagy release módban fordítod-e. egy szó mint száz, ki kell írni hogy = NULL, mert jobb a békesség

   
sirpalee - Tag | 1282 hsz       Online status #116562   2009.08.27 12:45 GMT+1 óra  
Idézet
TheProGamer :
Idézet
C++ guarantees that operator delete checks its argument for null-ness. If the argument is 0, the delete expression has no effect. In other words, deleting a null pointer is a safe (yet useless) operation. There is no need to check the pointer for null-ness before passing it to delete.

Szerk: Egyébként ez nekem is új, ennek én is most néztem utána.



De ettől függetlenül a delete meghívódik. Csak nem fagy szét.

Asylum én is úgy tudom hogy van.
raytraceisten és übermedic
   
Wolfee - Törzstag | 1337 hsz       Online status #116561   2009.08.27 12:44 GMT+1 óra  
"de mintha az egyes folyamatoknak saját címtartománya lenne, hogy még véletlenül se tudjanak egymás memóriájába belenyúlni (jó is lenne)."
igen, ez így van, nem hülyeség
FZoli jóváhagyásával XD

   
Asylum - Törzstag | 5471 hsz       Online status #116559   2009.08.27 12:42 GMT+1 óra  
hát de pajtás ha csak ennyit mond, hogy

Kód:
alma* alma;


Akkor az a jóéletbe nem lesz nullpointer hanem többnyire egy random szám, a delete meg gyönyörüen letörli a winfos kernelt. Persze ez azért nem egészen igy megy, nem akarok hülyeséget mondani, de mintha az egyes folyamatoknak saját címtartománya lenne, hogy még véletlenül se tudjanak egymás memóriájába belenyúlni (jó is lenne).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #116558   2009.08.27 12:41 GMT+1 óra  
Hmm akkor okos a c++ szabvány Ezt is jó tudni.
raytraceisten és übermedic
   
gaborlabor - Moderátor | 4449 hsz       Online status #116555   2009.08.27 12:38 GMT+1 óra  
ezeket mind jó tudni.
akkor csak arra kell figyelni hogy NULL-al legyen inicializálva.

   
TPG - Tag | 3402 hsz       Online status #116553   2009.08.27 12:36 GMT+1 óra  
Idézet
Asylum :
az elöfordulhat, hogy az oprendszer eltárolja a lefoglalt memóriák cimeit és mivel nem találta ezért nem szállt el...


Nem a rendszer hanem a C++ szabvány ilyen.
Idézet
C++ guarantees that operator delete checks its argument for null-ness. If the argument is 0, the delete expression has no effect. In other words, deleting a null pointer is a safe (yet useless) operation. There is no need to check the pointer for null-ness before passing it to delete.


Szerk: Egyébként ez nekem is új, ennek én is most néztem utána.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5471 hsz       Online status #116552   2009.08.27 12:31 GMT+1 óra  
az elöfordulhat, hogy az oprendszer eltárolja a lefoglalt memóriák cimeit és mivel nem találta ezért nem szállt el...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #116551   2009.08.27 12:31 GMT+1 óra  
Deus Ex Machina
(ಠ ›ಠ) Stewie!

   
Wolfee - Törzstag | 1337 hsz       Online status #116550   2009.08.27 12:30 GMT+1 óra  
mázli
FZoli jóváhagyásával XD

   
screat - Tag | 382 hsz       Online status #116544   2009.08.27 12:13 GMT+1 óra  
Bug, vagy fícsör?
még csak padawan...
Dont worry, be hippy - Fanni :)
   
gaborlabor - Moderátor | 4449 hsz       Online status #116543   2009.08.27 12:13 GMT+1 óra  
ez azért érdekes, mert nálam nem lett tőle fagyi. de tényleg.

szerk: nem direkt írtam ilyen hülyeséget, hanem 1 progban van egy csomó változó, amiket egy másik ojjektum destruktora szabadítana fel, és mikor elkezdtem átírni a progit , már nem lett mindegyikre szükség, és hirtelenjében csak a változók létrehozását (memóriafoglalás stb.) kommenteztem ki, a delete-et bennhagytam. és nem száll el.

   
Joga - Törzstag | 1791 hsz       Online status #116542   2009.08.27 12:11 GMT+1 óra  
Kód:
akarmi *akarmi_ptr = NULL;
if( akarmi_ptr )delete akarmi_ptr
(ಠ ›ಠ) Stewie!

   
fpeti - Törzstag | 1295 hsz       Online status #116538   2009.08.27 12:07 GMT+1 óra  
Idézet
gaborlabor :
Tényleg, abból lehet gond, ha olyat írok, hogy:
akarmi *akarmi_ptr;
delete akarmi_ptr;
Tehát van egy pointerem, nem foglalok le memóriát az ojjektumnak, de törölni akarom. Ettől lehet fagyi?


csak az lehet
   
gaborlabor - Moderátor | 4449 hsz       Online status #116532   2009.08.27 12:02 GMT+1 óra  
Tényleg, abból lehet gond, ha olyat írok, hogy:
akarmi *akarmi_ptr;
delete akarmi_ptr;
Tehát van egy pointerem, nem foglalok le memóriát az ojjektumnak, de törölni akarom. Ettől lehet fagyi?

   
Wolfee - Törzstag | 1337 hsz       Online status #116495   2009.08.27 08:39 GMT+1 óra  
mindent. amit te hoztál léte, neked kell törölnöd. ez egy ilyen világ. ha előveszel egy ollót, nem várhatod el, hogy saját maga visszamásszon a helyére, csak azért, mert már nem használod
FZoli jóváhagyásával XD

   
Asylum - Törzstag | 5471 hsz       Online status #116494   2009.08.27 08:35 GMT+1 óra  
Idézet
M4 :
(ha a dolog aminek átadom a címet törli az objektumot, utána még nekem is törölnöm kell?)



Nyelvi szinten nincs ilyen objektum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #116490   2009.08.27 08:26 GMT+1 óra  
Nem mert akkor szanaszét fagy

De lehet szépen írni managed környezetet is az egész c++ alá és nincs gond . Én is már rászoktam eléggé, hogy mental ray apin belül a saját memory allocator cuccait használom minden osztályhoz, nem pedig a hagyományosat.
raytraceisten és übermedic
   
M4 - Tag | 187 hsz       Online status #116488   2009.08.27 08:11 GMT+1 óra  
"Olyan nincs, hogy neked nem kell törölnöd, minden dinamikusan létrehozott objektumot neked kell törölni"
Nincs igazad
(ha a dolog aminek átadom a címet törli az objektumot, utána még nekem is törölnöm kell?)

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] > 65 < [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]