enumerieren von Objekten
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4443 / 226 /
1194
)
»
hi!
Gibt es eine Möglichkeit die interne Instanznummer oder den Pointer einer Objektinstanz zu ermitteln und z.B. als Integer zu speichern?
Ich habe ein sehr umfangreiches Programm, bei dem sehr viele Objekte angelegt werden. Um nicht jedesmal im Debugger alle Objekte durchzugehen z.B. ob Instanz "x" auch auf dieselben Instanzen wie Instanz "y" zeigt usw. würde ich gerne eine Möglichkeit haben um auf einmal alle aktuellen Instanzen in deren Abhägigkeiten zu ermitteln und als Text auszugeben. Damit wäre es mir leichter möglich Fehler im Programmlauf zu analysieren.
Über RTTI habe ich es schon geschafft die Klasseninformationen zu ermitteln. Mir fehlen nur noch die Informationen über die aktuellen Objektinstanzen (Pointer).
Irgendwie sowas in der Art wäre toll:
Irgendwie muss ja auch der ABAP-Debugger zu seinen (internen) Instanznummer in der Form "{O:84*\CLASS=...}" kommen 
gruss
ADT
Gibt es eine Möglichkeit die interne Instanznummer oder den Pointer einer Objektinstanz zu ermitteln und z.B. als Integer zu speichern?
Ich habe ein sehr umfangreiches Programm, bei dem sehr viele Objekte angelegt werden. Um nicht jedesmal im Debugger alle Objekte durchzugehen z.B. ob Instanz "x" auch auf dieselben Instanzen wie Instanz "y" zeigt usw. würde ich gerne eine Möglichkeit haben um auf einmal alle aktuellen Instanzen in deren Abhägigkeiten zu ermitteln und als Text auszugeben. Damit wäre es mir leichter möglich Fehler im Programmlauf zu analysieren.
Über RTTI habe ich es schon geschafft die Klasseninformationen zu ermitteln. Mir fehlen nur noch die Informationen über die aktuellen Objektinstanzen (Pointer).
Irgendwie sowas in der Art wäre toll:
Code: Alles auswählen.
data: ld_pointer type pointer,
lr_ref type ref to Object.
create object lr_ref type ...
ld_pointer = lr_ref.
gruss
ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Es hat ein bisschen gedauert, bis ich verstand, was du vor hast...
Evtl. hilft dir der Baustein 'GET_GLOBAL_SYMBOLS'!
Du bekommst hier halt nicht die durchnummerierten Objekte, sondern alle Datendeklarationen zurück.
Die Objektreferenzen haben den TYPE "r"...
Und über den Namen kommst du dann ja an die Klasse ran.
Irgendwie...
Glaube ich...
Evtl. hilft dir der Baustein 'GET_GLOBAL_SYMBOLS'!
Du bekommst hier halt nicht die durchnummerierten Objekte, sondern alle Datendeklarationen zurück.
Die Objektreferenzen haben den TYPE "r"...
Und über den Namen kommst du dann ja an die Klasse ran.
Irgendwie...
Glaube ich...
Beitrag
von a-dead-trousers (Top Expert / 4443 / 226 /
1194
)
»
hi!
Ne, das ist nicht so ganz das was ich brauche. Damit könnte ich mir ein Programm/eine Klasse analysieren lassen und die globalen Felder daraus ermitteln. Ich will aber die Intanznummer (= Zeiger/Pointer) eines Objektes zur Laufzeit ermitteln. Jede Objekt- / Dateninstanz zeigt ja im Kernel/Runtime auf eine bestimmte Speicheradresse und ist damit eindeutig identifizierbar und genau das brauche ich: Eine eindeutige Identifizierung von Objektinstanzen.
Ich hab in meinem Programm intern (nicht public) mehrere Instanzen einer Klasse die von unterschiedlichen Aufrufstellen aus referenziert werden und daher wäre es hilfreich zu wissen ob die gleiche Instanz verwendet wird und zwar ohne umständlich im Debugger hin- und herklicken zu müssen.
Ich hab sowas ähnliches zwar schon für Feld-Symbole (die ja eigentlich auch sowas wie Zeiger sind) gefunden, das funktioniert aber leider nicht für Objekteinstanzen:Ach ja, ich hab auch schon versucht, dem Feldsymbol eine Objektinstanz zuzuweisen, nur dann bekomme ich immer denselben Pointer (80030000 Hex)
Ne, das ist nicht so ganz das was ich brauche. Damit könnte ich mir ein Programm/eine Klasse analysieren lassen und die globalen Felder daraus ermitteln. Ich will aber die Intanznummer (= Zeiger/Pointer) eines Objektes zur Laufzeit ermitteln. Jede Objekt- / Dateninstanz zeigt ja im Kernel/Runtime auf eine bestimmte Speicheradresse und ist damit eindeutig identifizierbar und genau das brauche ich: Eine eindeutige Identifizierung von Objektinstanzen.
Ich hab in meinem Programm intern (nicht public) mehrere Instanzen einer Klasse die von unterschiedlichen Aufrufstellen aus referenziert werden und daher wäre es hilfreich zu wissen ob die gleiche Instanz verwendet wird und zwar ohne umständlich im Debugger hin- und herklicken zu müssen.
Ich hab sowas ähnliches zwar schon für Feld-Symbole (die ja eigentlich auch sowas wie Zeiger sind) gefunden, das funktioniert aber leider nicht für Objekteinstanzen:
Code: Alles auswählen.
DATA:
ld_pointer TYPE pointer,
ld_data TYPE i.
FIELD-SYMBOLS:
<ld_data> TYPE any.
ASSIGN ld_data TO <ld_data>.
SYSTEM-CALL POINTER <ld_data> TO ld_pointer.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
okay, wenn du "irgendwelche" Referenzen mitbekommst, ist mein Vorschlag natürlich nicht sehr hilfreich.
Ich bin beim Suchen auf Klassen CL_TPDA_* gestoßen, die wohl mit dem neuen Debugger zu tun haben. Vielleicht kannst du dich da weiter durch wurschteln...?!
Ich bin beim Suchen auf Klassen CL_TPDA_* gestoßen, die wohl mit dem neuen Debugger zu tun haben. Vielleicht kannst du dich da weiter durch wurschteln...?!
Beitrag
von a-dead-trousers (Top Expert / 4443 / 226 /
1194
)
»
ja, die CL_TPDA_* hab ich auch schon entdeckt, nur hängen diese Klassen direkt am Debugger und können nur mit den Symbolnamen umgehen und sind somit Kontextabhängig vom Aufrufstack. Also je nachdem wo ich die Klassenmethoden verwende löst er mir die aktuellen Symbolnamen des Programmcodes in die jeweiligen Instanzen auf, nicht jedoch die Instanzen über die gesamte Laufzeit. Und Symbolnamen zusammenzubasten die irgenwie so aussehen "ir_object->ir_link->ir_object->ir_link" hab ich keine Lust
Zumindest glaub ich das, weil die CL_TPDA_* Klassen konnte ich bis jetzt nicht verwenden da Laufzeitfehler
Ich hab mal einen Workaround gefunden, der zwar nicht sonderlich schön ist, aber zumindest für meine Zwecke funktioniert:
Ich merk mir einfach alle Instanzen in einer internen Tabelle und gebe mir zu den Klassennamen den Index des Tabelleneintrages aus. Damit kann ich zumindest Vergleiche anstellen. Großer Nachteil ist sicherlich, dass dadurch der Garbage Collector die Instanzen nicht mehr sauber freigibt, da ich ja immer noch Zeiger auf die uU bereits obsoleten Instanzen behalte. Auch hab ich hier eigentlich eine doppelte Speicherung von Informationen (Zeiger und Index). Aber zumindest bei der Fehlersuche muss ich nicht wirklich darauf Rücksicht nehmen.
Zumindest glaub ich das, weil die CL_TPDA_* Klassen konnte ich bis jetzt nicht verwenden da Laufzeitfehler
Ich hab mal einen Workaround gefunden, der zwar nicht sonderlich schön ist, aber zumindest für meine Zwecke funktioniert:
Ich merk mir einfach alle Instanzen in einer internen Tabelle und gebe mir zu den Klassennamen den Index des Tabelleneintrages aus. Damit kann ich zumindest Vergleiche anstellen. Großer Nachteil ist sicherlich, dass dadurch der Garbage Collector die Instanzen nicht mehr sauber freigibt, da ich ja immer noch Zeiger auf die uU bereits obsoleten Instanzen behalte. Auch hab ich hier eigentlich eine doppelte Speicherung von Informationen (Zeiger und Index). Aber zumindest bei der Fehlersuche muss ich nicht wirklich darauf Rücksicht nehmen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4131 / 130 /
955
)
»
Hallo ADT,
ich hatte mir das Problem mal kurz angeschaut und bin irgendwie auch nur auf eine Lösung gekommen, die mittels sy-tabix einer internen Tabelle einen Vergleich der Instanzen ermöglicht.
Allerdings sehe ich nicht ein, warum da ein Garbagecollectorproblem auftauchen könnte.
Zum Zeitpunkt der Analyse gehst du doch sicherlich alle verschiedenen Objektzeiger der Reihe nach durch und schaust, ob diverse von diesen Objektzeigern letztlich auf dieselbe Instanz zielen.
Aber nachdem du das gemacht hast, kannst du doch die o.a. interne Tabelle sofort wieder verwerfen ( oder am besten gleich nur lokal vorhalten während der Unterroutine, die den Objektzeigervergleich tätigt). Dann kann der Garbagecollector wieder normal arbeiten und bei der nächsten Analyse baust du dir die Tabelle halt wieder neu auf.
ich hatte mir das Problem mal kurz angeschaut und bin irgendwie auch nur auf eine Lösung gekommen, die mittels sy-tabix einer internen Tabelle einen Vergleich der Instanzen ermöglicht.
Allerdings sehe ich nicht ein, warum da ein Garbagecollectorproblem auftauchen könnte.
Zum Zeitpunkt der Analyse gehst du doch sicherlich alle verschiedenen Objektzeiger der Reihe nach durch und schaust, ob diverse von diesen Objektzeigern letztlich auf dieselbe Instanz zielen.
Aber nachdem du das gemacht hast, kannst du doch die o.a. interne Tabelle sofort wieder verwerfen ( oder am besten gleich nur lokal vorhalten während der Unterroutine, die den Objektzeigervergleich tätigt). Dann kann der Garbagecollector wieder normal arbeiten und bei der nächsten Analyse baust du dir die Tabelle halt wieder neu auf.
Beitrag
von a-dead-trousers (Top Expert / 4443 / 226 /
1194
)
»
Schon klar, ich brauch aber die Instanzen auch über mehrere Dynprowechsel hinweg und daher ist der Ansatz für viele wechselnde Objekte eher ungeeignet. Für meine Zewcke hats funktioniert weil ich doch weniger Instanzen hatte als ursprüglich angenommen. Sollte ja auch nur ein Hinweis sein, falls jemand anderes diese Methode verwenden möchte.
Und sofern man, wie du schon gesagt hat, möglichst zeitnah das löschen der Vergleichstabelle macht ist es eh kein Problem.
Und sofern man, wie du schon gesagt hat, möglichst zeitnah das löschen der Vergleichstabelle macht ist es eh kein Problem.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
4041
Views
Views
8
Antw.
Antw.
2759
Views
Views
3
Antw.
Antw.
2646
Views
Views
6
Antw.
Antw.
3032
Views
Views
namenskonventionen bei workbench-objekten
von gast » 12.08.2005 14:56 • Verfasst in SAP - Allgemeines
von gast » 12.08.2005 14:56 • Verfasst in SAP - Allgemeines
2
Antw.
Antw.
5897
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Einblenden / Füllen Felder in SapScript Formular (Mahnformular für Selbstzahler)
vor 13 Stunden von sap_enthusiast 2 / 4986
vor 13 Stunden von sap_enthusiast 2 / 4986
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Einblenden / Füllen Felder in SapScript Formular (Mahnformular für Selbstzahler)
vor 13 Stunden von sap_enthusiast 2 / 4986
vor 13 Stunden von sap_enthusiast 2 / 4986