nicht angemeldet
Halihallo Andreas
Hm. Long-IP für Longinteger wäre IMHO passender :-)
Stimmt, habe ich auch verwendet, nur hat das bei meinen 1MB keinen Unterschied gemacht, nur war FLOAT als Format angegeben und hatte es daher übernommen ;-)
Wer setzt denn FLOAT als Format zur Speicherung von IP's voraus? - Pfui :-)
Hat halt den Vorteil dass man dann die IP nicht mehr als String hat, sondern als Zahl, nur leider sind die meisten IPs zu groß für INT :-(
Hä? - Schalte ein unsigned davor oder substrahiere sie von INT_MAX, so kommst du wieder
zur lesbaren Form.
Hä? Was ist unsigned und wie schalte ich das wo vor?
Hä? :-)
Deklariert den Integer als Vorzeichenlos, somit wird der Wertebereich im positiven
Bereich verdoppelt und der negative fällt eben weg. Gibt's ja auch bei MySQL.
INT hat sowohl in PHP als auch in MySQL und ich denke auch überall anders, einfach einen zu kleinen Wertebereichüber den gehen dei IPs weit hinaus.
In MySQL ist INT ein Datentyp mit 32bit, kann also eine IP vollständig abbilden.
Die Zahl wird nur bei SIGNED evtl. negativ, da das letzte bit (bit 31) gesetzt ist,
was eben die Zahl als negativ "markiert". Bei UNSIGNED (vorzeichenlos) wirst du
immer eine positive Zahl kriegen.
Bei C sieht's etwas anders aus, da kann int mal 32, mal 64bit haben, je nach dem, ob
die Platform 32 oder 64bit hat. Ein 32-bit-Integer erhält man da explizit über short.
Also UNSIGNED INT kann die Werte 0-(2^32-1) abbilden, SIGNED INT kann die Werte
-2^31 bis (2^31-1) abbilden. Wenn du nun eine "grosse" IP in einem vorzeichenbehafteten
Integer abbildest, kann es vorkommen, dass die Zahl als negativ "interpretiert" wird,
aber die Zahl wird 100% komplett abgebildet.
Daher verwende ich halt LONINT, aber da PHP kein LONGINT kennt, verwende ich hier FLOAT, denn bei INT kommen komische negative Zahlen bei der Konvertierung raus, naja.
s. oben.
Oder man bräuchte ein Supa-Dupa Sun Fire Rechner mit 128bit Registern :-)
JAAA! Ich versuche schon seit Monaten eine Richtfunkstrecke 1 KM bis ins Rechenzentrum unserer Uni hinzubekommen, muss jetzt vom Dach nur noch irgendwie das dicke Kabel in den Keller bekommen, denn da gibt es das:
16 [ image:http://www.rz.rwth-aachen.de/hpc/sun/16x6800.jpg ] und 4 [ image:http://www.rz.rwth-aachen.de/hpc/sun/sunfire15k_einblick.jpg ]
http://www.rz.rwth-aachen.de/hpc/sun/index_e.html
http://www.rz.rwth-aachen.de/hpc/hw/Clusterhardware.html
Dann wäre das Performance-Problem ein für alle mal geklärt und ich müsste mich nicht mehr über meine stümperhaften Algorithmen ärgern ;-)))
Mama mia, will ich auch, her damit! :-)
Nun ja, früher hat man sich um jedes verlorene Byte geärgert und heute gibt es viele
Virtual Maschines, Perl, PHP, ... die eine virtuelle Umgebung simulieren und damit
tausende an Kilobytes verschwenden... Für jede Variable, die in PHP oder Perl definiert
wird, gehen einfach mal schwups einige Bytes drauf, ohne überhaupt einen Inhalt darin
festgelegt zu haben, oder es wird ein pseudo Maschinencode entwickelt, der von einem
Interpreter abgearbeitet wird... Ich glaube, du bist nicht der einzige, der von
den Vorzügen neuer Möglichkeiten auch Verwendung machen will :-)
Wer könnte sich heute noch vorstellen, dass der Bordcomputer der Mondlandung mit ein
paar Kilobyte auskam; ich hätte Schwierigkeiten ein Programm mit Perl zu schreiben, dass
unter dieser Voraussetzung überhaupt ein "Hello World" auf dem Bildschrim ausgibt,
geschweige denn mit Euler-Approximationen die Flugbahn vorherzuberechnen :-)
Strange world...
Viele Grüsse
Philipp