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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
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] [143]
Asylum - Törzstag | 5511 hsz       Online status #190191   2013.01.11 11:31 GMT+1 óra  
Ezert van/kell a weak_ptr. Ilyenkor a scene manager az egyetlen shared owner, a node-okon belul pedig csakis weak_ptr-el hivatkoznak egymasra. Ezzel megoldodik a problema.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #190190   2013.01.11 11:29 GMT+1 óra  
Alapesetben az alma is csak a scope végén szabadul fel. Csak azt akarom hogy legyen benne egy kierőszakolt rekurzív törlés is. Erre írtam a Release()-t. Egyébként a node objektumok sosem halnának meg, mert oda-vissza mutatnak egymásra, mint gyerek és szülő. Ha véget is ér a scope, akkor sem lesz 0 a ref count mert a barack mutat az almára és fordítva.

Nem tudom, csak jó dolognak tűnt, hogy ha ki akarok törölni egy teljes ágat a fából, akkor azt meglehessen csinálni úgy, hogy 100%-ig biztos vagyok benne, hogy az összes gyerek kitörlődött.
   
Asylum - Törzstag | 5511 hsz       Online status #190189   2013.01.11 11:19 GMT+1 óra  
De az alma mert torli a gyerekeit? Csak a refcountjuk kene csokkenjen, pont ez a lenyege a smart pointernek. A gyerek tenyleges felszabaditasa meg majd a scope vegen fog megtortenni a 7. lepesben.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #190187   2013.01.11 10:30 GMT+1 óra  
Az én problémám:

1. Lépés

Kód:
pdPointer<pdNode> alma = new pdNode();
pdPointer<pdNode> barack = new pdNode();


2. Lépés

Kód:
alma->AddChild(barack );


3. Lépés

Kód:
alma.Release();  // Explicit beletesszük az almát a garbage collectorba
pdGC::Clear();      // Memória felszabadítása


4. Lépés

Olyan mechanikát valósítottam meg, hogy ha egy pdNode destruktora meghívódik, akkor törlődik az összes gyereke is a node-nak.

5. Lépés

Az alma.Release() miatt törlődött a barack objektum is. Viszont a barack pdPointer értéke nem változott.

6. Lépés

Véget ér a scope, a barack törölni akarja magát.

7. Lépés

Double free.
   
Asylum - Törzstag | 5511 hsz       Online status #190186   2013.01.11 10:18 GMT+1 óra  
Mint emlitettem ilyenkor letrejon egy temporalis, tehat nem.

A problemat nem egeszen ertem, de engem is zavar, hogy a boost::shared_ptr-ben nem lehet egy hivassal az osszes pointert resetelni (v nemtom h hogyan).

En ezt ugy oldom meg, hogy van egy kill() metodus, ami invalidaltatja a smart_counter-t igy az osszes smart_ptr ami azt hasznalja invalid lesz onnantol, ami azt jelenti hogy nem lehet oket dereferalni, de egyebkent ugyanugy mukodnek (igy nem leakelnek el). Persze ez igy egy eleg komoly overhead ugyh csak debug modban erdemes.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #190185   2013.01.11 10:09 GMT+1 óra  
Asylum: Ha így adom át, hogy:

static void RemoveParticularPointer(const pdPointer<pdObject> &ptr);

Akkor a híváson belül tudom pdPointer<pdObject> * -ként tárolni igaz? És így le sem másolódik a pointer. Right?
   
Seeting - Törzstag | 2306 hsz       Online status #190184   2013.01.11 10:04 GMT+1 óra  
Hogy gondoltad pontosan?
   
Joga - Törzstag | 1791 hsz       Online status #190183   2013.01.11 09:55 GMT+1 óra  
tipp: move operatorral nem lehet megoldani?
(ಠ ›ಠ) Stewie!

   
Seeting - Törzstag | 2306 hsz       Online status #190182   2013.01.11 09:51 GMT+1 óra  
Azért akartam smart pointerre mutató pointerekkel dolgozni ebben az esetben, mert ha lemásolok egy smart pointert a tárolóba, akkor keletkezik egy új smart pointer és növeli az object ref countját, és az object nem fog meghalni egy scope végén mert a tárolóban mindig fog rá mutatni valaki. Ezt akartam elkerülni. Nekem a tároló csak arra kell, hogy ha egy objektumra explicit meghívja valaki a Release()-t, akkor tudjam hogy kik mutatnak rá, hogy át tudjam őket állítani NULL-ra, és ne maradjon olyan smart pointer ami nem létező címre mutat.
   
Asylum - Törzstag | 5511 hsz       Online status #190181   2013.01.11 09:50 GMT+1 óra  
Azert mert:

Kód:
void foo(const smart_ptr<Base>& p) {}

int main()
{
    smart_ptr<Derived> dp(new Derived());

    foo(dp); // meghivodik a lenti templates copy constructor
}


de:

Kód:
smart_ptr<Base>* pb = &dp;


ez mar forditasi hiba, hiszen a ket kulon peldanyosult smart_ptr-es osztalynak semmi koze nincsen egymashoz! Olyan mintha ezt irtad volna le:

Kód:
class A { Base* p; };
class B { Derived* p; };


Semmi kozuk egymashoz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #190180   2013.01.11 09:44 GMT+1 óra  
Idézet
Asylum :
szerk.: bocs most vettem eszre...te ket smart_ptr-re mutato pointert akarsz konvertalni, ami hogy a turoba is mukodhetne...ilyenekre soha ne csinalj pointert; vagy ertek v referencia szerint add at (ahhoz a fenti meg megfelelo)



Miért?
   
Pretender - Törzstag | 2498 hsz       Online status #190178   2013.01.11 08:51 GMT+1 óra  
Igen, az is érthető végül is. A template ugye c++ban úgy működik, hogy fordítás időben kifejti, azaz n db "ugyan olyan" osztályt készít. Mondjuk abban az esetben meg mindegy, hogy a pdNode a pdObject leszármazottja, mert ez két külön osztály lesz ezáltal.
Olyan, mintha azt mondanád (nyilván ilyen nincs c++ban, csak szemléltetés...), hogy
Kód:
class A := Produck::pdPointer<pdNode*>
class B := Produck::pdPointer<pdObject*>

void RemoveParticularPointer(B* const obj) { }

// majd meghívnád az A-val, ami nem a gyereke a B-nek
RemoveParticularPointer(new A());

Gyanítom valami ilyesmi lehet a háttérben, de nem értek hozzá...

szerk.:
Most látom, amit Asy írt. Igen, az egy egész szép megoldás

   
Asylum - Törzstag | 5511 hsz       Online status #190177   2013.01.11 08:48 GMT+1 óra  
Csak ugy magatol nem megy az, kell a pdpointer osztalynak egy templates copy constructor (es akkor nyilvan operator = is)

Kód:
template <typename value_type>
template <typename derived_type>
smart_ptr<value_type>::smart_ptr(const smart_ptr<derived_type>& other)
{
    ptr = 0;
    counter = 0;

    operator =<derived_type>(other);
}

template <typename value_type>
template <typename derived_type>
typename smart_ptr<value_type>& smart_ptr<value_type>::operator =(const smart_ptr<derived_type>& other)
{
    _tidy();

    ptr = other.ptr;
    counter = other.counter;

    if( counter )
        counter->smart_inc();

    return *this;
}


Ha igy se megy akkor pls valami komplettebb kodot masolj be.


szerk.: bocs most vettem eszre...te ket smart_ptr-re mutato pointert akarsz konvertalni, ami hogy a turoba is mukodhetne...ilyenekre soha ne csinalj pointert; vagy ertek v referencia szerint add at (ahhoz a fenti meg megfelelo)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #190174   2013.01.11 07:41 GMT+1 óra  
Akkor meg ezt kapom:

Kód:
error C2664: 'Produck::pdRegistry::RemoveParticularPointer' : cannot convert parameter 1 from 'Produck::pdPointer<T> *const ' to 'Produck::pdPointer<T> *const '
1>        with
1>        [
1>            T=Produck::pdNode
1>        ]
1>        and
1>        [
1>            T=Produck::pdObject
1>        ]


Szerintem a pdPointer<pdNode>-ot nem tudja átkonvertálni pdPointer<pdObject> -re. Pedig a pdNode a pdObject leszármazottja.
   
Pretender - Törzstag | 2498 hsz       Online status #190144   2013.01.10 11:56 GMT+1 óra  
Lehetséges, hogy az adott objektum konstans? A helyedben a RemoveParticularPointer-nél is beírnám a const-ot a * után, annak átadható const is meg "sima" is.
Sőt, ha valaki függvénynek pointert adok át, akkor szinte mindig odaírom, a * után a const-ot (a fent említettek miatt).
Kód:
void set(Pointer* const obj);

   
Seeting - Törzstag | 2306 hsz       Online status #190142   2013.01.10 10:53 GMT+1 óra  
Ja már lehet, hogy rájöttem.
   
Seeting - Törzstag | 2306 hsz       Online status #190141   2013.01.10 10:41 GMT+1 óra  
Most már csak az a kérdésem, hogy a this operátor miért generál ebben az esetben error C2664-et?

pdPointer:
Kód:
template <class T> void pdPointer<T>::Detach()
{
pdRegistry::RemoveParticularPointer(this);
if (pObject != NULL)
{
...
}
}


pdRegistry:
Kód:
void Produck::pdRegistry::RemoveParticularPointer(Produck::pdPointer<Produck::pdObject>* ptr)
{
     ...
}


error C2664: 'Produck::pdRegistry::RemoveParticularPointer' : cannot convert parameter 1 from 'Produck::pdPointer<T> *const ' to 'Produck::pdPointer<T> *'
   
Seeting - Törzstag | 2306 hsz       Online status #190140   2013.01.10 10:27 GMT+1 óra  
De igen. Sikerült, köszi!
   
Pretender - Törzstag | 2498 hsz       Online status #190139   2013.01.10 10:14 GMT+1 óra  
forward deklaráció a tárolóba:
Kód:
class PointerType;

// header
class Handler
{
    std::vector<PointerType*> pointers;
};

// cpp
#include "PointerType.h"

A pointer type-ban meg simán beincludeolod (vagy fordítva, ahogy tetszik)

Forward deklarációkor nyilván a headerben nem tudod a PointerType-ot "használni", mert nem ismeri a symbolokat, stb.

szerk.:
Most látom a szerkesztést
Az nem lehet, hogy azért van, mert a headerben próbálod használni is? Vagy a cpp-ben nincs beincludeolva.
Kód:
class A;

class B
{
    A* a;
    inline void do() { a = new A(); } // <--- hiba
};

   
Seeting - Törzstag | 2306 hsz       Online status #190137   2013.01.10 10:01 GMT+1 óra  
Van egy pointer típusom, és van egy tároló singleton osztályom ami ezeket menedzseli. A tároló a pointer típust tárolja, szóval azt be kell include-olnom, a pointer típus meg használja a tároló metódusait, szóval azt meg abba kell beinclude-olnom. Így viszont ez kereszt hivatkozás. Hogy tudnám ezt kiküszöbölni?

SZERK: Ha az egyiket forward deklarálom, akkor meg:

error C2027: use of undefined type 'Produck::pdPointer<T>

Ezt a hozzászólást Seeting módosította (2013.01.10 10:12 GMT+1 óra, ---)
   
Asylum - Törzstag | 5511 hsz       Online status #190028   2013.01.04 12:37 GMT+1 óra  
Ezt meg se hallottam.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #190026   2013.01.04 10:24 GMT+1 óra  
Ha a stack mérete általában olyan 1-2Mb, akkor mi történik, ha overflowol?
Például ha én minden vertexhez le akarom tárolni a 4db bone indexet:
Kód:
uint8 indices[4];

akkor ez ugye 4 byte. Ha van egy 10.000 vertexes modell, és ebből mondjuk 1000 db (ami azért lazán előfordulhat, nemde? ), akkor az 4 * 10000 *1000 = 40000000 byte = 39062.5 kb = 38.14697265625 mb. Vagy hogy is van ez?

szerk.:
Ja, de ha mondjuk
Kód:
VertexBone* vertices = new VertexBone[10000];

Ezt a hozzászólást Pretender módosította (2013.01.04 10:38 GMT+1 óra, ---)

   
borsi - Tag | 180 hsz       Online status #189636   2012.12.20 13:07 GMT+1 óra  
A kategóriákhoz egy ötlet:
Kód:
class A
{
public:
    class AB
    {
    private:
        A & a;

    public:
        AB( A & a )  : a( a ) {}
        void foo(){}
    };

    class AC
    {
    private:
        A & a;

    public:
        AC( A & a )  : a( a ) {}
        void bar(){}
    };
private:
    AB * b;
    AC * c;

    /* csak ha kellenek a private memberek is
    friend class AB;
    friend class AC;
    */
public:
    A() : b( new AB(*this) ), c( new AC(*this) ) {}
    A( const A & a ) : b( new AB(*this) ), c( new AC(*this) ) {}
    A & operator=(const A & a ){}
    ~A(){ delete b; delete c; }

    AB & B() {  return *b;  }
    AC & C() {  return *c;  }
};

//...

A a;

a.B().foo();
a.C().bar();

   
Pretender - Törzstag | 2498 hsz       Online status #189631   2012.12.20 07:46 GMT+1 óra  
Ez azért csúnya szerintem, mert az alapvető hozzáállás az az, hogy egy osztály adattagjait csak önmaga módosítsa, vagy kívülről függvények alapján. Arra akarok utalni, hogy ez a lekéred a pointert, és azon keresztül átírod az értéket, az nem az igazi. Most még talán követhető, de később meg csak pislognál, hogy "fú, ez itt miért lett annyi amennyi?".
Ráadásul így nem csak a B éri el, hanem bárki, azaz ha mondok egy olyat, hogy:
Kód:
A* a = new A();
a->changeA(20);

B* b = new B(a);

int* c = a->GetARef();
*c = 0;

az úgy gondolom nem az igazi Ha nagyon így "kézzel át akarod írni" a B-ben, akkor legyen A-nak friendje B, és ekkor látja a private memberjeit is. De ez így tervezési probléma lenne, A adattagjait A módosítsa, vagy biztosítson kifelé biztonságos függvényeket.

   
LBandy - Tag | 271 hsz       Online status #189629   2012.12.19 23:26 GMT+1 óra  
Az alábbi kérdést idő közben tovább boncolgattam, és lett egy ilyen megoldásom:

Kód:
class A
{
private:
int a;

public:
void ChangeA(int n)
{
a = n;
}

int GetA()
{
return a;
}

int* GetARef()
{
return &a;
}
};

class B
{
private:
int* pa;

public:
B(A* a)
{
pa = a->GetARef();
*pa = 15;
}
};

int main()
{
A a;
a.ChangeA(8);
std::cout << a.GetA() << "\n"; // 8
B b(&a);
std::cout << a.GetA() << "\n"; // 15

system("pause");
return 0;
}

Látszólag ilyen módszerrel egy teljesen külön osztályból hozzáférek az átadott osztály minden változójához (persze ha egyenként lekérem a pointereket), tudom őket írni és olvasni. Kérdésem, hogy ez mennyire elfogadott megoldás?
   
LBandy - Tag | 271 hsz       Online status #189471   2012.12.13 14:57 GMT+1 óra  
Két pakli van, egy player és egy cpu, tehát ezeken belül mindig az adott játékosra vonatkozóan kapom az adatokat. Próbafeladat, igen. Dobok egy privátot a részletekkel.
   
Asylum - Törzstag | 5511 hsz       Online status #189470   2012.12.13 14:53 GMT+1 óra  
Logikailag minden a paklihoz tartozik (hacsaknem pl. a legerosebb lap egy adott jatekosra vonatkozik, mert akkor a jatekoshoz tartozik).

Ez valami probafeladat? Konkretan mi a megvalositasod es mi a problemajuk?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
LBandy - Tag | 271 hsz       Online status #189468   2012.12.13 13:38 GMT+1 óra  
Akkor a problémám valószínűleg dizájn-beli. Mondom a konkrétumot, úgy könnyebb.
Kártyás játékról lévén szó létrehozok egy Pakli objektumot, amiben egy vektor/tömb/bármi tartalmaz Kártya objektumokat. Ezzel más dolgom nincs. A következő szétbontásra gondoltam:
Kód:
Pakli-kezelés funkciók:
- Hozzáad egy lapot
- Töröl egy lapot
- Generál egy új paklit
- Üríti a paklit
- stb..

Kártyalap-kérés funckiók:
- Visszaadja a legerősebb lapot
- Visszaadja a leggyengébb lapot
- Visszaad egy véletlenszerűen kiválasztott lapot
- stb..

Info funckiók:
- Visszaadja a pakli méretét
- Visszaadja a lap helyét a megadott indexen
- Visszaadja a laphoz tartozó referenciát a megadott indexen
- stb...

Ugye az világos, hogy minden egyes funkció a Pakliban egyszer létrehozott vektort/tömböt/bármit macerálja, vagy abból kér le, vagy abba ír bele, tehát külön, Pakli-tól független objektumot létrehozni rájuk szerintem értelmetlen. Ezt milyen struktúrában lenne érdemes implementálni?
   
versio - Tag | 673 hsz       Online status #189467   2012.12.13 13:28 GMT+1 óra  
azert nem sikerul mert a funkciokat akarod szetvalogatni, holott az adatokat kell, a fuggvenyek majd kovetik a valtozokat a megfelelo osztalyban
   
LBandy - Tag | 271 hsz       Online status #189466   2012.12.13 13:22 GMT+1 óra  
Ez is egy érdekes megközelítése a dolognak, template-ekkel még nem foglalkoztam, de kicsit utánuk olvasok, köszönöm!
Igazából az egész ötlet onnan jött, hogy dolgozom egy feladaton, amivel kapcsolatban már kaptam visszajelzéseket. Az egyik az volt, hogy célszerű lenne a komplex kompozit objektumokat szétbontani kisebb diszkrét objektumokra. Ezen felbuzdulva kezdtem volna a nagy objektumomat több kicsiből összerakni, ám mindnek el kellene érnie a nagy változóit.
Tehát akkor én nem értelmezem jól a leírtakat, és más oldalról kellene megközelíteni a problémát, mint ahogy most nekiálltam?
   
versio - Tag | 673 hsz       Online status #189465   2012.12.13 12:59 GMT+1 óra  
ez nem fog tetszeni , de ilyet is lehet

Kód:
class Alma
{
template <GONDOZ>
int Kapal()
{
}

template <VIZSGAL>
bool isGrowUp()
{
}

};

int main()
{
Alma alma;

alma.isGrowUp<VIZSGAL>();
alma.Kapal<GONDOZ> ();


}
   
Matzi - Szerkesztő | 2529 hsz       Online status #189464   2012.12.13 12:57 GMT+1 óra  
Lényegében igen. Jó esetben az intellisense úgyis besegít, ha elkezded gépelni amit szeretnél.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
LBandy - Tag | 271 hsz       Online status #189462   2012.12.13 12:47 GMT+1 óra  
Asylum amit írtál végeredményben nagyon jó, csak az implementálása egy kicsit körülményes, de még mindig ez van a legközelebb ahhoz, amit kivitelzni szerettem volna, szóval köszönet a megoldásért!
Viszont ha jól értem, arra próbáltok finoman rávezetni, hogy ne gyökérkedjek csoportosítással, hanem csak a funkció nevekkel variáljak úgy, hogy kifejezze, amit eddig külön osztállyal szerettem volna.
   
Asylum - Törzstag | 5511 hsz       Online status #189461   2012.12.13 12:36 GMT+1 óra  
Szerintem is baromsag, de pl. directx 10-ben a prefix csoportosit pl. OMSetRenderTarget v mi a pocs.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2529 hsz       Online status #189460   2012.12.13 12:35 GMT+1 óra  
Tudtommal ipari méretű projektekben sem nagyon szoktak ezzel nagyon törődni. Érdemes olyan nevet adni a függvényeknek, ami elég jól utal a funkciójára, de ennél több szerintem inkább csak körülményessé teszi a fejlesztést, nem kényelmesebbé.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
versio - Tag | 673 hsz       Online status #189459   2012.12.13 12:29 GMT+1 óra  
gondolom amikor egy osztalynak rengeteg funkcioja van , akkor nehez megtalalni pont azt ami kell, csoportositva gyorsabb, es a kod is egyertelmubb
   
Matzi - Szerkesztő | 2529 hsz       Online status #189458   2012.12.13 12:26 GMT+1 óra  
Egyáltalán mi értelme van ennek? Mi lenne vele a cél?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
versio - Tag | 673 hsz       Online status #189457   2012.12.13 12:17 GMT+1 óra  
nem hiszem hogy ez tetszene neki nekem se tetszene, c#-ben a namespae hatokore megadhato ,azzal trivialis a megoldas c++-al meg csak ilyen nyakatekert modszerrel megy csak
   
Asylum - Törzstag | 5511 hsz       Online status #189456   2012.12.13 12:03 GMT+1 óra  
Kód:
#include <iostream>

class Alma
{
public:
    class Gondoz;

    Alma();

    ~Alma() {
        delete gondozo;
    }

    inline Gondoz& Gondozo() {
        return *gondozo;
    }

    inline int Szin() const {
        return szin;
    }

private:
    int szin;
    int meret;
    Gondoz* gondozo;
};

class Alma::Gondoz
{
private:
    Alma* alma;

public:
    Gondoz(Alma* parent) {
        alma = parent;
    }

    void Tisztit() {
        alma->szin = 2;
    }
};

Alma::Alma()
{
    szin = 1;
    meret = 10;

    gondozo = new Gondoz(this);
}

int main()
{
    Alma alma;
   
    std::cout << alma.Szin() << "\n";
    alma.Gondozo().Tisztit();
    std::cout << alma.Szin() << "\n";

    system("pause");
    return 0;
}


Csak unatkozom
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #189447   2012.12.13 06:57 GMT+1 óra  
Idézet
Seeting :
De Pretender, nem tudom, hogy most C++-on gondolkozol-e, mert ez nem hiszem, hogy lehetséges C#-ban. De C#-ban felesleges ilyen alacsony szintű optimalizálásokat végezni mert ellent mond a nyelv filozófiájának.


c++ topicba írtam, nem?

   
ddbwo - Tag | 1654 hsz       Online status #189444   2012.12.12 23:38 GMT+1 óra  
Idézet
Joga :
ne skatulyázz egybe osztálydeklarációkat, nem jó ötlet


Eeemondom parasztosan.

1. Megcsinálod B osztályt.
2. Megcsinálod A osztályt, ami tartalmazza B b-t.

A többi úgy működik mint bármelyik más adat kezelésénél. Ilyen módon úgy rakhatsz osztályt osztályba, ha már kész van. Ha jól értettem....

Kód:
class B
{
    int cucc;
};

class A
{
    B b;
};

De a kettő együtt kezeléséhez A-ban kell függvényezni.
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
   
LBandy - Tag | 271 hsz       Online status #189442   2012.12.12 23:28 GMT+1 óra  
Értem, köszi! Ez érdekesnek tűnik, utánaolvasok. Viszont ha nem túl népszerű, akkor gondolom nekem sem ezen a nyomon kellene elindulnom. Mi egyébként a bevett szokás az ilyesmire? Egyszerűen minden funkció neve elejére írjam oda hogy milyen logikai csoportba sorolom? Pl GondozOntoz(), GondozTisztit(), stb...
Biztos volt már hasonló elképzelésed neked is, hogyan oldottad meg?

(versio közben látom írtál Te is, ez sem rossz ötlet, köszönöm! Ha más nem, így fogom megoldani.)
   
versio - Tag | 673 hsz       Online status #189441   2012.12.12 23:26 GMT+1 óra  
szerintem nem jo megoldas az osztalyokat egymasba rakni, total atlathatatlan , egy megoldas lehet pl : lesz egy alma osztaly, egy gondoz osztaly, es vizsgal osztaly , es namespacekkel jelezheted hoyg az almara vonatkozik ,es amikor letrehozod a peldanyokat atadod nekik az alma pointeret
   
syam - Törzstag | 1491 hsz       Online status #189440   2012.12.12 23:20 GMT+1 óra  
Kb. ilyesmire való a friend class.
class Alma és ennek friendje a class Gondoz. Külön osztály viszont eléri az Alma összes változóját.
Ritka esetektől eltekintve azonban ezt a tervezést nem ajánlják.
alias aalberik
   
LBandy - Tag | 271 hsz       Online status #189439   2012.12.12 23:11 GMT+1 óra  
Igen, ezt én is észrevettem már, hogy namespacelni nem lehet odabenn, ezért is próbáltam al-osztályokra bontani a dolgot.
Tehát akkor ha jól értem, egy adott osztályon belül nem tudok csoportosítani? Mondok egy példát.
Osztály neve legyen Alma, legyen neki mondjuk 5 változója, amik kintről nem érhetőek el.
Szeretnék az Alma-hoz Gondoz osztályt (itt tudom öntözni, tisztítani, ezek változtatják az Alma változóit). Aztán szeretnék hozzá egy Vizsgál osztályt (ezek mondjuk kifelé adják tovább a változók tartalmát), stb... Mindezt úgy, hogy egyetlen egy Alma példányt hoztam létre korábban a kódban, és utána minden Alma-ra vonatkozó utasítás rá vonatkozik.
Egy ilyen konstrukciót dizájn szinten c++ -ban meg lehet-e oldani, és ha igen, hogyan?
   
syam - Törzstag | 1491 hsz       Online status #189438   2012.12.12 23:00 GMT+1 óra  
Ezek a namespacek lennének, de olyanokat nem tudsz osztályon belül deklarálni.
alias aalberik
   
versio - Tag | 673 hsz       Online status #189437   2012.12.12 22:59 GMT+1 óra  
Kód:
class A
{
class B {};

B b;

};

int main()
{
A* aPtr = new A();
aPtr->b.SetA(1);
return 0;
}
   
LBandy - Tag | 271 hsz       Online status #189435   2012.12.12 22:51 GMT+1 óra  
Köszi az ötleteket! versio amit írtál az még önmagában sajnos nem oldotta meg a problémát, de akkor közelítsük meg máshonnan.
Szeretném a nagy A osztályomat szétbontani alegységekre, és a benne lévő funkciókat logikailag csoportosítani. Hogyan oldhatom ezt meg okosan, szépen, és külön osztályok nélkül? Célszerű lenne, ha tudnám tartani az A::B.Funkcio(), vagy valami hasonló "megjelenést".
   
versio - Tag | 673 hsz       Online status #189434   2012.12.12 22:42 GMT+1 óra  
Kód:
aPtr->B::SetA(1);


helyett

Kód:
A::B::SetA(1


ennel meg azert nem eri el mert private a valtozo:

Kód:
A::aVar.push_back(a););
   
syam - Törzstag | 1491 hsz       Online status #189433   2012.12.12 22:41 GMT+1 óra  
Én zavart érzek az erőben:
amikor egy B példányosul, attól nem jönne létre egy A példány is és szerintem nem is lehet hivatkozni az A adattagjaira a B-ből csak öröklés esetén vagy ha A tagjai staticok, de akkor meg a castolás lesz nehézkes.
alias aalberik
   
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] [143]