View Full Version : another Vector
Ich habe wieder mal ein wenig auf meiner Open Source Seite gebastelt und einen Vector da reingestellt, das ist so ein dynamisches Array, in das man mit add Datenstrukturen reinstellen kann, die man mit get wieder rausholt. Das Serviceprogramm kapselt die gesamte dynamische Speicherverwaltung und bietet noch ein wenig mehr an.
Dieter Bender
Hallo,
schön eine weitere Implementierung von dynamischen Arrays zu sehen. Die Grundfunktionalität ist vorhanden. Jetzt fehlen noch die paar Funktionen, die es richtig angenehm machen damit zu arbeiten und das ganze programmiererfreundlich gestaltet.
Eine entsprechende API Dokumentation (a la Javadocs) wäre auch nicht schlecht. Eine Möglichkeit ist ILEDocs (siehe http://www.rpgnextgen.com?content=iledocs ).
Was mich noch interessiert: Aus welchem Grund hast du für den Handle zum Vector ein Integer gewählt und nicht einen Pointer?
Gruss
Mihael
Hallo,
da die Prototypen per Copybook in die Programme eingebunden werden, finde ich es immer wieder merkwürdig, wenn die exportierten Prozedurnamen einen Präfix bekommen, die Prozedurnamen der Prototypen aber keinen Präfix haben. Auf der Maschine (i5), auf der ich arbeite, bekomme ich eine Fehlermeldung (RNF0516), wenn ich zwei Prototypen habe, die den selben Namen haben (auch mit unterschiedlichem exportieren Prozedurnamen).
Sollte man nun ein Serviceprogramm für eine Hashtable haben und ein Serviceprogramm für ein dynamisches Array (Vector oder Linked List, ist ja auch egal) und beide haben die Prozedur "isEmpty" ohne Präfix, bekommt man Probleme, wenn man beides in einem Programm verwenden will.
Oder habe ich da etwas übersehen?
Gruss
Mihael
Hallo Mihael,
@int versus pointer:
- information hiding, sprich um die Korrumpierung der Inhalte durch einen (unbekannten) Verwender zu verhindern
- ich will den Verwender von der Verwendung von Pointern und deren Randproblemen entlasten (Stichwort: aligned)
- ich will die Randprobleme beim reallocate entgehen
- ich habe mich da ein wenig an den APIs, die mit handle arbeiten orientiert
@Prefixe:
- die exportierten Namen werden mit prefix versehen, damit alle Exporte eindeutig sind, dass letzteres der Fall sein muss, da sind wir uns vermutlich einig
- der Verzicht auf prefixe bei den intern verwendeten Namen (die Kollission gibt es wohl bei allen Releasen, deshalb - und aus weiteren Gründen - verwende ich auch kein alles umfassendes Binding directory) orientiert sich ein wenig am Schlüsselwort import und dessen Wirkung im Java
- das von dir benannte Problem könnte man (und habe ich zuweilen) mit einem aufgebohrten Prototyp toppen, wo man über die Compiletime Variable QUALIFIED kurze oder lange Namen wahlweise verwenden kann.
was mich davon abhält das in den Prototypen auf meiner Seite so zu machen, ist, dass dasselbe Problem ja auch auftritt, wenn ich 2 Vectoren (oder andere mehrfach aktivierbare Komponenten) in einem Programm verwenden will/muss, dann platzt das, egal wie ich das mache. Was RPG eigentlich fehlt, das ist qualified naming für Prozedur Aufrufe - ab und an denke ich darüber nach, ob man da nicht einen kleinen Pre Compiler bauen sollte, so eine Art RPGFront als Einstieg in RPG++ (CFront lässt grüßen).
@Doku: ist im Prinzip alles richtig, was du sagst, was dem bei mir entgegen steht, ist eher Faulheit
@weitere Funktionalität: die habe ich im Moment nicht benötigt (ebenso wenig wie Thread Sicherheit)
Dieter
Hallo,
da die Prototypen per Copybook in die Programme eingebunden werden, finde ich es immer wieder merkwürdig, wenn die exportierten Prozedurnamen einen Präfix bekommen, die Prozedurnamen der Prototypen aber keinen Präfix haben. Auf der Maschine (i5), auf der ich arbeite, bekomme ich eine Fehlermeldung (RNF0516), wenn ich zwei Prototypen habe, die den selben Namen haben (auch mit unterschiedlichem exportieren Prozedurnamen).
Sollte man nun ein Serviceprogramm für eine Hashtable haben und ein Serviceprogramm für ein dynamisches Array (Vector oder Linked List, ist ja auch egal) und beide haben die Prozedur "isEmpty" ohne Präfix, bekommt man Probleme, wenn man beides in einem Programm verwenden will.
Oder habe ich da etwas übersehen?
Gruss
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
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
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
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
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) (http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/CPYBWP.htm?resultof=%22%63%70%79%62%77%70%22%20)
... 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) (http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/CPYBWP.htm?resultof=%22%63%70%79%62%77%70%22%20)