Wenn man sich was wünschen dürfte...

[Bernhard Geyer]

Zitat von Pfaffe:

Wenn ein Kind seinen ersten (1) Geburtstag feiert, dann ist ein Jahr rum, das Leben fängt also bei 0 an.

Und wenn ich jetzt mir eine Auswahl zwischen zwei Äpfel gibt sag ich dann auch ich will den 0ten Apfel

[Hansa]

Da hat Bernhard auch Recht. Aber : es gibt ein Binärsystem. Um 256 Zahlen darzustellen komme ich mit einem Byte aus, aber nur, sofern ich die 0 mitnehme.

[stahli]

Zitat von Hansa:

Da hat Bernhard auch Recht. Aber : es gibt ein Binärsystem. Um 256 Zahlen darzustellen komme ich mit einem Byte aus, aber nur, sofern ich die 0 mitnehme.

Speicherbezogen hast Du Recht.
Wenn Du 256 Einträge in einer Liste speichern willst ist das erste natürlich auch am Speicherplatz[0] zu finden.

Aber das heißt ja nicht, dass eine Hochsprache dafür nicht die 1 vorsehen könnte.
Der tatsächliche Zugriff muss dann natürlich auf die Speicherstelle[0] erfolgen.

Statt for I := 0 to 255 schreibst Du dann halt for I := 1 to 256 .
Unterm Strich ändert sich nichts, weil der Maschinencode dann gleich aussieht.

Die einzige Frage ist, was für den Menschen das logischere ist. Offenbar gehen die Meinungen da auseinander.
Technische Überlegungen wie Binärsystem ab 0 sind aber m.E. kein wirkliches Argument für Listenzähler.


Label.Text := 'Text' ist ja auch nichts, was irgendeinen natürlichen Bedzug zum Speicheraufbau hat. Die Entwicklungsumgebung gaukelt uns das nur vor. Hier sagt ja auch niemand: Im Speicher gibt es keine Labels, deshalb sind die nicht sinnvoll.

[samso]

Da es ja um quasi philosophische Überlegungen geht:

Offensichtlich hängt doch der sinnvolle Index von den Daten ab, die verwaltet werden. Wenn ich ein array von Farbintensitäten haben, formulieren ich irgendetwas wieFarbwerte: array [Farben] of Integer . Nicht umsonst wurde die Wahl des Index bei statischen Arrays dem Programmierer überlassen. Den Rest hat der Compiler erledigt. Bei den dynamischen Arrays wollte man sich diesen Aufwand sparen und hat sie schlicht als 0-Basiert definiert. Aus meiner Sicht wäre es konsequent gewesen, wenn man den Basiswert auch bei dynamischen Arrays umgesetzt hätte.

Wäre es nicht eigentlich viel besser, gleich auf arrays zu verzichten und diese statt dessen als Listen-Objekte zu implementieren? Und brauche ich dann Strings (AnsiStrings sind ja eh schon gestorben)? Sollte nicht einfach alles ein Objekt sein?

[Perlsau]

Zitat von Hansa:

Aber : es gibt ein Binärsystem. Um 256 Zahlen darzustellen komme ich mit einem Byte aus, aber nur, sofern ich die 0 mitnehme.

... und genau deshalb wird in Programmiersprachen in der Regel ab 0 indexiert ...

[schöni]

Mit Nullbasierten Listen habe ich kein Problem. @Sir Rufo erlärt das gut mit dem Geburtsproblem.

Wenn ich auf dem Bildschirm die X;Y Position adressieren will, mache ich das oft mit:

Line := Abslute_Position div XResolution;
Column := Abslute_Position mod XResolution;

Das klappt aber nur, wenn das erste Pixel des Bildschirmes an Position NULL liegt.

Jemans schrieb, das ein Byte 256 Werte annehmen kann, was nur geht, wenn die NULL berücksichtigt wird.

Zitat von Luckie:

Ich war glücklich, wenn sie das "Haus des Nikolaus" gezeichnet hat.

Das ist die kindgerechte Form des Salaesman Problems. Jeder Weg soll öglichst nur einmal gegangen werden.


Ich wüchsche mir vielmehr einen Compiler, der die Initialisierung und Freigabe der verwendeten Objekte automatisiert. Ich habe sehr oft EAccessViolations. Weil wohl irgendein Objekt nicht korrekt erzeigt worden ist. Dann geht die frustrierende Fehlersuche los.

Die Prozessoeren werden immer leistungsfähiger, da könnte doch der Compiler Konstruktorcode und Destruktorcode automatisch einfügen.

Für Abwärtskompatibilität könnte der im Quellcode formulierte Konstruktor und Destruktor noch zugelassen werden, fehlt das jedoch in der Klassendefinition muss der Compiler den passenden Code dafür erzeugen.

[jfheins]

Zitat:

Die Prozessoren werden immer leistungsfähiger, da könnte doch der Compiler Konstruktorcode und Destruktorcode automatisch einfügen.

Das ist in der Tat ein (in meinen Augen) wichtiger Punkt. Konstruktoren zu automatisieren finde ich unglücklich, weil dadurch wieder schwer zu findende Fehler passieren. Destruktoren finde ich inzwischen überflüssig/nervig.

Viele Sprachen (gerade junge) gehen ja stark in die Richtung. C# und Java machen es ja vor, da gibt es einen Garbage Collector. In Rust prüft (meines Wissens) der Compiler statisch (also beim compilieren) ob es sein könnte, dass du auf ein freigegebenes Objekt zugreift. Falls das sein kann, compiliert das Programm nicht.

Manche beschweren sich, dass moderne Programme immer mehr Bloatware sind, aber zu einem Teil ist das einfach nur ein Tradeoff von "Entwicklerzeit/kosten" gegen Laufzeitperformance/Größe. Und bei modernen CPUs finde ich, darf man den Kompromiss auch graduell Richtung Reduktion der Entwicklungszeit steuern.

Leider ist es sehr schwierig, eine Sprache, die von jeher auf manuelle Speicherverwaltung setzt, auf automatische Speicherverwaltung zu ändern. Sieht man ja bei C++ und den neuen Smart Pointern: http://stackoverflow.com/questions/5...oost-explained

[Luckie]

Garbage Collector. Ein Garage Collector wäre ein Autowerkstatt Sammler.

[jfheins]

Zitat von Luckie:

Garbage Collector. Ein Garage Collector wäre ein Autowerkstatt Sammler.

Ach verdammt Mit der Rechtschreibprüfung im Browser wird man echt dazu verleitet, nur noch die rot unterstrichenen Sachen zu überprüfen.

[Hansa]

Zitat von jfheins:

..dass moderne Programme immer mehr Bloatware sind, aber zu einem Teil ist das einfach nur ein Tradeoff von ,,,

Da wird über Computersprachen diskutiert, ist ja auch richtig, aber erkläre mir mal (auf deutsch), was Bloatware ist, oder Tradeoff. Das ist (keine Angst : 9 Jahre Englisch dürften reichen) so nicht verständlich, nicht mal im Zusammenhang. Wenn in einem Team in solch einem Stil kommuniziert wird, tja, dann gute Nacht. Starke Erhöhung der Entwicklungszeit. Da ist man ja mehr damit beschäftigt, zu überlegen, was einer meint oder wälzt womöglich noch Wörterbücher. Es gibt eingedeutschtes. Ich sage auch gelegentlich "Klicke mal den geschickten Link an". Link ist schon kürzer als z.B. "Daten-Fernübertragungs-Darstellungs-Zugriffspunkt". In Deutsch neue halb-englische Wortschöpfungen zu erfinden, das ist imho allerdings wirklich überflüssig. "Handy" lässt grüssen, das versteht nicht mal ein Amerikaner.