another Vector

[mihael]

@int vs. pointer: Ich denke Pointer sind genauso "böse" wie Userspaces. Wenn man sie kennengelernt hat, können sie doch recht sympatisch sein =) (Der Mensch hat meist Angst vor dem was er nicht kennt). Ich würde an sich auch einen int Handle bevorzugen, jedoch habe ich noch keine elegante/mir zusagende Möglichkeit gefunden, dieses in meiner Vector Implementierung umzusetzen.

Das Problem mit aligned verstehe ich nicht ganz, denn AFAIK braucht man das Schlüsselwort nur in Verbindung mit Pointern und Datenstrukturen. Und selbst in dieser Kombination braucht man meist nix zu beachten. Ok. Es könnte in manchen Situationen "Randprobleme" geben. Auszuschliessen ist das leider nicht ganz. (Wäre allerdings meiner Meinung nicht der normale Gebrauch).

@Prototypen: Bei diesem Thema versuche ich keine gute oder perfekte Lösung zu finden, sondern einfach nur einen Schritt nach vorn zu machen. RPG bietet da ja nicht wirklich viel. Unique Prefixe scheinen mir da sinnvoll zu sein. Ich kann allerdings nicht ganz ausschliessen, dass nicht doch jemand seinen Prototypen genauso bezeichnet samt Prefix wie eine meiner eigenen Prototypen. Allerdings könnte so etwas auch in Java passieren (Gleicher Packagename und gleicher Klassenname). In Java ist es nur unwahrscheinlicher als in RPG, jedoch nicht auszuschliessen.

Bei Ideen für weitere Funktionalität stehen ich und meine Implementierung gerne zur Verfügung =)

@Doku: Mal sehen ob ich die generieren kann.

Gruss

Mihael

[BenderD]

Hallo,

@pointer: es geht nicht um gut oder böse, eine Komponente darf nicht von außen korrumpierbar sei und da sind Pointer, die keinerlei Schutz haben, in meiner Philosophie nogo. Was die Eleganz angeht, gefällt mir deine (und auch die von Thomas) eigentlich besser, aber ich würde bei deiner Pointer Implementierung 2 Dinge ändern: 1) der Prototyp darf nicht CONST (und auch nicht value sein), da das ermöglicht, dass eine Änderung der Adresse beim realloc nicht zurück kommt (je nach Implementierung, des verwendenden Programmes - BTW: geht immer schief, wenn jemand sich den Pointer (=handle) in einer entkoppelten Variable merkt!!!. 2) deine Prüfung auf Validität des Pointers wird schärfer, wenn du die auf eine Variable machst, die über den Pointer selber referenziert wird und nicht über eine "static" globale, dann merkt diese Prüfung nicht nur, wenn das handle aus einem anderen Object kommt, sondern auch andere Arten von Korrption (das ist der Grund, warum ich mein handle nicht value mache, damit es wenigstens keine Literale frisst).

@align: ich habe bei nested DS (insbesondere bei V5R1, wo das likeds noch Einschränkungen hatte) schon Probleme gehabt, dass Pointer beim rausholen kaputt waren, wenn man sie in eine DS reingepackt hat.

@Prototypen: ich finde es einfach lästig, wenn man Namen qualifizieren muss, obwohl man es im Kontext nicht bräuchte. Ich bin schon froh, dass sich da die (meine) Konvention mit dem Modul als Prefix im ExportNamen durchgesetzt hat; eigentlich bin ich ja Anhänger von Late Binding (zur Laufzeit), aber das habe ich noch nicht zu der Reife gebracht, dass ich es auf meine Open Source Seite durchschlagen lasse (frühere Versuche habe ich wieder zurück gebaut).

@Ideengeber: das warst du (und Thomas) im Grunde schon, wobei ich da andere Prioritäten habe, für mich ist das mehr Spielwiese, wo ich versuche konzeptionelle Ideen zu transportiere, da ist der Spielanteil höher.

@Doku: da bin ich sperrig, je klarer die Implementierung, desto kürzer die Doku - und ich arbeite an Ziel 1.

danke für das Feedback

Dieter

@int vs. pointer: Ich denke Pointer sind genauso "böse" wie Userspaces. Wenn man sie kennengelernt hat, können sie doch recht sympatisch sein =) (Der Mensch hat meist Angst vor dem was er nicht kennt). Ich würde an sich auch einen int Handle bevorzugen, jedoch habe ich noch keine elegante/mir zusagende Möglichkeit gefunden, dieses in meiner Vector Implementierung umzusetzen.

Das Problem mit aligned verstehe ich nicht ganz, denn AFAIK braucht man das Schlüsselwort nur in Verbindung mit Pointern und Datenstrukturen. Und selbst in dieser Kombination braucht man meist nix zu beachten. Ok. Es könnte in manchen Situationen "Randprobleme" geben. Auszuschliessen ist das leider nicht ganz. (Wäre allerdings meiner Meinung nicht der normale Gebrauch).

@Prototypen: Bei diesem Thema versuche ich keine gute oder perfekte Lösung zu finden, sondern einfach nur einen Schritt nach vorn zu machen. RPG bietet da ja nicht wirklich viel. Unique Prefixe scheinen mir da sinnvoll zu sein. Ich kann allerdings nicht ganz ausschliessen, dass nicht doch jemand seinen Prototypen genauso bezeichnet samt Prefix wie eine meiner eigenen Prototypen. Allerdings könnte so etwas auch in Java passieren (Gleicher Packagename und gleicher Klassenname). In Java ist es nur unwahrscheinlicher als in RPG, jedoch nicht auszuschliessen.

Bei Ideen für weitere Funktionalität stehen ich und meine Implementierung gerne zur Verfügung =)

@Doku: Mal sehen ob ich die generieren kann.

Gruss

Mihael

[mihael]

Danke für die Tipps mit dem Pointer. Ich werde mal sehen wann ich dafür Zeit habe mir das genauer anzuschauen in Bezug auf meine Vector Implementierung.

Doku: Vielleicht habe ich da etwas Zeit auszuhelfen. Mal sehen.

Gruss

Mihael

[BenderD]

da sollte man vielleicht besser überlegen, ob man die Implementierungen zusammen führt, ich mail dich mal private an.

D*B

Danke für die Tipps mit dem Pointer. Ich werde mal sehen wann ich dafür Zeit habe mir das genauer anzuschauen in Bezug auf meine Vector Implementierung.

Doku: Vielleicht habe ich da etwas Zeit auszuhelfen. Mal sehen.

Gruss

Mihael

[Fuerchau]

Das Problem der Pointerzerstörung liegt meist am verwendeten Kopier-Befehl.
Der MOVE oder EVAL einer DS mit eingebettetem Pointer zerstört diesen, da hier intern der MI-Befehl CPYBLA/CPYBRA verwendet wird.
Wird eine Pointervariable direkt kopiert, weiß der Compiler das und verwendet den korrekten MI-Befehl.
Wenn Pointer ohne Zerstörung in einer DS kopiert werden müssen, hilft hier der Einbau einer C-Funktion:
Copy Bytes with Pointers (CPYBWP)

[BenderD]

... danke für die Info, ich habe den Hintergrund nicht bis auf die MI Ebene recherchiert, innerhalb der Implementierung einer Komponente kann man das schon im Griff halten, aber kann/soll man das jemandem zumuten, der eine Komponente wie einen Vector, eine LinkedList oder eine Hashtable verwendet, die ja gerade die dynamische Speicherverwaltung mit ihrere Pointer Verwendung kapseln soll?

D*B

Das Problem der Pointerzerstörung liegt meist am verwendeten Kopier-Befehl.
Der MOVE oder EVAL einer DS mit eingebettetem Pointer zerstört diesen, da hier intern der MI-Befehl CPYBLA/CPYBRA verwendet wird.
Wird eine Pointervariable direkt kopiert, weiß der Compiler das und verwendet den korrekten MI-Befehl.
Wenn Pointer ohne Zerstörung in einer DS kopiert werden müssen, hilft hier der Einbau einer C-Funktion:
Copy Bytes with Pointers (CPYBWP)

[mihael]

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

[Fuerchau]

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.

[mihael]

Habe ich das Problem mit dem Kopieren nur, wenn ich die Pointer in einer Datenstruktur habe und diese dann kopieren will?

Gruss

Mihael

[Fuerchau]

Stimmt genau (siehe obige Erklärung).

[BenderD]

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.

[Fuerchau]

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.