[c++] pointer naar het object zelf initialiseren

[st0p]

ik heb in c++ een klasse Boom. daarin zit een methode die VindBlad heet en een pointer teruggeeft naar een object Blaad wat aan de Boom zit. De leaves zitten mooi in vectoren, VindBlad geeft een pointer terug zodat ik door middel van pointer_naar_blad->VoegBladToe en
pointer_naar_blad->VerwijderBlad eenvoudig de boom kan manipuleren. Dit werkt allemaal goed, er is alleen een probleem:
als ik aan de boom zelf een blad wil hangen, zal in de methode VoegBladToe van Boom (die net even anders is dan die van Blad) gecheckt moeten worden of de pointer die VindBlad geeft naar Boom verwijst. Op zich is het heel eenvoudig om via een aparte methode de pointer naar Boom door te geven zodat ik in de boom die pointer kan initialiseren. Ook dit werkt prima, alleen is het lelijk en moet je dus na het creeren van je boom die functie aanroepen, wat ik natuurlijk ergens in mijn code ga vergeten. Dus eigenlijk wil ik in de constructor die pointer naar de boom zelf al initialiseren. Nou is alleen het probleem dat ik geen idee heb hoe ik dit klaar moet spelen. Kan iemand mij die juiste richting wijzen?

[The End]

Als je de pointer van een object wil gebruiken binnen een functie van dat object, dan gebruik je het woord 'this'. this geeft de pointer naar de instantie van het object.

[Radiant]

Daar heb je toch "this" voor? Of begrijp ik je verkeerd.. this is in elke member functie een pointer naar je object.

[MSalters]

Ik vermoed dat je functie VindBlad ten onrechte een pointer teruggeeft. Het llijkt me meer een functie die een reference moet teruggeven. De extra semantiek van een pointer (0, delete) lijkt me namelijk volledig overbodig.

Verder snap ik niet waarom je bladeren aan bladeren toevoegt. Bladeren zitten aan bomen. Bladeren voeg je dus ook toe aan bomen, en verwijder je van bomen. In C++ termen: de constructor van Boom::Blad is private, en alleen Boom::VoegBladToe roept die aan. Uiteraard kun je dan vanuit Boom::VoegBladToe de Boom* this meegeven, zodat elk blad weet aan welke boom het zit - indien dat nodig blijkt. Omdat de ctor verder nergens wordt aangeroepen, kun je dus ook niet vergeten om de associatie te maken.

[st0p]

okay, het probleem is opgelost, inderdaad met het gebruik van this (is trouwens al wel weer even geleden dat het opgelost is, ondertussen is het project waar ik mee bezig ben al weer wat verder). ik had alleen nog 2 prangende vragen overgehouden aan het antwoord van MSalters:

1) wat bedoel je met ctor? is dit een term waarmee vectoren en aanverwante containerobjecten bedoeld worden?

2) wat bedoel je met "De extra semantiek van een pointer (0, delete)"? bedoel je daarmee dat je met een pointer dus ook NULL als waarde kan hebben en dat je new en delete ermee kan gebruiken?

ik weet het, het heeft weinig met het oorspronkelijke probleem te maken, maar ik ben wel nieuwschierig...

(en mijn woordkeus was misschien niet helemaal goed: ik had in de TS beter over boom en tak kunnen spreken, een tak moet je aan een tak kunnen hangen maar ook aan de boom... hoop dat dat de zaak verduidelijkt)

[edit]
hinderlijke taalfout...

[ Voor 3% gewijzigd door st0p op 30-05-2005 15:16 ]

[.oisyn]

st0p schreef op maandag 30 mei 2005 @ 15:16:
1) wat bedoel je met ctor? is dit een term waarmee vectoren en aanverwante containerobjecten bedoeld worden?

constructor, de "functie" van een klasse met gelijke naam die wordt aangeroepen op het moment dat het object aangemaakt of geconstrueerd (hence "constructor") wordt. Tegenhanger van de destructor of dtor, die gedefinieerd wordt met een ~ gevolgd door de klassenaam.

2) wat bedoel je met "De extra semantiek van een pointer (0, delete)"? bedoel je daarmee dat je met een pointer dus ook NULL als waarde kan hebben en dat je new en delete ermee kan gebruiken?

ja, behalve dat new gedeelte dan, dat is geen operatie op een pointer zoals delete dat is.

[ Voor 7% gewijzigd door .oisyn op 30-05-2005 15:24 ]

[st0p]

ik weet (godzijdank) wel wat constructors en destructors zijn (gisteren net voor het eerst een eigen copyconstructor geschreven ) ik was de afko ctor alleen hier al vaker tegen gekomen en ik wist niet waar het voor stond...

en is het dan een enorme blunder als ik in plaats van een reference een pointer heb gebruikt? gebruik namelijk verder in mijn code ook wel pointers die nooit NULL (zouden mogen) zijn en ook niet gebruikt worden voor delete...

[.oisyn]

Ligt eraan, met references kom je niet weg als het object waarnaar gereferenced wordt pas bekend is nadat de reference zelf geconstruct moet gaan worden. Je kunt een reference namelijk niet ergens anders naartoe laten wijzen na construction. Aan de andere kant zijn ruwe pointers vaak zeldzaam, meestal worden wrapper objects gebruikt die ook aan reference counting en dat soort dingen doen, om memory leaks te voorkomen en het leven van de programmeur wat makkelijker te maken

[st0p]

hmmm dat van die wrapper is wel een interessant concept, is wel iets om in je achterhoofd te houden. aan de andere kant is het in deze situatie niet nodig om bij de pointer ook de references te counten en te zorgen dat alles netjes opgeruimd word, aangezien de boom en de bladeren zelf al alle functionaliteit hiervoor in huis hebben...

anyway, het is me nu allemaal duidelijk, kweetniet of dat hier standaard is maar van mij mag het topic op slot...

[MSalters]

't Is geen erge blunder nee. Het levert wat verwarring op, marginaal minder efficiente code, en wat meer bugs elders.

Overigens is het bezwaar van .oisyn enigzins theoretisch: als je nog geen object hebt, dan maak je de reference nog niet. Je schuift de definitie van de reference gewoon naar beneden in je code tot het punt waar je het object wel hebt. Ja, dat betekent soms dat je een ?: moet gebruiken.

[.oisyn]

Ook leuk als die reference een classmember is, bijvoorbeeld een Node in een boom die naar andere Nodes wijst

.edit: slecht voorbeeld, hier wil je sowieso pointers omdat ze null kunnen zijn. Maar you get the idea.

[ Voor 35% gewijzigd door .oisyn op 30-05-2005 17:15 ]