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]
Seeting - Törzstag | 2306 hsz       Online status #189308   2012.12.06 05:20 GMT+1 óra  
Thank you very much!
   
Asylum - Törzstag | 5455 hsz       Online status #189307   2012.12.06 00:33 GMT+1 óra  
Fanatikusoknak stateful változat, ami gcc-vel is kell hogy menjen. És mentem is aludni.

Kód:
#include <iostream>

class Debug
{
    struct _helper
    {
        bool notmp;

        _helper() {
            notmp = false;
        }

        _helper(const _helper& other) {
            notmp = true;
        }

        ~_helper() {
            if( notmp )
                std::cout << "\n";
        }

        template <typename T>
        _helper& operator <<(T val) {
            std::cout << val;
            return *this;
        }
    };

private:
    static Debug _inst;

public:
    template <typename T>
    _helper operator <<(T val) {
        _helper h;

        h << val;
        return h;
    }

    static Debug& Get() {
        return _inst;
    }
};

Debug Debug::_inst;

int main()
{
    int a = 2, b = 6;

    Debug::Get() << "Test 1";
    Debug::Get() << "Test 2: " << a;
    Debug::Get() << "Test 3: " << a << ", " << b;

    system("pause");
    return 0;
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5455 hsz       Online status #189306   2012.12.05 23:49 GMT+1 óra  
Ezek a szörnyü programozási problémák...
A default konstruktor definiálása itt lényeges.

Kód:
#include <iostream>

class Debug
{
public:
    ~Debug() {
        std::cout << "\n";
    }

    Debug() {}

    template <typename T>
    Debug& operator <<(T val) {
        std::cout << val;
        return *this;
    }

    static Debug Get() {
        return Debug();
    }
};

int main()
{
    int a = 2, b = 6;

    Debug::Get() << "Values: " << a << ", " << b;
    Debug::Get() << "Test 1: " << a << ", " << b;
    Debug::Get() << "Test 2: " << a << ", " << b;

    system("pause");
    return 0;
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #189302   2012.12.05 23:01 GMT+1 óra  
Pont azt a csúnya \n-et akarta eltüntetni a kódból
(ಠ ›ಠ) Stewie!

   
Asylum - Törzstag | 5455 hsz       Online status #189299   2012.12.05 22:04 GMT+1 óra  
Kód:
pdDebugger::Get() << "Ertekek: " << a << ", " << b << "\n";


Csak ötlet, nem éjtek cépjuszpjuszhoz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
kernel_panic - Tag | 117 hsz       Online status #189296   2012.12.05 19:48 GMT+1 óra  
Én az '\n' hozzáfűzésére gondoltam...

   
Seeting - Törzstag | 2306 hsz       Online status #189293   2012.12.05 19:35 GMT+1 óra  
Idézet
kernel_panic :
Idézet
Joga :
esetleg maga az out emelhetné a sort, mielőtt kiírnád bele a dolgokat.


Vagy akár a Flush() is hozzáfűzhetné...



A Flush()-t nem fűzhetem az Out()-hoz mert jelenleg most így van megoldva az Out():

Kód:
std::stringstream& Produck::pdDebugger::Out()
{
*(GetInstance().dbg) << "\n";
return *(GetInstance().dbg);
}


És a dbg egy stringstream. Így nem kellett külön megírni a "<<" operátorokat.

SZERK.: Max úgy fűzhetném hozzá, ha mindig csak az utolsó előtti sor íródna ki. Az meg félrevezető lehet
   
Seeting - Törzstag | 2306 hsz       Online status #189292   2012.12.05 19:33 GMT+1 óra  
Ja már rájöttem. Destruktorban ki akartam törölni egy const char*-t.
   
Joga - Törzstag | 1791 hsz       Online status #189291   2012.12.05 19:28 GMT+1 óra  
Nem muszáj dinamikusan létrehozni, de statikusan létrehozva lehet, hogy másolat készül a példányról és az eredeti törlődik, szóval ilyenek is közrejátszhatnak, ha ott van hiba ott száll el. debugger mit mond?
(ಠ ›ಠ) Stewie!

   
kernel_panic - Tag | 117 hsz       Online status #189289   2012.12.05 19:25 GMT+1 óra  
Nem lehet, hogy a létrehozás módja a ludas? new-val esetleg? (bár mostanában nem c++-oztam, úgyhogy csak egy tipp).

   
kernel_panic - Tag | 117 hsz       Online status #189288   2012.12.05 19:21 GMT+1 óra  
Idézet
Joga :
esetleg maga az out emelhetné a sort, mielőtt kiírnád bele a dolgokat.


Vagy akár a Flush() is hozzáfűzhetné...

   
Seeting - Törzstag | 2306 hsz       Online status #189287   2012.12.05 19:20 GMT+1 óra  
Még egy kérdés. Írtam egy kis exception típust, de ahányszor le akarom tesztelni, sosem ér el a futás a catch() részig, hanem az egész program elszáll és a VS a képembe mászik, hogy DEBUG ASSERTION FAILED.

Ezt mi okozhatja rendszerint?

Kód:
try {
pdDebugger::Out()<<"try";
throw (pdException(1, "Loop in SceneGraph"));
}
catch (pdException e)
{
pdDebugger::Out()<<e.What();
}
   
Joga - Törzstag | 1791 hsz       Online status #189285   2012.12.05 18:56 GMT+1 óra  
Esetleg trükkös módon az első << egy másik típusú onjektumot ad vissza, amire szintén ugyanúgy fog működni a többi <<, viszont amikor a végén felszabadul, emeli a sort, bár ez már kicsit trükközés

Szerk.: Ennek annyi előnye lehet, hogy nem feltétlenül kell az Out függvényt minden kiírásra megírni, elég egyszer lekérdezni a logger osztályt.
(ಠ ›ಠ) Stewie!

   
Seeting - Törzstag | 2306 hsz       Online status #189279   2012.12.05 18:01 GMT+1 óra  
Valóban! Köszi!
   
Joga - Törzstag | 1791 hsz       Online status #189278   2012.12.05 17:35 GMT+1 óra  
esetleg maga az out emelhetné a sort, mielőtt kiírnád bele a dolgokat.
(ಠ ›ಠ) Stewie!

   
Seeting - Törzstag | 2306 hsz       Online status #189276   2012.12.05 17:21 GMT+1 óra  
Már mindegy... Megoldottam úgy ahogy panic mondta. Nem tetszik, de ez van. Most így néz ki:

Kód:
pdDebugger::Out()<< "Garbage collector contains: " << pdGC::Count() << " objects. \n";
pdDebugger::Flush();


Konkrétan a \n-el és a Flush() kiírásával van bajom, de már nem szenvedek vele többet.

Köszi a segítséget!

Ezt a hozzászólást Seeting módosította (2012.12.05 17:28 GMT+1 óra, ---)
   
borsi - Tag | 180 hsz       Online status #189275   2012.12.05 16:54 GMT+1 óra  
Esetleg a C++11-es variadic template lehet még megoldás, de azt nem ismerem.
Ezzel a fő gond(om nekem), hogy nem támogatja még a microsoft fordítója.

   
kernel_panic - Tag | 117 hsz       Online status #189274   2012.12.05 16:31 GMT+1 óra  
Szerintem a központi probléma, hogy tulajdonképpen az utasítás végével (pontosvessző ) szeretnéd jelezni a Debugger instance-nak, hogy végeztél a sorral, és szeretnéd kiírni - csakhogy szerintem ezt a mechanizmust nem lehet megvalósítani, így valamiképp manuálisan kell jelezned, hogy készen vagy.

   
borsi - Tag | 180 hsz       Online status #189273   2012.12.05 16:30 GMT+1 óra  
Balról jobbra értékelődik ki, attól tud több paramétert is fogadni sorban, hogy az operátorod mindig returnöli a debuggeredet. Pl valami ilyesmi is lehetne az implementáció:

Kód:
struct println{};

debugger & operator<<(debugger & dbg, const int param)
{
    dbg.addParam(param);  //ez pl írhatja egy belső stringstreambe a paramétereket
    return dbg;
}

debugger & operator<<(debugger & dbg, const println param)
{
    dbg.writeParamsOut()
    return dbg;
}

...

Debugger::Get()  << "a" << "s" << "d" << "f" << println();

   
Seeting - Törzstag | 2306 hsz       Online status #189272   2012.12.05 15:53 GMT+1 óra  
A Get() az csak egy referenciát ad vissza a debuggerhez. Vagy hogy értékelődik ki ez a sor?

Kód:
Debugger::Get()<<"Értékek: " << a << ", " << b;

(", " << b;)

(a << (", " << b;))

("Értékek: " << (a <<( ", " << b;)))

(Get()<<("Értékek: " << (a << (", " << b;))))


Így?
   
kernel_panic - Tag | 117 hsz       Online status #189271   2012.12.05 15:50 GMT+1 óra  
Kód:
// Mondjuk a Get metódusban kiírod,
// hogy "\nÉrtékek",
// majd az << operátorban, hogy ": érték " ?
// Persze akkor így fog kinézni:
Értékek: 10 : 3.14

Ja nem, ez se jobb így...

szerk:
Egyébként miért kényelmetlenebb ez?
Kód:
(Debugger::Get() << "Értékek: " << a << ", " << b).println();

   
Seeting - Törzstag | 2306 hsz       Online status #189270   2012.12.05 15:38 GMT+1 óra  
Ez nekem nem felel meg. Én olyan szintaxist akarok, hogy:

Mostantól a MyInstance egy Debugger (singleton pattern).
Kód:
int a = 10;
float b = 3.14f;

Debugger::Get()<<"Értékek: " << a << ", " << b;


És ezen sor végrehajtása után jelenjen meg a debug.txt-ben a következő:

Kód:
Értékek: 10, 3.14


Ezt nem lehet megoldani így?
   
kernel_panic - Tag | 117 hsz       Online status #189269   2012.12.05 15:33 GMT+1 óra  
Kód:
// Ha ez...
MyInstance << a << b << c << d << e;

// ...egyenértékű ezzel...
MyInstance << a;
MyInstance << b;
MyInstance << c;
MyInstance << d;
MyInstance << e;

/* ...akkor nem tudod megállapítani, hogy melyik az utolsó elem, hisz pont az a lényege, hogy akárhány elemmel megismételheted ezt. A legegyszerűbb megoldás talán az, ha manuálisan hívsz meg valami függvényt, ez is megvan egy sorból: */
(MyInstance << a << b << c << d << e).done();


szerk:
Matzi megoldása is használhatónak tűnik...

   
Matzi - Szerkesztő | 2521 hsz       Online status #189268   2012.12.05 15:32 GMT+1 óra  
Kreálj egy sorvég jelet, amiről egyértelműen tudod, hogy na most kell írni. Ronda, de működik.
Amúgy meg sehogy, ez nem dinamikus mennyiségű paraméter, hanem ugyanaz a hívás többször.

A műveletek sorrendjét ha jól tudom az operátorok definiálják, így valószínűleg nem változtatható meg.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Seeting - Törzstag | 2306 hsz       Online status #189267   2012.12.05 15:21 GMT+1 óra  
Jó, de honnan tudjam mikor van vége? Melyik a legutolsó ami bejön? Mert nekem ekkor kéne eltárolni az egészet egy sorként vagy fájlban vagy vectorban, akárhol.
   
kernel_panic - Tag | 117 hsz       Online status #189266   2012.12.05 15:05 GMT+1 óra  
Ahogy a leírásból kiveszem, azt kell csinálni, hogy az << operátor mindig az ostream referenciáját adja vissza (ebben az esetben a MyInstance-ét), így gyakorlatilag ugyanaz történik, mintha ezt írnád:
Kód:
MyInstance << a;
MyInstance << b;
MyInstance << c;
MyInstance << d;
MyInstance << e;


szerk:
Vagy ha így szemléletesebb:
Kód:
((((MyInstance << a) << b) << c) << d) << e;


szerk2:
Viszont erről nekem is eszembe jutott egy kérdés: azt vajon hogyan lehet elérni, hogy a műveleteket 'jobbról-balra' hajtsa végre (mint az = operátornál) ?

Ezt a hozzászólást kernel_panic módosította (2012.12.05 15:23 GMT+1 óra, ---)

   
Seeting - Törzstag | 2306 hsz       Online status #189265   2012.12.05 14:39 GMT+1 óra  
Hogy ofstream-el térjek vissza és írjak még egy túlterhelést ami meg ofstreamet vár? Vagy nem értem...
   
Matzi - Szerkesztő | 2521 hsz       Online status #189264   2012.12.05 14:28 GMT+1 óra  
Egyszerre sehogy. De ha a stream jellegű megoldásra gondolsz, akkor az operátor végeredményben az adott objektummal tér vissza, amelyiken meghívod, és így szépen sorban megkapod mindegyik paramétert egyesével.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Seeting - Törzstag | 2306 hsz       Online status #189262   2012.12.05 14:17 GMT+1 óra  
Hogy lehet úgy túlterhelni a '<<' operátort, hogy több változót is képes legyen fogadni egyszerre?

Ehelyett:

MyInstance << a;

így:

MyInstance << a << b << c << d << e;
   
ddbwo - Tag | 1625 hsz       Online status #188882   2012.11.15 21:15 GMT+1 óra  
Nem fölényeskedésnek szánom, de a file kezelés függvényeinek megismerése kb a második hetes teendők közé tartoznak. Tudom, meg kell említeni akkor is, ha egyértelműnek tűnik, hátha, de minden rendben van, semmi sincs elírva.

A fread-nél szinte mindegy hogy írjuk, a két számot összeszorozza egy számmá, mivel az adat void-ként kerül be.

a "fseek (file, 0 , SEEK_SET);" megegyezik egy "rewind(file)"-al. Mivel a file nulláról indul, nem sok minden történik.

a memset hatástalan.
---

Mindegy, kicsit kijjebb szedtem a dolgokat, és eggyel beljebb helyeztem az egészet a game_loop elejébe, most működik, és a fő program loading-nál vissza is tud térni ha kéne.
Ami a pláne, hogy érintetlen a kód, se több, se kevesebb hívás meg átadás nem került bele, de most simán megy "tgaSaveRGBA(img2,sW,sH);" nélkül is.

u.i.: Asylum által javallott programot meg nem tudom letölteni, mert mindig kerül bele a mobilnet miatt hiba... Kicsit szór a letöltés...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Joga - Törzstag | 1791 hsz       Online status #188862   2012.11.15 10:34 GMT+1 óra  
tipp a túlindexelés kiderítéséhez:
eleve x byte-al többet foglalsz le, és ezt feltöltöd valami egységes elemmel, pl 'n'
Ha túlindexelnéd alapból a tömböt, akkor ezek az 'n'-ek változnak meg, ha nem, akkor máshol van a hiba.
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #188852   2012.11.15 06:28 GMT+1 óra  
Én kipróbálnék egy memset 0-t az img-re. Illetve nem tudom, hogy az adott fileal olvasol-e előtte, ha igen, akkor kell egy
Kód:
fseek (file, 0 , SEEK_SET);

Ezen felül - bár nincs jelentősége -, de az fread paraméterei:
Kód:
size_t fread ( void * ptr, size_t size, size_t count, FILE * stream );
- size: egy element mérete byteokban
- count: ahány ilyen element van.

Azaz pl. 10db 4byte-os intet akarsz olvasni egy arraybe, akkor
Kód:
fread(arr, 4, 10, file);

Ezen felül ebből a kódból többet nem tudunk mondani, keresd meg a hibát, valahol biztos elnézed

   
ddbwo - Tag | 1625 hsz       Online status #188844   2012.11.14 19:48 GMT+1 óra  
A legalsó (harmadik) korábbi linkelt kód értelmezésében:

mint írtam, kicsit más szerkezetben pontosan működik, ha kiírom a tga-t akkor se jelenik meg hiba. Tehát nem index hiba.
Kód:
{
        openBSP("dm_bwo_undercranes.bsp");

        // ... file megnyitások, vmt elemzések, clean up, stb.
    }
        // ... file megnyitás, offset számolás

        BYTE *img;
        img = new BYTE[cSize];
        fread(img,cSize,1,vtfFile);

        BYTE *img2;
        img2 = new BYTE[dSize];
        dDXT5(img,img2,sW,sH);
       
        tgaSaveRGBA(img2,sW,sH); //<----

        mipLinTexD(img2,sW,sH);

        delete[] img;
        delete[] img2;

        // fclose
    }
   
    game_loop();

}

Ezt a hozzászólást ddbwo módosította (2012.11.14 20:53 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pretender - Törzstag | 2498 hsz       Online status #188837   2012.11.14 18:04 GMT+1 óra  
Hát persze, ez a két függvény biztos önmagát hívja csak.
Kód:
buffer_meret_foglal();
szamitasok();

Persze nekem mindegy, nem az én problémám...

   
ddbwo - Tag | 1625 hsz       Online status #188835   2012.11.14 18:00 GMT+1 óra  
Nem túlindexelés. Ugyan az marad a kód. A sorrend is, meg minden. Ráadásul a túlindexelésnél azonnal kilép, de itt még befejez szinte mindent.
Közbe a varázslat segítségével átléptem a cuccon és már megcsináltam a többit, de majd valahogy ki kell javítani így is.

Be azért nem rakok részletesebb kódot, mert az sem ad több infót, mivel kb ugyanígy nézne ki... xd
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5455 hsz       Online status #188834   2012.11.14 15:49 GMT+1 óra  
Minden hasonlo hibara:

application verifier

nem, nem tertem vissza, de nem birom mar ezt nezni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
SX - Törzstag | 361 hsz       Online status #188832   2012.11.14 12:34 GMT+1 óra  
Igen, első blikkre én is azt tudom mondani, hogy túlindexelés, vagy valami hasonló lehet. A többi fgv. kódját berakod?

   
Pretender - Törzstag | 2498 hsz       Online status #188826   2012.11.14 06:42 GMT+1 óra  
Nem lehet, hogy simán túlindexeled? Elnézed a méretet, akármi.
Konkrétabb kód esetén jobban tudnánk segíteni.

   
ddbwo - Tag | 1625 hsz       Online status #188823   2012.11.13 23:10 GMT+1 óra  
Találtam egy disasm-et, de ez csak console-ban végigpörgeti a betüket és semmi nem történik, pedig a readme-t követtem... na mindegy.

calloc, malloc, new, mindent próbáltam, de vmi hiba van vele fwrite nélkül mindig.... Még sima tömbbel is.

Fekete mágia!
----------------------

-load to buffer, convert to buffer2, export to file, remove the file, upload the buffer2...
-why do you export to file?
-Sssh, noob! This is MAGIC!

Ez életem első bugja. Hát elég idegelő...

Ezt a hozzászólást ddbwo módosította (2012.11.13 23:50 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
versio - Tag | 664 hsz       Online status #188822   2012.11.13 22:20 GMT+1 óra  
disasm , aztan megnezed a verem mutatot, megnezed mi van benne, aztan kiderited van e kulonbseg a belepes es kilepes kozott
   
ddbwo - Tag | 1625 hsz       Online status #188821   2012.11.13 22:14 GMT+1 óra  
De mivel? Szó szerint nem történik semmi közte, csak annyi kerül be elötte hogy fwrite(), és máris jó. Ez még csak a sima betöltésnél van.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
versio - Tag | 664 hsz       Online status #188820   2012.11.13 22:08 GMT+1 óra  
talan felulirja a vermet
   
ddbwo - Tag | 1625 hsz       Online status #188818   2012.11.13 21:57 GMT+1 óra  
Még annyi érdekesség van, hogy akkor szakad ki, mikor "kijönne" a függvényből. még a benne levő utolsó printf()-et is elvégzi... ???

filet becsukom, mindent szabályosan törlök, papírforma szerint minden szabályos...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
ddbwo - Tag | 1625 hsz       Online status #188817   2012.11.13 21:40 GMT+1 óra  
Egy teljesen értelmetlen bug(?)-ba ütköztem:

van egy BYTE buffer-em full szabályosan lefoglalva, amiből szeretnék betölteni textúrát.

Ha ezt függvényen kívül használom, rendesen működik. Pl.:

Kód:
{
    BYTE *buffer;
    buffer_meret_foglal();
    szamitasok();
    texturabetolt();
   
    game_loop();
}

De ha a betöltési dolgok egy függvényen belülre kerülnek, akkor read error.
Kód:
{
    {
        BYTE *buffer;
        buffer_meret_foglal();
        szamitasok();
        texturabetolt();
    }
   
    game_loop();
}

DE!!! Ha a betöltési dolgok egy függvényben vannak, viszont a számítások után kiírom a buffert egy file-ba, és attól függetlenűl ugyanúgy a régi buffer -ből töltöm be a képet, hiba nélkül végigmegy...
Kód:
{
    {
        BYTE *buffer;
        buffer_meret_foglal();
        szamitasok();
       
        fwrite_al_kiir(); //<-----
       
        texturabetolt(); // a változatlan bufferből
    }
   
    game_loop();
}


Mi kerüli el a figyelmem? Mivel lehet kijavítani? Mert az automatikus működéshez mindenképpen függvényben kellene lennie, ha meg konvertálom az összes file-t, nincs értelme a buffernek, és a disk space-t is meríti.
---

UI: minden esetben ugyanúgy törlöm a buffer-t azonnal a "texturabetolt();" meghívása után.

Ezt a hozzászólást ddbwo módosította (2012.11.13 21:55 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Seeting - Törzstag | 2306 hsz       Online status #188714   2012.11.10 22:42 GMT+1 óra  
Köszi!
   
Joga - Törzstag | 1791 hsz       Online status #188712   2012.11.10 21:31 GMT+1 óra  
a clear nem fogja felszabadítani a mutatott értékeket, ezért a fenti kód helyes.
(ಠ ›ಠ) Stewie!

   
Seeting - Törzstag | 2306 hsz       Online status #188710   2012.11.10 21:19 GMT+1 óra  
Kód:
std::vector<Object*> trash;


Törlésnél melyik a helyes?

Kód:
for (int i=0; i<trash.size(); i++)
{
delete trash[i];
}
trash.clear();


vagy
Kód:
trash.clear();


?
   
Pretender - Törzstag | 2498 hsz       Online status #188706   2012.11.10 19:08 GMT+1 óra  
Hmm, lett végül egy megoldás:
Készítettem egy DllLogger nevű osztályt is, aminek meg lehet adni egy Logger példányt és a 3 Write függvényét function pointerként. (Write - Error, Debug, Warning). Ekkor nekem a dll oldalon azt kell mondanom, hogy
Kód:
DllLogger::GetInstance()->WriteError("blabla");

ez pedig a function pointeren keresztül belehív az enginebe, ahol már van egy "valós példány" a loggerből, aminek így meghívja a WriteError függvényét. Kicsit komplikált lett, de így működik szépen, és nem kellett a loggert kiemelni egy külön osztályba.

   
Pretender - Törzstag | 2498 hsz       Online status #188702   2012.11.10 06:52 GMT+1 óra  
Van egy kis problémám. Csináltam hozzá egy csodaszép ábrát is

Tehát van egy Base projektem, ami dll-be vagy lib-be fordul, mind a kettő elfogadható számomra, a megoldástól függ ugye.
Ebben a Base valamiben vannak különféle Helperek, alap osztályok (Vector2, MathHelper, String, stb.), amit ugye jó lenne mindenfelé használni (A, B, C -> ezáltal D).

Jelenlegi állapot: lib-ként fordítom, ekkor szépen megoldja az exportálgatást, kikerülnek a static-ek is, minden jó. A probléma csak annyi, hogy ott van pl. a Logger osztályom, ami egy Singleton. Magát az osztályt meg a függvényeit szépen kiexportálja, csak ha én nyomok egy CreateInstance-t az exe-ben, akkor arról az instance-ról a dll-ek úgymond nem fognak tudni.
Ha meg követem az "eredeti Singleton" mintatervet, miszerint az Instance() létrehozza, ha szükséges, akkor több helyről próbálom egyszerre ugyan azt a filet írni, ami nem egy egészséges dolog.

Ha dll-ként exportálom, akkor jönnek a különféle problémák a static const memberekkel, meg a static függvényekkel.

Mi arra a legjobb megoldás, hogy a Base-t lássa mindenki szépen, és ha ott legyártok valamit, arról tudjon mindenki? Vagy valami ilyesmi.

   
cclonix - Tag | 6 hsz       Online status #188480   2012.11.01 14:11 GMT+1 óra  
Ha az idom engene, akkor lehet, hogy elmennek a talalkozora, bar en meg igencsak friss vagyok itt leszamitva egy regebbi versenyen valo reszvetelemet. Koszonom, hogy mindezeket leirtad, meg is fogom majd otthonrol, asztali geprol nezegetni, viszont azt nem fogom megtudni beloluk (valoszinuleg) hogy ki mire a legbuszkebb az alkotasai kozul - hiszen fokepp erre lettem volna kivancsi, de azert majd szetnezek! : )

   
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]