Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

[C++] Zeiger auf Objekt in Vector verliert seine Daten, sobald ein neues Objekt dazukommt

Werbeanzeige

anti-freak

Alter Hase

Beiträge: 635

  • Private Nachricht senden

11

23.09.2015, 09:45

Das macht semantisch für mich aber irgendwie keinen Sinn. Ich verstehe, was du sagen willst, allerdings leuchtet mir nicht ein, warum ein Node seinen nächsten Nachbarn "besitzen" soll (unique_ptr). Erleichtert vll ein bisschen das Management, ist logisch gesehen für mich allerdings Unsinn. Würde dann doch eher die Variante bevorzugen, dass das Parent alle Children besitzt.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

12

23.09.2015, 09:55

Er besitzt Unterknoten. Links/Rechts quasi und hat einen Parent. Passt schon. Ist exakt ein Binärbaum.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

anti-freak

Alter Hase

Beiträge: 635

  • Private Nachricht senden

13

23.09.2015, 10:05

Und welchen Vorteil bietet das im Gegensatz zur "Parent besitz alle Unterknoten"-Methode?

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

14

23.09.2015, 10:42

Ich wollte es nur auch erwähnen, da ich diese Variante, einen Baum zu bauen, erwähnenswert finde...

Vorteile: Nodes klein und kompakt, exakt eine dynamische Speicherallokation konstanter Größe pro Node, weniger Indirektionen.
Nachteil: Kein Random Access auf konkretes Child.
m4studios

Shorkan

Frischling

  • »Shorkan« ist der Autor dieses Themas

Beiträge: 61

  • Private Nachricht senden

15

23.09.2015, 12:53

Eine Frage wirft sich mir jetzt noch auf und zwar da ich unique_ptr bis jetzt noch garnicht einschätzen kann. Wie ist da der Unterschied zwischen einen unique_ptr und wenn ich einfach den Index speichere. Ist das im Grunde egal oder sollte man etwas bevorzugen?

Die andere Art den Baum zu konstruieren merke ich mir mal, aber da ich noch nicht weiß wie oft und auf welche Art ich Zugriff auf die Daten innerhalb brauchen werde, lasse ich es erstmal so wie ich es habe. Kann das einfach noch nicht abschätzen, da es von vielem abhängt was noch nicht genau definiert ist. Aber irgendwo muss man ja mal anfangen, sonst wird die KI niemals fertig.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

16

23.09.2015, 13:26

Mal kurz eine andere Frage. Bist du dir sicher dass du wirklich eine Baumstruktur haben möchtest und keinen Graphen? Je nachdem was du vor hast kann es eben das eine oder das andere sein.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Checkmateing

Community-Fossil

Beiträge: 2 218

  • Private Nachricht senden

17

23.09.2015, 13:35

Ein unique_ptr ist ein spezieller Datentyp, der dir Arbeit abnimmt, die du bestimmt mal vergisst.
Aber fern ab davon ist es vom OOP-Konzept auch viel besser diesen zu benutzen, wenn man ihn denn benötigt.
So einen unique_ptr kannst du als Wrapper um T* sehen, also irgendeinem Zeiger.
unique_ptr kümmert sich dann darum, dass der Speicher wieder freigegeben wird, den du mithilfe
von new allokiert hast, oder dass es eben genau eine Instanz gibt, die darauf zeigt, d.h. du kannst
nicht mehrere unique_ptrs erzeugen, die alle auf die selbe Stelle zeigen. Für solche Fälle ist
shared_ptr vorgesehen. Interessant für eine Baumstruktur dahin ist dann sicherlich auch
shared_from_this. ;)

MfG
Check
Das gibt Übersicht! Stay gold.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

18

23.09.2015, 20:26

Zitat von »Checkmateing«

dass es eben genau eine Instanz gibt, die darauf zeigt, d.h. du kannst nicht mehrere unique_ptrs erzeugen, die alle auf die selbe Stelle zeigen. Für solche Fälle ist shared_ptr vorgesehen
Das stimmt so aber nicht und kann ganz schnell zu falscher und voreiliger Verwendung von shared_ptr führen. Das Thema hatten wir ja gerade erst wieder: [C++] Ärger mit unique_ptr
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Checkmateing

Community-Fossil

Beiträge: 2 218

  • Private Nachricht senden

19

23.09.2015, 23:38

Zitat von »dot«

Wenn es einen Besitzer gibt, verwendet man unique_ptr und rohe Zeiger bzw. Referenzen für "das Kennen" und nicht shared_ptr und weak_ptr.

Ich rede mit 'Instanz' selbstverständlich von unique_ptrs, wenn du das meinst... Ich habs bisher jedenfalls noch nie gesehen, dass zwei unique_ptr auf den gleichen Speicherpunkt schauen.

MfG
Check
Das gibt Übersicht! Stay gold.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

20

24.09.2015, 06:45

Dann hast Du Dich missverständlich ausgedrückt. Danke für die Klarstellung. Dennoch bleibt der letzte Satz und den würde ich auch hier gern nochmal klarstellen: Will man von mehreren Objekten aus auf dasselbe Objekt zeigen, nimmt man eben nicht einfach nur shared_ptr, sondern einen unique_ptr für den Owner und Raw-Pointer für alle anderen Objekten, die es nur verwenden wollen/müssen.

Zwei unique_ptrs kann man technisch auf dieselbe Stellen schauen lassen, aber das wäre ein Bug, der einem irgendwann Speicherverletzungen um die Ohren knallt.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Werbeanzeige

Ähnliche Themen