nicht angemeldet
Hallo CK,
Dafür sind viele Dinge in C katastrophal gelöst.
Und viele Dinge sind in Pascal so gar nicht möglich.
Das musst Du mir mal näher erklären. Beide sind Turing-complete. Was soll also in C möglich sein was in Pascal nicht möglich ist?
Mag sein das in einer Sprache einige Dinge etwas umständlicher sind als in der anderen. Aber eine Unmöglichkeit folgt daraus nicht.
Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.
Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.
Ja ich kann und MUSS es selber tun. Für mich ein Rückschritt ohne Zwang. Wenn es danach geht können wir ALLES selber tun und uns in die Assemblerprogrammierung zurückziehen.
Programmiersprachen sollen dem Programmierer das Leben erleichtern. Und da finde ich es nicht besonders clever, wenn etwas Bestehendes wieder wegrationalisiert wird.
In Pascal kann ich sagen Array[5..15] usw.
Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.
Ohne vernüftige Begründung bleibt das eine Aussage auf dem Niveau wie "Windows ist für DAUs und Linux für Profis".
falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Das ist bei C genau so:
char array[100];
Fängt bei 0 an, hört bei 99 auf.
Was ich meinte (so schrieb ich es auch), dass es eben beim hinschauen nicht klar ist weil es nur implizit ist und nicht explizit. Die Lesbarkeit leidet darunter.
Und in der Praxis ist es nicht immer so, daß es sinnvoll ist die Zählung mit 0 zu beginnen. Da muss man dann wieder umrechnen usw. ein Aufwand, den man sich eigentlich sparen könnte.
Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.
Irgendwie sehe ich nicht den rechten Sinn in dieser Trennerei (wegen der Übersichtlichkeit dafür gibts moderne IDEs). Allenfalls das besch* Konzept von C macht dies manchmal notwendig (ohne dabei irgendein Benefit zu liefern).
BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.
Das ist allerdings richtig. Nur nützt mir das wenig, wenn ich vorhandenen Code übernehmen muss. Weil landläufig wird diese Trennung vorgenommen.
C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.
Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.
Stimmt. Das war zumindest unter Turbo Pascal so. Das ist keine Schwäche der Sprache generell, sondern der Implementierung. Ich weiß gar nicht, ob dass in den modernen Pascaldialekten noch der Fall ist. Weil es macht keinen Sinn mehr angesichts des heute verfügbaren RAMs.
Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen
Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.
Falsch. Zumindest die Implementierung in Turbo Pascal war es so, daß die Länge am Anfang des Strings gespeichert wurde.
(was auch nicht gerade positiv für die Perforamce ist).
Zähle halt mit.
Brauch ich ja wieder eine extra Variable. Wofür? Wo es mir doch andere Sprachen wesentlich einfacher machen.
Mengen und Bereiche fehlen gänzlich in C.
Ich kann nicht einfach mal sagen
if ch in ['ä','ö','ü','ß','Ä','Ö','Ü'] usw.
sondern muss immer
if (ch=='ä' || ch=='ö' || ch=='ü' || ch=='ß' || ch=='Ä' || ch=='Ö' || ch=='Ü')
Das soll übersichtlicher sein?Dafür gibt es switch().
switch(ch) {
case 'ä':
case 'ö':
case 'ü':
case 'ß':
case 'Ä':
case 'Ö':
case 'Ü':
tu_was();
break;
}
Sorry. Aber das ist ja noch länger. *kopfschüttel*
Das fehlen von Bereichen macht Programme fehleranfällig.
Das ist nun wirklich aus der Luft gegriffen.
Wieso? Ein konkretes Beispiel habe ich gleich mitangegeben:
In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
In C müsste ich ein int nehmen und müsste sämtliche Bereichsüberprüfungen von Hand machen. Zu Assemblerzeiten war das ja noch akzeptabel. Heutzutage will ich schlanken, lesbaren und fehlerunanfälligen Code haben.
Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2; // funktioniert auch!!!
Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di
Doch. Der C-Compiler vergibt implizit Nummern sofern nicht eine eigene angegeben ist. Für C sind enums nichts weiter als int-Werte und die möglichen Werte nichts anderes als int-Konstanten.
Und sowas ist für mich kein Aufzählungstyp sondern ... na ich weiß nicht was. Das selbe gibt ja auch für ein praktisch nicht vorhandenes Boolean.
auswählt. Wenn du sichergehen willst, dass Di mit zwei indiziert wird, musst du die
Definition wie folgt ändern:
[Quelltext]
Toll. Nur das es überhaupt nicht das ist, was ich haben will.
Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.
Ich beklage mich auch nur darüber, daß C einem es unnötig(!) schwer macht.
Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C.
Schon die Strenge Typisierung in Pascal vermeidet viele Probleme (das ist auch der Grund, warum man das in Java wieder eingeführt hat).
Dadurch werden viele Fehler abgefangen, die sonst erst zur Laufzeit auftreten.
Diverse implizite Checks tragen ebenfalls dazu bei.
Die weitaus meisten Fehler (und damit Sicherheitslücken) die in Programmen auftreten liegen nicht nur daran, daß C so verbreitet ist sondern an den teilweise kaputten Konzept. Andere Sprachen haben solche Probleme prinzipbedingt nicht.
Man lädt sich mit C einfach eine Menge Balast auf der in meinen Augen gar nicht notwendig ist.
Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.
Pointer brauche ich immer, wenn ich mit Arrays dynamischer Größe (also praktisch Listen) arbeite.
Aber üblicherweise implementiert man sowas einmal (falls nicht sogar schon in einer Bibliothek vorhanden) und verwendet es dann nur noch. Das ist in der Tat bei beiden Sprachen gleich gut/schlecht. So richtig komfortabel wird das dann erst, wenn man die in der OOP üblichen Collections verwendet.
Gruß
MichaelB