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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
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] [141]
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 | 5455 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 | 5455 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 | 1291 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 | 1291 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 | 1336 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 | 5455 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 | 5455 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 | 1336 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 | 1291 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 | 1336 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 | 5455 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?)

   
Asylum - Törzstag | 5455 hsz       Online status #116484   2009.08.27 07:13 GMT+1 óra  
Javaslom ilyenekre keress rá, hogy "láthatóság" és "élettartam". Az utóbbi fontosabb.
Egy statikus objektumnak (mint a példában is) az élettartama és a láthatósága is arra a blokkra érvényes amiben deklaráltad. Tökmind1, hogy közben ráállítottál egy pointert vagy referenciát, attól még az megszünik. Tehát igen, másolnia kell a lenti függvénynek.

Dinamikusan létrehozott objektumoknak viszont az élettartama addig tart amig nem mondasz egy delete-et. Olyan nincs, hogy neked nem kell törölnöd, minden dinamikusan létrehozott objektumot neked kell törölni (persze a program végén meg fog semmisülni de addig fantasztikus memory leakeid lesznek).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
M4 - Tag | 187 hsz       Online status #116483   2009.08.27 06:46 GMT+1 óra  
Konkrétan én nem hivatkozom, hanem aminek átadtam. De közben megtaláltam a dokumentációban, hogy ha new-val hozom létre nem nekem kell törölnöm (az egész fát, hanem csak a gyökerét).

   
Wolfee - Törzstag | 1336 hsz       Online status #116482   2009.08.27 06:37 GMT+1 óra  
hát, ha a { } utáni részben hivatkozol az onstack-re, akkor egészen biztosan fogsz futásidőben egy 'onstack not declared in this scope' vagy valami ezzel ekvivalens üzenetet. az onstack nevű változód a }-nál meghal.
FZoli jóváhagyásával XD

   
M4 - Tag | 187 hsz       Online status #116476   2009.08.27 06:18 GMT+1 óra  
Azt szeretném kérdezni, najó, inkább illusztrálom:
Kód:
{
    Myobj onstack(...);
    Valami.add(&onstack, ...);
}

Hiba lehet, ha a blokk után kellenek az onstack adatai? Vagy ez attól függ, mit csinál vele a Valami.add (lemásolja vagy nem)? Vagy ha new-val hozom létre, akkor Valami törlésekor törlődik amit hozzáadtam vagy nem?

   
Asylum - Törzstag | 5455 hsz       Online status #116372   2009.08.25 15:59 GMT+1 óra  
én ennek enumoknál látnám értelmét, mert cpp-ben nem muszáj az enum nevével minösiteni a dolgokat (annyira nem, hogy a fordito nemis engedi). Ekkor egy enum helyett egy class és static const memberek is megteszik (nem foglalódik le memória).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1291 hsz       Online status #116371   2009.08.25 15:29 GMT+1 óra  
Én spec. még sosem használtam se exception-t, se dynamic_cast-ot, jól elvagyok nélkülük.
Apropó, most nézgettem fizikai apikat (havok uber rulez), és sok helyen van osztályon belüli osztály deklaráció, valamiért sok nagy api nincsen oda a névterekért. pl ilyesmi:
Kód:
class valami
{
   struct valamistruct
   {
   };
};

Nekem először fura volt, ez valami bevett szokás?
   
Asylum - Törzstag | 5455 hsz       Online status #116370   2009.08.25 14:56 GMT+1 óra  
És a C-style cast? De szerintem az nem biztonságos.
Egyébként marhára nem értem, hogy minek raknak be ilyeneket a nyelvbe mikor eleve az volt a célja, hogy mentes legyen az ilyen lassito dolgoktol...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #116369   2009.08.25 14:36 GMT+1 óra  
Jah igen es egy aprosag : dynamic castot inkabb ne hasznaljunk. Vagy nagyon ritkab, max framenkent parszor. Ugyanez igaz exceptionokre is. Rossz, csunya szokas, kerulendo. Ok : lassusag.
raytraceisten és übermedic
   
gberes - Tag | 38 hsz       Online status #116368   2009.08.25 13:43 GMT+1 óra  
Hehee sirpalee kódjával működik Az error leírása is pont ezt mondta, de magamtól nem jöttem volna rá soha

Köszi a segítségeteket.

   
Asylum - Törzstag | 5455 hsz       Online status #116367   2009.08.25 13:18 GMT+1 óra  
johogy nem látja ha B -re mutató pointereket tárol...

Kód:
dynamic_cast<C*>(objects.at(0))->fgv(int var);


viszont nem árt ellenörizni, hogy érvényes-e a konverzió; a dynamic_cast 0-t ad vissza ha az adott objektum nem konvertálható arra a tipusra.

szerk.: látom megelöztél
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #116366   2009.08.25 13:17 GMT+1 óra  
Kód:
class B
{
public:
virtual void fgv()=0;
};


helyett

Kód:
class B
{
public:
virtual void fgv()=0;
virtual void fgv(int var)=0;
};


és persze normálisan hívd meg az updateben
raytraceisten és übermedic
   
gberes - Tag | 38 hsz       Online status #116365   2009.08.25 13:14 GMT+1 óra  
3 fájlból áll:

file.h:
Kód:
#include "file2.h"
#include "file3.h"

class A
{
public:
vector<B*> objects;
        void  Update();
C *obj;
A();
};

A::A()
{
obj= new C();
objects.push_back(obj);
}

A::Update()
{
if (...) objects.at(0)->fgv(int var);
}


file2.h:
Kód:
class B
{
public:
virtual void fgv()=0;
};


file3.h:
Kód:
class C : public B
{
public:
void fgv();
void fgv(int var);
};

C::fgv()
{
...
}

C::fgv(int var)
{
...
}

   
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] [141]