Warum faengt das Array bei 0 an?

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.

knivil

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.

volkard

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.

Fellhuhn

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

wxSkip

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.

SeppJ

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.

Simon2

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.

theliquidwave

Wenn du einen GC willst, empfehle ich dir D.

Gruß

wxSkip

unmöglich schrieb:

: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.

1. C++/CLI gibt es schon.
2. hatte das ISO-Kommitee schon bei C++0x vor, die Garbage Collection optional einzuführen, hat es aber dann doch verschoben.

Nexus

Ich kann SeppJ vollkommen zustimmen. Ein Garbage Collector passt meiner Meinung nach weder konzeptionell noch technisch zu C++. Er ist zwar ein wertvolles Werkzeug in anderen Sprachen, aber in C++ habe ich ihn nie vermisst.
:hoppschwiiz: :hoppschwiiz: :hoppschwiiz:

volkard

Nexus schrieb:

Ich kann SeppJ vollkommen zustimmen. Ein Garbage Collector passt meiner Meinung nach weder konzeptionell noch technisch zu C++.

Naja, technisch vielleicht schon. Aber nicht in der Art wie in Java. Sondern nur als Memory-Collector. Soll heißen, daß man sehr wohl Destruktoren für das supi wertvolle RAII benutzt, aber Speicher vom GC aufräumen läßt. Soll heißen, daß man ihn einfach fallen läßt, außer ein Kind hat was Nichtspeicheriges, dann wird nur dieses Kind halt noch umgebracht. Könnte vielleicht ein paar Locks vermeiden und bei 12 Kernen überlegen viele Leute schon viel rum, Locks zu vermeiden als Standardrundumallheilmittel.
Naja, noch brauche ich es nicht, denn ich habe entdeckt, daß bei mir entweder die Speicherbesorgung supi wenig Prozent der Gesamtlast ausmacht, oder bei meinem lustigen neverending Webserverplan, daß threadlokale Allokatoren, die man std::-containern ja frei unterschieben kann, das Mittel der Wahl sind.
Ich hatte mal einen Simulator gebaut, wo verflixt viele Objekte sich freispeicherallkokierte Nachrichten geschickt hatten, und bei 10Mio Nachrichten pro Sekunde war new/delete schon ein Happen. Damals nur ein Kern. Konnte ich auf 70-mal so schnell wie new bringen. Aber mit 12 Kernen würde es ein reines Rumgewarte werden. Und zwar egal, wie ich die SmartPointers anlege, refcountig, Ring, pagetagging, naja, vielleicht geht es, nur weiß ich nicht, wie. Aber dann wissen es auch genügend viele Leute nicht, und viele, die sowas bauen, wünschen sich für C++ einen für diese eine Projektsorte zuschaltbaren GC.
Damals gab es noch kein C#. Vielleicht wäre es besser, sowas in C# zu machen. Nee, auch nicht. Es brauchte auch high speed in Array-Zweckentfremdung und humeoresken Operator-Überladungen.
D?