Ankündigung

Einklappen
Keine Ankündigung bisher.

OOP - Rekursive Verknüpfungen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    spl_object_hash oder so ähnlich heisst die Zauberfunktion.
    www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
    Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

    Kommentar


    • #17
      Zitat von mepeisen Beitrag anzeigen
      spl_object_hash oder so ähnlich heisst die Zauberfunktion.
      Yup, spl_object_hash() ... exakt so.

      Die muss ich bisher übersehen haben. Scheint auch mal wieder eine für PHP typische Implementierung zu sein: Statt einfach den Pointer aufs Objekt als String zurückzugeben, wird wieder irgendein umständlicher Hokus-Pokus ausgeführt. ... und mit Arrays kann die Funktion auch nichts anfangen. Trotzdem sehr nützlich.
      Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

      Kommentar


      • #18
        Das gibts sogar in der SPL ein "Array", was Objekte als Key verwenden kann Und das ist kein Hokuspokus, das ist im Prinzip eine Art Pointer. in Textform. lediglich das Reverse ist so nicht möglich.
        www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
        Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

        Kommentar


        • #19
          Zitat von mepeisen Beitrag anzeigen
          Das gibts sogar in der SPL ein "Array", was Objekte als Key verwenden kann
          meinst du SPL Object Storage?

          Zu sowas ähnlichem kann ich das gebrauchen. Dein "sogar" darf man aber nur auf PHP beziehen. In Python (nur mal so als Beispiel) ist jedes Objekt "hashable", das eine magische Funktion implementiert. Nur in PHP ist man (ohne SPL) auf Strings und Integers als Keys festgenagelt.

          Und das ist kein Hokuspokus, das ist im Prinzip eine Art Pointer. in Textform. ...
          Doch ist es. Guckst du PHP 5.3.0
          /ext/spl/php_spl.c:
          Code:
          PHPAPI void php_spl_object_hash(zval *obj, char *result TSRMLS_DC) /* {{{*/
          {
          	intptr_t hash_handle, hash_handlers;
          	char *hex;
          
          	if (!SPL_G(hash_mask_init)) {
          		if (!BG(mt_rand_is_seeded)) {
          			php_mt_srand(GENERATE_SEED() TSRMLS_CC);
          		}
          
          		SPL_G(hash_mask_handle)   = (intptr_t)(php_mt_rand(TSRMLS_C) >> 1);
          		SPL_G(hash_mask_handlers) = (intptr_t)(php_mt_rand(TSRMLS_C) >> 1);
          		SPL_G(hash_mask_init) = 1;
          	}
          
          	hash_handle   = SPL_G(hash_mask_handle)^(intptr_t)Z_OBJ_HANDLE_P(obj);
          	hash_handlers = SPL_G(hash_mask_handlers)^(intptr_t)Z_OBJ_HT_P(obj);
          
          	spprintf(&hex, 32, "%016x%016x", hash_handle, hash_handlers);
          
          	strlcpy(result, hex, 33);
          	efree(hex);
          }
          /* }}} */
          Ein sprintf(..., '%08x', obj, ...)
          oder ein Z_OBJ_HANDLE_PP(obj)
          hätte es doch auch getan.

          ... lediglich das Reverse ist so nicht möglich.
          Der eindeutige Identifier reicht. Keiner will das Ding dereferenzieren und dann wild im Speicher rumPOKEn. Das geht in PHP sowieso nicht, weil einem da systematisch der direkte Zugriff auf alle System-Ressourcen verwehrt bleibt.

          Deswegen brauchts ja auch die SPL-Krücken, um Datenstrukturen zu bauen, die vom Standard-Array abweichen. Oder man stößt beim Selberbasteln auf die Probleme, die zum Ausgangsposting dieses Threads führten.
          Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

          Kommentar


          • #20
            Code:
            spprintf(&hex, 32, "%016x%016x", hash_handle, hash_handlers);
            Zitat von fireweasel Beitrag anzeigen
            Ein sprintf(..., '%08x', obj, ...)
            oder ein Z_OBJ_HANDLE_PP(obj)
            hätte es doch auch getan.
            So sind sie auf 64bit Betriebssysteme vorbereitet
            Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

            Kommentar


            • #21
              Zitat von lstegelitz Beitrag anzeigen
              So sind sie auf 64bit Betriebssysteme vorbereitet
              Uiuiui, das ist mir jetzt peinlich. Da hatte ich mal wieder die ganzen Bytes gezählt, statt der halben. Natürlich war "%x016" gemeint. "Z_OBJ_HANDLE_PP(obj)" wäre mir aber ohnehin lieber ...
              Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

              Kommentar


              • #22
                Zitat von fireweasel Beitrag anzeigen
                Uiuiui, das ist mir jetzt peinlich. Da hatte ich mal wieder die ganzen Bytes gezählt, statt der halben. Natürlich war "%x016" gemeint. "Z_OBJ_HANDLE_PP(obj)" wäre mir aber ohnehin lieber ...
                Trotzdem hättest du mit dem Vertrag bei 64bit-Systemen ein Problem. Der Vertrag sagt: Der Hash muss EINDEUTIG sein. Ein reines %016x auf die Adresse im RAM ist nicht garantiert eindeutig. Deswegen diese "Magic". Was die Makros da tun, müsste man mal schauen, aber es scheint dadurch generell eindeutig zu werden.
                www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

                Kommentar


                • #23
                  Zitat von mepeisen Beitrag anzeigen
                  Trotzdem hättest du mit dem Vertrag bei 64bit-Systemen ein Problem. Der Vertrag sagt: Der Hash muss EINDEUTIG sein. Ein reines %016x auf die Adresse im RAM ist nicht garantiert eindeutig.
                  Wieso sollte die Adresse nicht eindeutig sein? Können sich zwei unterschiedliche PHP-Objekte eine Adresse teilen?
                  Möglicherweise war meine improvisierte sprintf-Anwendung da unpassend, ich wollte die Adresse und nicht die Daten, die sich dort befinden.

                  Ich würde sowieso die Objekt-ID, also Z_OBJ_HANDLE_PP() bevorzugen.
                  Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                  Kommentar


                  • #24
                    Die Adresse ist selbst eindeutig. Aber nicht als unsigned int darstellbar. Das war sie noch nie. Dazu müsste ich nun erklären, wie Adressierung in der Intel-Architektur funktioniert. Glaube mir einfach mal, dass auf 32Bit-Systemen die Adresse generell über 48Bit dargestellt wird. Auf 64 Bit-Systemen müssten das ebenfalls entweder 80 Bit oder mehr sein (Falls du nachschlagen willst: Zauberwort Selektor oder Far-Pointer vs. Near-Pointer). Theoretisch kann die Adresse mit 64Bit eindeutig sein (Programme arbeiten in der Regel nur mit einem Selektor für Code und einem zweiten für Heap), das garantieren, würde ich nicht wollen. Die eindeutige Adresse ist somit niemals so exakt über printf darstellbar, wenn man sich unabhängig von physiklaischer Adressierung des Speichers machen will. Es gibt Prozessorsysteme, da ist es noch komplizierter.
                    Genau aus diesem Grund, um die Abhängigkeit zur physikalischen Ausrichtung von Speicherbereichen zu vermeiden, sollte man niemals einfach so wortlos davon ausgehen, dass eine hexadezimale Ausgabe von Adressen eindeutig ist. Um Beispielsweise zu Debugging-Zwecken mal nachvollziehen was passiert, ist das OK. Mehr nicht. Es kann je nach Compiler bereits ein unterschiedliches Segment für Heap und Stack geben und schon hast du Probleme Adressen eins zu eins zu übersetzen. Dann kann die 64-Bit-Adresse 0x0001000200030004 unterschiedliche Speicherbereiche meinen, je nachdem ob sie mit Stack-Selektor oder Heap-Selektor geladen wird.
                    www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                    Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

                    Kommentar


                    • #25
                      Ojeh, wir kommen nicht nur vom Thema ab (tun wir?), es wird auch immer komplizierter. Lassen wir mal die Ausgabe und Umwandlung einer "Viel"-Bit-Integer-Zahl per sprintf() ausgeblendet oder nehmen einfach an, es könnte so funktionieren, wie mein unkompliziert gewebtes Gemüt sich das so vorstellt(e) ...

                      Zitat von mepeisen Beitrag anzeigen
                      Die Adresse ist selbst eindeutig. Aber nicht als unsigned int darstellbar. Das war sie noch nie. Dazu müsste ich nun erklären, wie Adressierung in der Intel-Architektur funktioniert. Glaube mir einfach mal, ...
                      Muss ich ja wohl, da mir größtenteils einfach das Verständnis für die verquere x86-Logik fehlt. Mit 68k und PPC kam|komme ich besser zurecht.

                      ... dass auf 32Bit-Systemen die Adresse generell über 48Bit dargestellt wird. Auf 64 Bit-Systemen müssten das ebenfalls entweder 80 Bit oder mehr sein ...
                      Okay, dann machen wir das ganze halt ein paar Bits breiter. Das erschien mir aber (anfangs) immer noch vernünftiger, als mit Zufallsfunktionen (... mt_rand() ...) eine ID auszuwürfeln.

                      ... (Falls du nachschlagen willst: Zauberwort Selektor oder Far-Pointer vs. Near-Pointer).
                      Zwischenruf: Wurde der umständliche Far-Near-Unfug nicht irgendwann in den Neunzigern abgeschafft? Zauberwort: Flat-Memory-Model?

                      Und das googeln nach deinen Zauberwörtern bringt für meinen Geschmack etwas zu viel archäologisch interessanten Kram hervor (Pattern wie "286" und "16 Bit" bspw.).
                      [1]

                      Theoretisch kann die Adresse mit 64Bit eindeutig sein (Programme arbeiten in der Regel nur mit einem Selektor für Code und einem zweiten für Heap), das garantieren, würde ich nicht wollen. Die eindeutige Adresse ist somit niemals so exakt über printf darstellbar, wenn man sich unabhängig von physiklaischer Adressierung des Speichers machen will.
                      Stimmt, zu eng gedacht. Physikalische Adressen sind nun mal keine logischen ... Address-Aliasing und der ganze Kram, wenn man segmentierte Speichermodelle benutzt.

                      ... Es kann je nach Compiler bereits ein unterschiedliches Segment für Heap und Stack geben und schon hast du Probleme Adressen eins zu eins zu übersetzen. Dann kann die 64-Bit-Adresse 0x0001000200030004 unterschiedliche Speicherbereiche meinen, je nachdem ob sie mit Stack-Selektor oder Heap-Selektor geladen wird.
                      Sollte man nicht trotzdem annehmen können, dass PHP-Objekte (wie alle diese Zend-Val-Dinger) immer auf dem Heap alloziert werden? ...

                      Nein, jetzt werden's mir zu viele Annahmen, ... Z_OBJ_HANDLE_PP() und gut ist's.

                      --

                      [1] Falls hier noch wer mitliest, ein paar (für mich) interessante Google-Suchergebnisse, die irgendwie zum Thema (Speicher, Adressen usw.) passen:

                      http://www.ualberta.ca/CNS/RESEARCH/...sters/mem.html

                      http://stackoverflow.com/questions/4...t-memory-limit

                      http://blogs.technet.com/b/markrussi...1/3092070.aspx
                      Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                      Kommentar


                      • #26
                        Mag sein, dass ich mit Far-Pointer und Near-Pointer die falschen Begrifflichkeiten verwendet habe. Das sind in der Tat Schlagworte aus der 16Bit Architektur. Das Grundprinzip dahinter wurde aber in x86 nie abgeschafft. Es gibt nach wie vor eine Art Segmentierung und auch die Selektoren. Aber ja, wir driften weit vom Thema ab
                        www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                        Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

                        Kommentar


                        • #27
                          Zitat von mepeisen Beitrag anzeigen
                          Mag sein, dass ich mit Far-Pointer und Near-Pointer die falschen Begrifflichkeiten verwendet habe. Das sind in der Tat Schlagworte aus der 16Bit Architektur. Das Grundprinzip dahinter wurde aber in x86 nie abgeschafft. Es gibt nach wie vor eine Art Segmentierung und auch die Selektoren.
                          Zur Einführung in die Thematik reicht(e) das aus. Ich kann schließlich selbst weitergoogeln und -lesen.

                          Aber ja, wir driften weit vom Thema ab
                          Aber niemand soll mehr behaupten, hier würde man auf naive Fragen keine ausführlichen Antworten bekommen.
                          Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                          Kommentar

                          Lädt...
                          X