[c++] Classes die naar elkaar verwijzen

[JeRa]

Ik ben (voor het eerst) een crossplatform GUI in C++ aan het programmeren voor een audioprogramma, en ik stuitte op het volgende probleem.

Ik heb een hoofdclass waarin al het grafische werk wordt verricht. Deze hoofdclass heeft verwijzingen naar widgets die getekend moeten worden. Deze widgets hebben zelf ook een verwijzing naar de hoofdclass, zodat ze kunnen tekenen.

code:

#include "widget.h"

class Core {
...
private:
    Widget **_widgets;
...
}

code:

#include "core.h"

class Widget {
...
private:
    Core *_core;
...
}

code:

Widget::Widget(Core *core) : _core(core)
{
}

Nou gaat hier natuurlijk iets fout. De Widget-class heeft de Core-class nodig, maar in deze Core-class is ook de Widget-class gedefinieerd. Recursiviteit en wanhoop alom in de compiler. Hoe zou ik dit dan het best kunnen oplossen?

edit: tnx Korakal

De foutmeldingen die ik van gcc trouwens krijg zijn normale parse errors en missende matches voor de constructors.

[ Voor 10% gewijzigd door JeRa op 03-07-2004 15:29 ]

[Korakal]

Professional Networking & Servers > Programming & Webscripting

[Zoijar]

Je moet Widget of Core even forward declaren. Dus voor 'class Core' zet je even 'class Widget;'

[JeRa]

Zoijar schreef op 03 juli 2004 @ 15:37:
Je moet Widget of Core even forward declaren. Dus voor 'class Core' zet je even 'class Widget;'

Bedankt, dat werkt! Naar aanleiding van je antwoord kwam ik ook op deze pagina waar ik weer even mee vooruit kan. Tnx

[ Voor 6% gewijzigd door JeRa op 03-07-2004 15:42 ]

[MSalters]

Het werkt wel, maar het is een design fout. De hoofdclass weet welke widgets getekend moeten worden en wanneer. Als deze dus een tekenopdracht geeft aan een widget kan die meteen ervoor zorgen dat alle tekencontext wordt doorgegeven.

[curry684]

MSalters schreef op 04 juli 2004 @ 10:47:
Het werkt wel, maar het is een design fout. De hoofdclass weet welke widgets getekend moeten worden en wanneer. Als deze dus een tekenopdracht geeft aan een widget kan die meteen ervoor zorgen dat alle tekencontext wordt doorgegeven.

* curry684 mikt even wat in de groep:

C++:

void Widget::Paint(Canvas* p_Canvas);

Tis maar een idee

[Verwijderd]

curry684 schreef op 04 juli 2004 @ 11:55:
[...]

* curry684 mikt even wat in de groep:

C++:

void Widget::Paint(Canvas* p_Canvas);

Tis maar een idee

offtopic:
zoiets heb ik gedaan in een schoolopdracht die we moesten inleveren. welliswaar in delphi pascal, maar da's exact hetzelfde idee.

nou hoorde ik van de week dat dat tegen alle conventies in gaat, en absoluut niet hoort, dat ze het hierop zondermeer afkeuren.

klopt dat?

[curry684]

Verwijderd schreef op 04 juli 2004 @ 11:58:
[...]

offtopic:
zoiets heb ik gedaan in een schoolopdracht die we moesten inleveren. welliswaar in delphi pascal, maar da's exact hetzelfde idee.

nou hoorde ik van de week dat dat tegen alle conventies in gaat, en absoluut niet hoort, dat ze het hierop zondermeer afkeuren.

klopt dat?

Uhm lijkt me redelijk grote onzin, daar dit namelijk OO-technisch een zeer cleane en nette oplossing is. De class Widget introduceert namelijk de functionaliteit om zichzelf te painten, wat correct is als hij het eerste 'renderbare' object in de hierarchie is. Doordat er een 'abstract' type Canvas wordt gebruikt (en niet expliciet een Window, een Printer oid.) kan hij zichzelf painten naar ieder object dat de interface Canvas implementeert. En daar je deze functie Paint in principe virtual zult maken kan iedere afgeleide class in de boom zijn eigen Paint functionaliteit toevoegen.

Veel zuiverder kan het niet imho, en daarom werken VCL, MFC en .NET ook op deze manier