spl_object_hash oder so ähnlich heisst die Zauberfunktion.
Ankündigung
Einklappen
Keine Ankündigung bisher.
OOP - Rekursive Verknüpfungen
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zitat von mepeisen Beitrag anzeigenspl_object_hash oder so ähnlich heisst die Zauberfunktion.
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
-
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.[url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]
Kommentar
-
Zuletzt geändert von fireweasel; 04.05.2011, 21:43.Zitat von mepeisen Beitrag anzeigenDas gibts sogar in der SPL ein "Array", was Objekte als Key verwenden kann
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. ...
/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); } /* }}} */
oder ein Z_OBJ_HANDLE_PP(obj)
hätte es doch auch getan.
... lediglich das Reverse ist so nicht möglich.
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
-
Code:spprintf(&hex, 32, "%016x%016x", hash_handle, hash_handlers);
Zitat von fireweasel Beitrag anzeigenEin sprintf(..., '%08x', obj, ...)
oder ein Z_OBJ_HANDLE_PP(obj)
hätte es doch auch getan.Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.
Kommentar
-
Zuletzt geändert von fireweasel; 05.05.2011, 13:59.Zitat von lstegelitz Beitrag anzeigenSo sind sie auf 64bit Betriebssysteme vorbereitetWenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.
Kommentar
-
Zitat von fireweasel Beitrag anzeigenUiuiui, 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 ...[url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]
Kommentar
-
Zuletzt geändert von fireweasel; 05.05.2011, 14:03.Zitat von mepeisen Beitrag anzeigenTrotzdem 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.
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
-
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.[url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]
Kommentar
-
Zuletzt geändert von fireweasel; 05.05.2011, 16:36.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 anzeigenDie 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).
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.
... 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.
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.aspxWenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.
Kommentar
-
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[url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]
Kommentar
-
Zitat von mepeisen Beitrag anzeigenMag 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 abWenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.
Kommentar
Kommentar