View Full Version : another Vector
da sollte man vielleicht besser überlegen, ob man die Implementierungen zusammen führt, ich mail dich mal private an.
D*B
Liebend Gerne.
Gruss
Mihael
Da ich ja nun beliebige Strukturen über diesen Service verwalten können soll, darf ich ja wohl auch eigene Pointer in dieser Struktur unterbringen.
Wenn du also CPYBWP hier nicht verwendest, sind meine eigenen Pointer nun mal zerstört.
Noch zum Hintergrund:
Vor Rel. 3.1 konnten Pointer über die Speicheradresse modifiziert werden, insbesonders die Authority-Flags.
Seit dem führt aber ein Schreibzugriff ohne Pointerbefehle unweigerlich zur Zerstörung des Pointers.
Deshalb ist der CPYBWP zwingend erforderlich, da dieser ja die Vorkommen von Pointern prüft und diese daher erhält.
Auch für deine interne Speicherverwaltung könnt der CPYBWP ja hilfreich werden.
Habe ich das Problem mit dem Kopieren nur, wenn ich die Pointer in einer Datenstruktur habe und diese dann kopieren will?
Gruss
Mihael
Stimmt genau (siehe obige Erklärung).
meine internen Pointer habe ich nicht in einer zu kopierenden Struktur.
Falls ich das speichern von Pointern in Datenstrukturen in einem Vector oder einer Hashtable zulassen will, worüber ich erst mal nachdenke, dann muss man schon sehen, ob der Ersatz von memcpy durch CPYBWP hier alles kann, was man dafür bräuchte (ich bin mir nicht so sicher, was da beim realloc alles so passiert, oder eben nicht).
D*B
Da ich ja nun beliebige Strukturen über diesen Service verwalten können soll, darf ich ja wohl auch eigene Pointer in dieser Struktur unterbringen.
Wenn du also CPYBWP hier nicht verwendest, sind meine eigenen Pointer nun mal zerstört.
Noch zum Hintergrund:
Vor Rel. 3.1 konnten Pointer über die Speicheradresse modifiziert werden, insbesonders die Authority-Flags.
Seit dem führt aber ein Schreibzugriff ohne Pointerbefehle unweigerlich zur Zerstörung des Pointers.
Deshalb ist der CPYBWP zwingend erforderlich, da dieser ja die Vorkommen von Pointern prüft und diese daher erhält.
Auch für deine interne Speicherverwaltung könnt der CPYBWP ja hilfreich werden.
Das kommt drauf an, welche Funktionen du benutzt.
Ich kann nur spekulieren, dass die RPG-BuildIn's die C-Funktionen nutzen.
Ansonsten helfen auch hier halt die korrespondierenden C-Funktionen malloc(), realloc(), calloc(), free().
In C/C++ ist es nämlich normal, dass Pointer in Strukturen gespeichert werden und diese ja erhalten bleiben müssen, sonst würde C++ gar nicht funktionieren.
Wenn du die C-Funktion memcpy() verwendest, müssten Pointer eigentlich auch erhalten bleiben.
beim Vector nehme ich die CEE Functions, weil ich mit User Heaps arbeite, ansonsten werden die Daten mit memcpy angepackt, der Schwachpunkt liegt schon vorher, da die Datenstrukturen über alfa Schnittstellen der Prototypen rüber müssen, am liebsten auch noch varying - und das Problem ist hier, dass da null dokumentiert ist, also Wohlverhalten des Compilers Bug oder Feature sein kann und von Release zu Release diesen Charakter und/oder sein Verhalten wechseln kann.
D*B
Das kommt drauf an, welche Funktionen du benutzt.
Ich kann nur spekulieren, dass die RPG-BuildIn's die C-Funktionen nutzen.
Ansonsten helfen auch hier halt die korrespondierenden C-Funktionen malloc(), realloc(), calloc(), free().
In C/C++ ist es nämlich normal, dass Pointer in Strukturen gespeichert werden und diese ja erhalten bleiben müssen, sonst würde C++ gar nicht funktionieren.
Wenn du die C-Funktion memcpy() verwendest, müssten Pointer eigentlich auch erhalten bleiben.
Das kommt drauf an, welche Funktionen du benutzt.
Ich kann nur spekulieren, dass die RPG-BuildIn's die C-Funktionen nutzen.
Ansonsten helfen auch hier halt die korrespondierenden C-Funktionen malloc(), realloc(), calloc(), free().
In C/C++ ist es nämlich normal, dass Pointer in Strukturen gespeichert werden und diese ja erhalten bleiben müssen, sonst würde C++ gar nicht funktionieren.
Wenn du die C-Funktion memcpy() verwendest, müssten Pointer eigentlich auch erhalten bleiben.
Die RPG Built-In Funktionen greifen auf die CEE Funktionen zu was Speichermanagement angeht. Wie das dann weiter unten aussieht ... k. A.