Seltsames Reflections Verhalten [Neues Problem]

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	Kernle 32DLL Betreff: Seltsames Reflections Verhalten [Neues Problem]	Mo, Jun 22, 2009 12:38 Antworten mit Zitat
Hiho, beim erkunden der Möglichkeiten von Reflections, ist mir heute etwas aufgefallen. Undzwar gibt es wohl Probleme mit den Methoden "Get" und "Set" im bezug auf eigene Klassen. Code: [AUSKLAPPEN] [EINKLAPPEN] Method Debug() Local id:TTypeId = TTypeId.ForObject(Self) Print id.Name() For Local fld:TField = EachIn id.EnumFields() Print "~t" + fld.Name() + ":" + fld.TypeId().Name() + " = " + String(fld.Get(Self) ) Next End Method [....] Method ZeroMemory() Local id:TTypeId = TTypeId.ForObject(Self) For Local fld:TField = EachIn id.EnumFields() If fld.TypeId().Name() = "TPlayer" fld.Set Self , Null Else fld.Set Self , String(Null) EndIf Next End Method Was ist der Sinn der Methoden? Debug soll alle Felder (funktioniert soweit üprigens auch mit vererbten Klassen) mit ihren Werten ausgeben. Das Funktioniert mit allen Datentypen von BMax prima, aber sobald es um Felder mit eigenen Datentypen geht (z.b. TPlayer?) gibt es keine Ausgabe des Wertes mehr (spezifischer, "String(fld.Get(Self) )" gibt "" zurück). Ein seltsames verhalten zeigt auch "fld.Set Self , String(Null)" bei eigenen Datentypen. Es gibt einfach eine (viel sagende) Exception "ERROR". Darum habe ich in der Methode "ZeroMemory" einen Bypass geschrieben. Ob das funktioniert weis ich net, und der Bypass ist auch nur verrübergehend (ich weis halt nicht genau wieso es bei eigenen Datentypen eine "ERROR" exception gibt...) Hat einer Idee wodran das liegt? Bug? Oder habe ich einfach murks gebaut? Myteriös ist auch das die Set Methode eigentlich NUR Strings annehmen sollte, bei eigenen Datentypen aber nur mit Null funktioniert (wie zur Hölle kann das sein?) So long, Kernle Edit: Ich muss mich korrigieren, das Set nur Strings an nimmt ist natürlich quark, es nimmt Objects an. Aber warum die Methode mit "fld.Set Self , String(Null)" nur bei BMax Datentypen, und nicht bei eigenen funktioniert, ist mir ein Rätsel. Und ebenfalls, wieso Null auf einmal als Parameter geht, wo es doch sonst immer die besagte Exception wirft.
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Betreff: Seltsames Reflections Verhalten [Neues Problem]

Mo, Jun 22, 2009 12:38
Antworten mit Zitat

Hiho, beim erkunden der Möglichkeiten von Reflections, ist mir heute etwas aufgefallen. Undzwar gibt es wohl Probleme mit den Methoden "Get" und "Set" im bezug auf eigene Klassen.

Code: [AUSKLAPPEN]

Method Debug()
   Local id:TTypeId = TTypeId.ForObject(Self)

   Print id.Name()

   For Local fld:TField = EachIn id.EnumFields()
      Print "~t" + fld.Name() + ":" + fld.TypeId().Name() + " = " + String(fld.Get(Self) )
   Next
End Method

[....]

Method ZeroMemory()
   Local id:TTypeId = TTypeId.ForObject(Self)
   For Local fld:TField = EachIn id.EnumFields()
      If fld.TypeId().Name() = "TPlayer"
         fld.Set Self , Null
      Else
         fld.Set Self , String(Null)
      EndIf
   Next
End Method

Was ist der Sinn der Methoden? Debug soll alle Felder (funktioniert soweit üprigens auch mit vererbten Klassen) mit ihren Werten ausgeben. Das Funktioniert mit allen Datentypen von BMax prima, aber sobald es um Felder mit eigenen Datentypen geht (z.b. TPlayer?) gibt es keine Ausgabe des Wertes mehr (spezifischer, "String(fld.Get(Self) )" gibt "" zurück). Ein seltsames verhalten zeigt auch "fld.Set Self , String(Null)" bei eigenen Datentypen. Es gibt einfach eine (viel sagende) Exception "ERROR". Darum habe ich in der Methode "ZeroMemory" einen Bypass geschrieben. Ob das funktioniert weis ich net, und der Bypass ist auch nur verrübergehend (ich weis halt nicht genau wieso es bei eigenen Datentypen eine "ERROR" exception gibt...)

Hat einer Idee wodran das liegt? Bug? Oder habe ich einfach murks gebaut? Myteriös ist auch das die Set Methode eigentlich NUR Strings annehmen sollte, bei eigenen Datentypen aber nur mit Null funktioniert (wie zur Hölle kann das sein?)

So long,
Kernle

Edit: Ich muss mich korrigieren, das Set nur Strings an nimmt ist natürlich quark, es nimmt Objects an. Aber warum die Methode mit "fld.Set Self , String(Null)" nur bei BMax Datentypen, und nicht bei eigenen funktioniert, ist mir ein Rätsel. Und ebenfalls, wieso Null auf einmal als Parameter geht, wo es doch sonst immer die besagte Exception wirft.

Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog]
Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89
Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Zuletzt bearbeitet von Kernle 32DLL am Sa, Jun 27, 2009 18:25, insgesamt 3-mal bearbeitet

	hamZta Administrator	Mo, Jun 22, 2009 14:21 Antworten mit Zitat
Der Get-Part liegt daran, dass BlitzMax beim Cast von Object nach String (String(fld.Get(Self) )) scheinbar nicht die Standardmethode "ToString" die jedes Object implementiert hat aufruft sondern nur primitive Datentypen in einen String konvertiert. Da hat Mark wohl wieder mal gegen seine eigenen Pläne verstoßen. Wie es aussieht klappt auch der Ansatz, zu prüfen ob die TypeId des Feldes vom Typ ObjectTypeId ist nicht (If fld.TypeId() = ObjectTypeId). Manchmal frag ich mich, was sich Mark so den ganzen Tag denkt. Du könntest prüfen ob der Name der TypeId (fld.TypeId().Name()) kein Name eines Standarddatentyps ist und dich so irgendwie entlanghangeln. hamZta
Blog.

hamZta

Administrator

Mo, Jun 22, 2009 14:21
Antworten mit Zitat

Der Get-Part liegt daran, dass BlitzMax beim Cast von Object nach String (String(fld.Get(Self) )) scheinbar nicht die Standardmethode "ToString" die jedes Object implementiert hat aufruft sondern nur primitive Datentypen in einen String konvertiert. Da hat Mark wohl wieder mal gegen seine eigenen Pläne verstoßen.

Wie es aussieht klappt auch der Ansatz, zu prüfen ob die TypeId des Feldes vom Typ ObjectTypeId ist nicht (If fld.TypeId() = ObjectTypeId). Manchmal frag ich mich, was sich Mark so den ganzen Tag denkt.

Du könntest prüfen ob der Name der TypeId (fld.TypeId().Name()) kein Name eines Standarddatentyps ist und dich so irgendwie entlanghangeln.

hamZta

Blog.

	Kernle 32DLL	Sa, Jun 27, 2009 18:28 Antworten mit Zitat
Und hier komme ich mit einem neuen Problem. Nachdem ich heute geprüft habe ob ich irgendwo Speicherlecks habe, ist mir etwas sehr seltsames aufgfefallen. Undzwar wenn ich den Befehle TTypeId.ForObject() aufrufe macht der genutzte Speicher der Applikation einen deutlichen Sprung nach oben, ohne ersichtlichen Grund. Auch das durchforsten von Brl.Reflections hat mich net weiter gebracht. Um mein Problem zu verdeutlichen, hier ein mini-testprogramm: Code: [AUSKLAPPEN] [EINKLAPPEN] Type TBlubb Field Gaga:Byte End Type Local Blubb:TBlubb = New TBlubb GCCollect() Print GCMemAlloced() TTypeId.ForObject(Blubb) GCCollect() Print GCMemAlloced() Es funktioniert auch mit TTypeId.ForObject(Null), der Effekt ist der gleiche. Hat jemand eine Idee wodran das liegt, und wie man das ggf. beheben kann? So long, Kernle
Mein PC: "Bluelight" - Xtreme Gamer PC [Video] Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009

Kernle 32DLL

Sa, Jun 27, 2009 18:28
Antworten mit Zitat

Und hier komme ich mit einem neuen Problem. Nachdem ich heute geprüft habe ob ich irgendwo Speicherlecks habe, ist mir etwas sehr seltsames aufgfefallen. Undzwar wenn ich den Befehle TTypeId.ForObject() aufrufe macht der genutzte Speicher der Applikation einen deutlichen Sprung nach oben, ohne ersichtlichen Grund. Auch das durchforsten von Brl.Reflections hat mich net weiter gebracht. Um mein Problem zu verdeutlichen, hier ein mini-testprogramm:

Code: [AUSKLAPPEN]

Type TBlubb
Field Gaga:Byte
End Type

Local Blubb:TBlubb = New TBlubb

GCCollect()
Print GCMemAlloced()

TTypeId.ForObject(Blubb)

GCCollect()
Print GCMemAlloced()

Es funktioniert auch mit TTypeId.ForObject(Null), der Effekt ist der gleiche.

Hat jemand eine Idee wodran das liegt, und wie man das ggf. beheben kann?

So long,
Kernle

	Suco-X Betreff: .....	Sa, Jun 27, 2009 19:05 Antworten mit Zitat
Musst du genauer im Code hinschauen. Beim ersten Aufruf von TTYpeId.ForObject erstellt BlitzMax eine Liste mit den Registrierten Typen (Siehe _Update() Methode im Code bei TTypeId). Dieser Vorgang ist aber einmalig. Deshalb dauert der erste Aufruf auch immer ein wenig länger. Wieso benutzt du bei der Debug-Methode nicht einfach fld.Get(self).ToString() ? Dann wird die ToString Methode des Objects aufgerufen. Da sie für Integer, Floats usw. schon definiert ist, wird er bei deinem Objekt die Adresse ausspucken, kannst die Methode aber überschreiben und etwas beliebiges zurückgeben. Mfg Suco
Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

Suco-X

Betreff: .....

Sa, Jun 27, 2009 19:05
Antworten mit Zitat

Musst du genauer im Code hinschauen. Beim ersten Aufruf von TTYpeId.ForObject erstellt BlitzMax eine Liste mit den Registrierten Typen (Siehe _Update() Methode im Code bei TTypeId). Dieser Vorgang ist aber einmalig. Deshalb dauert der erste Aufruf auch immer ein wenig länger.
Wieso benutzt du bei der Debug-Methode nicht einfach fld.Get(self).ToString() ?
Dann wird die ToString Methode des Objects aufgerufen. Da sie für Integer, Floats usw. schon definiert ist, wird er bei deinem Objekt die Adresse ausspucken, kannst die Methode aber überschreiben und etwas beliebiges zurückgeben.
Mfg Suco

Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Seltsames Reflections Verhalten [Neues Problem]

Kernle 32DLL

Betreff: Seltsames Reflections Verhalten [Neues Problem]

hamZta

Kernle 32DLL

Suco-X

Betreff: .....