Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › 32-Bit-Software: Die Openstreetmap…

Wenn schon 32bit warum kein uint?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wenn schon 32bit warum kein uint?

    Autor: mc-kay 14.02.13 - 11:20

    Oder gibt es negative nodes?

  2. Re: Wenn schon 32bit warum kein uint?

    Autor: as (Golem.de) 14.02.13 - 11:23

    Hallo,

    mc-kay schrieb:
    --------------------------------------------------------------------------------
    > Oder gibt es negative nodes?

    jupp, zum Teil: "Editors tend to save these as negative to denote id's that haven't been saved to the server."

    gruß

    -Andy (Golem.de)

  3. Re: Wenn schon 32bit warum kein uint?

    Autor: droptable 14.02.13 - 11:36

    Genau das gleiche dachte ich auch :-)

  4. Re: Wenn schon 32bit warum kein uint?

    Autor: non_sense 14.02.13 - 11:37

    Außerdem wirst du bei Java (und somit auch bei Android-Apps) Probleme bekommen, da Java kein Unsigned kennt.

  5. Re: Wenn schon 32bit warum kein uint?

    Autor: nille02 14.02.13 - 11:59

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > Außerdem wirst du bei Java (und somit auch bei Android-Apps) Probleme
    > bekommen, da Java kein Unsigned kennt.

    Das weiß auch jeder Entwickler, aber wenn es bekannt ist benutzt man einfach ein long.

  6. Re: Wenn schon 32bit warum kein uint?

    Autor: non_sense 14.02.13 - 12:29

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Das weiß auch jeder Entwickler, aber wenn es bekannt ist benutzt man
    > einfach ein long.

    Tja, vielen war es wohl nicht bekannt, dass die größe der IDs die 32 Bits übersteigen werden, sonst gäbe es ja kein Artikel darüber ;)

    long benutze ich auch nur recht selten, da ich in den meisten Fällen schon weiß, dass es nie zu einem Überlauf kommen wird. Ich sehe es einfach nicht ein, die doppelte Menge an Speicher zu verbraten, nur um wirklich auf Nummer sicher zu gehen, dass meine Software in 40 Jahren keinen Speicherüberlauf hat, wenn tatsächlich irgendwann mal so viele IDs auftauchen sollten.

  7. Re: Wenn schon 32bit warum kein uint?

    Autor: nille02 14.02.13 - 12:43

    non_sense schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das weiß auch jeder Entwickler, aber wenn es bekannt ist benutzt man
    > > einfach ein long.
    >
    > Tja, vielen war es wohl nicht bekannt, dass die größe der IDs die 32 Bits
    > übersteigen werden, sonst gäbe es ja kein Artikel darüber ;)

    Du solltest alles Zitieren. Die Aussage bezieht sich darauf das Java keine unsight Datentypen kennt. Wenn ich ein unsight int erwarte benutze ich dann entsprechend nicht einfach ein sight int.

    >
    > long benutze ich auch nur recht selten, da ich in den meisten Fällen schon
    > weiß, dass es nie zu einem Überlauf kommen wird. Ich sehe es einfach nicht
    > ein, die doppelte Menge an Speicher zu verbraten, nur um wirklich auf
    > Nummer sicher zu gehen, dass meine Software in 40 Jahren keinen
    > Speicherüberlauf hat, wenn tatsächlich irgendwann mal so viele IDs
    > auftauchen sollten.

    Bei dem System konnte man es doch aber vorhersehen das es nicht reichen wird.

  8. Re: Wenn schon 32bit warum kein uint?

    Autor: Endwickler 14.02.13 - 14:20

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > ...
    > Die Aussage bezieht sich darauf das Java keine unsight Datentypen kennt.
    > Wenn ich ein unsight int erwarte benutze ich dann
    > entsprechend nicht einfach ein sight int.
    > ...

    Meintest du mit sight und unsight vielleicht signed und unsigned oder sind das spezielle Datentypen, die ich nicht kenne, weil ich kaum JS mache?
    Wenn es signed und unsigned sein soll: Opfer der Wortvervollständigung?

  9. Re: Wenn schon 32bit warum kein uint?

    Autor: nille02 14.02.13 - 14:22

    Endwickler schrieb:
    --------------------------------------------------------------------------------
    > Opfer der Wortvervollständigung?

    Und selber nicht noch mal drüber geschaut.

  10. Re: Wenn schon 32bit warum kein uint?

    Autor: d^vid 14.02.13 - 20:57

    Endwickler schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ...
    > > Die Aussage bezieht sich darauf das Java keine unsight Datentypen kennt.
    > > Wenn ich ein unsight int erwarte benutze ich dann
    > > entsprechend nicht einfach ein sight int.
    > > ...
    >
    > Meintest du mit sight und unsight vielleicht signed und unsigned oder sind
    > das spezielle Datentypen, die ich nicht kenne, weil ich kaum JS mache?
    > Wenn es signed und unsigned sein soll: Opfer der Wortvervollständigung?

    Wie kommst du auf JS?

  11. Re: Wenn schon 32bit warum kein uint?

    Autor: fletschge 15.02.13 - 14:49

    OT:

    Ist ein int nicht immer so gross wie die Adressbreite der CPU (also z.B. 32 oder 64 bit) und ein long ist immer 64 bit, unabhängig von der Architektur?

    Lasse mich gerne eines Besseren belehren.

  12. Re: Wenn schon 32bit warum kein uint?

    Autor: nille02 15.02.13 - 15:09

    fletschge schrieb:
    --------------------------------------------------------------------------------
    > OT:
    >
    > Ist ein int nicht immer so gross wie die Adressbreite der CPU (also z.B. 32
    > oder 64 bit) und ein long ist immer 64 bit, unabhängig von der
    > Architektur?
    >
    > Lasse mich gerne eines Besseren belehren.

    Ne, das hat alles nicht miteinander zu tun. Ist halt alles eine Frage wie es auf der Plattform, CPU gehandhabt wird und was der Compiler daraus macht.

    > http://de.wikipedia.org/wiki/Datenwort

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. HMS media solutions, Halle (Saale)
  2. PHOENIX CONTACT GmbH & Co. KG, Blomberg
  3. BWI GmbH, Bonn
  4. Universität Hamburg, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 18,99€
  2. (u. a. Fractal Design Meshfy Light Tint 69,90€)
  3. 399,00€ (Wert der Spiele rund 212,00€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Uploadfilter: Voss stellt Existenz von Youtube infrage
Uploadfilter
Voss stellt Existenz von Youtube infrage

Gut zwei Wochen vor der endgültigen Abstimmung über Uploadfilter stehen sich Befürworter und Gegner weiter unversöhnlich gegenüber. Verhandlungsführer Voss hat offenbar kein Problem damit, wenn es Plattformen wie Youtube nicht mehr gäbe. Wissenschaftler sehen hingegen Gefahren durch die Reform.

  1. Uploadfilter Koalition findet ihren eigenen Kompromiss nicht so gut
  2. Uploadfilter Konservative EVP will Abstimmung doch nicht vorziehen
  3. Uploadfilter Spontane Demos gegen Schnellvotum angekündigt

Security: Vernetzte Autos sicher machen
Security
Vernetzte Autos sicher machen

Moderne Autos sind rollende Computer mit drahtloser Internetverbindung. Je mehr davon auf der Straße herumfahren, desto interessanter werden sie für Hacker. Was tun Hersteller, um Daten der Insassen und Fahrfunktionen zu schützen?
Ein Bericht von Dirk Kunde

  1. Alarmsysteme Sicherheitslücke ermöglicht Übernahme von Autos
  2. Netzwerkanalyse Wireshark 3.0 nutzt Paketsniffer von Nmap
  3. Sicherheit Wie sich "Passwort zurücksetzen" missbrauchen lässt

Display-Technik: So funktionieren Micro-LEDs
Display-Technik
So funktionieren Micro-LEDs

Nach Flüssigkristallanzeigen (LCD) mit Hintergrundbeleuchtung und OLED-Bildschirmen sind Micro-LEDs der nächste Schritt: Apple arbeitet daran für Smartwatches und Samsung hat bereits einen Fernseher vorgestellt. Die Technik hat viele Vorteile, ist aber aufwendig in der Fertigung.
Von Mike Wobker

  1. AU Optronics Apple soll Wechsel von OLEDs zu Micro-LEDs vorbereiten

  1. DDR4-Speicher: Samsung hat dritte 10-nm-Generation entwickelt
    DDR4-Speicher
    Samsung hat dritte 10-nm-Generation entwickelt

    Mit DRAM im 1Z-Verfahren will Samsung seine DDR4-Speicherproduktion noch weiter steigern, denn die Chips sollen auf dem kleinsten 10-nm-Class-Fertigungsprozess am Markt basieren. Die Südkoreaner verzichten dabei auf extrem ultraviolette Strahlung (EUV.)

  2. Android 9: Oneplus startet Pie-Beta für Oneplus 3 und 3T
    Android 9
    Oneplus startet Pie-Beta für Oneplus 3 und 3T

    Nachdem Oneplus die aktuelle Android-Version 9 alias Pie bereits auf das Oneplus 5, 5T und 6 gebracht hat, wendet sich der Hersteller seinen älteren Modellen zu: Für das Oneplus 3 und 3T ist eine geschlossene Betaversion angekündigt worden, für die sich Nutzer bewerben können.

  3. Matisse: Erste Hauptplatinen unterstützen AMDs Ryzen 3000
    Matisse
    Erste Hauptplatinen unterstützen AMDs Ryzen 3000

    Diverse Hersteller haben damit begonnen, für ihre Mainboards neue Firmware bereitzustellen, die mit AMDs kommenden Matisse-CPUs alias Ryzen 3000 umgehen kann. Offiziell sollen die Prozessoren zur Jahresmitte 2019 veröffentlicht werden.


  1. 11:32

  2. 10:26

  3. 09:35

  4. 09:18

  5. 09:15

  6. 08:43

  7. 07:49

  8. 07:29