Warum faengt das Array bei 0 an?



  • Die Null ist eine der tollsten Erfindungen der Menschheit, die die Mathematik sehr viel weiter gebracht hat. Sag nur mal: Stellenwertsystem. Oder findest Du die Zählweise der Römer praktisch?

    1,2,3 zählen kann jeder Menschenaffe und noch so manch anderes Säugetier. Die Null ist eine menschliche Erfindung.

    Ach ja: es gab Naturvölker, die kamen mit drei Zahlen aus: "1,2,viele."

    0 ist der Ursprung. Wie schon gesagt: bei 1 anfangen wäre willkürlich und wenig logisch.

    AFAIR fangen bei Pascal im Normalfall die Arrays bei 1 an. Kann man aber beliebig anders deklarieren. Ist auch wahrscheinlich bloß ein Entgegenkommen für Neulinge. Pascal ist ja als Lehrsprache konzipiert gewesen.



  • Wenn du ein Array hast, dann muss der 1. Wert irgendwo liegen.
    z.B. Bei irgendeiner Adresse. Nennen wir sie mal willkürlich 0x28FF10
    Der 2. Wert liegt dann bei 0x28FF14, wenn man mal von nem int ausgehen.

    Will ich jetzt den Wert, so kann ich einmal mit a[0] zugreifen, was für dich
    ja jetzt die Frage verursacht hat. Man kann aber auch *(a+0) schreiben.

    Ich find es viel logischer, bei 0 anzufangen, weil bei *(a+1) würde ja schon
    der 2. Wert stehen.

    😃 jaaaa ... schlecht erklärt. Ist aber auch ne doofe Frage



  • Es ist für Ringstrukturen ausgesprochen praktisch:

    array[raw_index % array_size]
    

    Das (bzw. ähnliches) dürfte beispielsweise in Hashtables oft zu sehen sein.

    Außerdem wäre es mit Blick auf Zeigerarithmetik ziemlich verwirrend, das erste Element mit Index 1 anzusprechen.



  • Wenn du Sachen nachmisst fängst du halt immer bei 0 an Oo
    Nen Zollstock beginnt mit 0 (schau mal nach!), das Lebensalter wird gezählt ab 0 (du wirst nicht mit einem jahr geboren). Es macht schon Sinn.



  • Da haette ich auch selber drauf kommen muessen 😞

    Ausserdem muesste es 'array[x+1]=(array + x -1)' heissen, oder? Ansonsten wuerde ja gelten 'array + x -1 = array + x' wenn man das derefernzieren weg laesst und 'array[x]=(array + x -1)' gleich 'array[x]=*(array + x)' setzt. Da ja beide Methoden gegeneinander austauschbar sein sollen.

    Das wuerde wiederum heissen das man x nicht laenger im mathematischen sinne berechenen kann, oder liege ich auf dem Holzweg?

    Gruss
    Baracke



  • Vergesst das letzte, natuerlich sind die beiden Methoden nicht gegeneinander austauschbar. Sollen ja auch Verschieden funktionieren.



  • int array[20];
    int *ptr = array - 1;
    
    // Benutze ptr[1-20]
    

    ...wenn es dich so sehr wurmt.



  • asdfasd schrieb:

    Wenn du Sachen nachmisst fängst du halt immer bei 0 an Oo
    Nen Zollstock beginnt mit 0 (schau mal nach!), das Lebensalter wird gezählt ab 0 (du wirst nicht mit einem jahr geboren). Es macht schon Sinn.

    Und Mathematiker fangen gern bei 1 an (Matrizen und so). Real life Beispiele heranzuziehen, ist Bullshit. Delphi's Arraytyp konnte bei einem beliebigen Wert starten.



  • Dann koennte ich aber keinen index mehr korrekt berechnen (ausser die berechnungen beinhalten nur + oder -), oder?



  • Ich habe die Diskussion auch schon des öfteren geführt und ich bleibe bei meiner Antwort: 0 ist die erste zählbare Zahl. Da vor 0 unendlich negative Zahlen sind, kann man erst bei 0 anfangen zu zählen.



  • Bleibt trotzdem, daß man Arrayfelder bei 0 anfangend benennt und Zwerge anfangend bei 1. Das ist verwirrend.
    Zwerge: http://www.youtube.com/watch?v=Bfr-mroxeDo

    Ich habe leichteres Spiel mit 0 wenn ich Sortieralgorithmen und so schreibe. Ich mag es mit 0. Natürlich geht auch alles mit 1. Die halboffenen Intervalle [0;anzahl[ aneinanderzustückeln und zu teilen ist auch sehr praktisch.



  • seldon schrieb:

    int array[20];
    int *ptr = array - 1;
    
    // Benutze ptr[1-20]
    

    ...wenn es dich so sehr wurmt.

    http://c-faq.com/aryptr/non0based.html



  • Ich hatte ein bisschen Schwierigkeiten, die Stelle im Standard zu finden - in C99 steht das ganze in 6.5.6 (8), nicht in 6.3.6, wie der Link es benennt - aber Tatsache, das ist explizit als undefiniert genannt.

    Gut, in dem Fall könntest du dir mit Makros helfen oder einen Platz mehr im Array anfordern und array[0] ignorieren, sofern du genug Speicher hast. Ratsamer wäre aber, sich an 0-basierte Arrays zu gewöhnen.



  • Nimm halt std::map<int, T>. Dann kannst anfangen wo du willst. Und sogar Sprünge machen. 😉



  • Tim schrieb:

    seldon schrieb:

    int array[20];
    int *ptr = array - 1;
    
    // Benutze ptr[1-20]
    

    ...wenn es dich so sehr wurmt.

    http://c-faq.com/aryptr/non0based.html

    Und wenn in C++ beim nächsten Mal die Garbage Collection eingeführt wird, bist du auch blöd dran.



  • :hoppschwiiz: wxSkip schrieb:

    Und wenn in C++ beim nächsten Mal die Garbage Collection eingeführt wird, bist du auch blöd dran.

    Geht nicht.



  • Wichtig ist mir das nicht, war nur ne frage die mir im Kopf rumgeschwirrt ist und raus wollte. Und eigentlich ist 1 oder was auch immer unnoetig, blaeht nur denn Code auf.

    Aber warum in C++ keine Garbage Collection einfuehren kann ist mir nicht klar.


  • Mod

    Baracke_out schrieb:

    Wichtig ist mir das nicht, war nur ne frage die mir im Kopf rumgeschwirrt ist und raus wollte. Und eigentlich ist 1 oder was auch immer unnoetig, blaeht nur denn Code auf.

    Aber warum in C++ keine Garbage Collection einfuehren kann ist mir nicht klar.

    1. Weil dann Code wie der hier gezeigt nicht mehr funktionieren würde. Und solche oder ähnliche Tricks werden recht oft benutzt. Und wenn man durch eine Erweiterung der Sprache allen Code der bisher existierte ksputt macht, dann macht man die Sprache kaputt. Das ist der Grund warum man keine GC einführen kann.

    2. Außerdem läuft bei Sprachen mit GC die Objekterzeugung und Vernichtung völlig anders. Man müsste die ganze Syntax der Sprache und die grundlegenden Mechnismen ändern. Folgen: Siehe Punkt 1.

    3. Außerdem sprechen auch sprachphilosophische Gründe dagegen: C++ ist eine abstrakte aber maschinennahe Sprache. Man kann ganz tolle Strukturen aufbauen, aber man hat dabei die volle Kontrolle über alles. Eine GC würde eine unkontrollierbare Zwischenschicht einführen. Das Anwendungsgebiet der Sprache würde sich dadurch komplett verlagern und es würde eher Richtung Java gehen. Dafür gäbe es dann aber keine abstrakte maschinennahe Sprache mehr.

    4. Ein etwas schwacher Punkt: Man braucht sie nicht. Mit den vorhandenen Sprachmechanismen ist es relativ einfach auch ohne GC auszukommen ohne nennenswerte Nachteile. Und falls man doch eine braucht, kann man sich auch trotzdem eine GC selber programmieren.



  • SeppJ schrieb:

    ...Und falls man doch eine braucht, kann man sich auch trotzdem eine GC selber programmieren.

    ... oder gleich java nehmen. 😉

    Soll kein C++-Bashing sein - ich bin nur ein großer Freund von "das richtige Werkzeug für die Aufgabe". Man fragt ja auch nicht, wann denn endlich in die Bohrmaschine eine Beilschneide eingebaut wird. 😉

    Gruß,

    Simon2.



  • SeppJ schrieb:

    Baracke_out schrieb:

    Wichtig ist mir das nicht, war nur ne frage die mir im Kopf rumgeschwirrt ist und raus wollte. Und eigentlich ist 1 oder was auch immer unnoetig, blaeht nur denn Code auf.

    Aber warum in C++ keine Garbage Collection einfuehren kann ist mir nicht klar.

    1. Weil dann Code wie der hier gezeigt nicht mehr funktionieren würde. Und solche oder ähnliche Tricks werden recht oft benutzt. Und wenn man durch eine Erweiterung der Sprache allen Code der bisher existierte ksputt macht, dann macht man die Sprache kaputt. Das ist der Grund warum man keine GC einführen kann.

    2. Außerdem läuft bei Sprachen mit GC die Objekterzeugung und Vernichtung völlig anders. Man müsste die ganze Syntax der Sprache und die grundlegenden Mechnismen ändern. Folgen: Siehe Punkt 1.

    3. Außerdem sprechen auch sprachphilosophische Gründe dagegen: C++ ist eine abstrakte aber maschinennahe Sprache. Man kann ganz tolle Strukturen aufbauen, aber man hat dabei die volle Kontrolle über alles. Eine GC würde eine unkontrollierbare Zwischenschicht einführen. Das Anwendungsgebiet der Sprache würde sich dadurch komplett verlagern und es würde eher Richtung Java gehen. Dafür gäbe es dann aber keine abstrakte maschinennahe Sprache mehr.

    4. Ein etwas schwacher Punkt: Man braucht sie nicht. Mit den vorhandenen Sprachmechanismen ist es relativ einfach auch ohne GC auszukommen ohne nennenswerte Nachteile. Und falls man doch eine braucht, kann man sich auch trotzdem eine GC selber programmieren.

    👍


Anmelden zum Antworten