Warum gibt es so viele Programmiersprachen – Teil 2
Eine ganze Menge Programmiersprachen entstanden, weil man sie nur in einer bestimmten Softwareumgebung braucht. Die ersten Programmiersprachen waren zum einen kompiliert, erzeugten also Maschinencode. Zum anderen waren sie für die Entwicklung von Stand-Alone Anwendungen gedacht. Mit einem zweiten Konzept, des Interpreters konnte man dagegen eine Programmiersprache in jedes Programm einbauen. Bei einem Interpreter wird der Quelltext on the fly übersetzt und daher gibt es hier auch die Möglichkeit Funktionen eines Systems aufzurufen in das die Programmiersprache eingebettet ist. Ein Großteil der Scriptsprachen entfällt in diese Kategorie wie die ganzen Shell-Scripts, aber auch in komplexer Software integrierte Sprachen wie die in Matlab oder R in Statistikpaketen.
R ist auch inzwischen eine eigenständige Programmiersprache gehört aber zu den „Special Purpose“ Sprachen. Während Sprachen wie Pascal, C oder Java den Anspruch haben sich für eine breite Anwendung zu eignen. wenn auch nicht für jede gleich gut, ist eine Special Purpose Sprache eine die bestimmte Feature hat die man nur für bestimmte Anwendungen braucht, dann sind sie aber sehr nützlich. R hat z.B. als elementaren Datentyp das Array nicht Skalare. Sinnvoll wenn man Statistik betreibt also große Datenmengen auswertet. Bei Pearl hat man eine Skriptsprache rund um die regulären Ausdrücke herum gebaut. APL ist eine Sprache für Mathematiker die nicht mal in einer Programmiersprache von ihren geliebten Symbolen lassen wollen. Alle drei – wen verwundert es – sind interpretiert.
Eine andere Intention für eine neue Sprache sind veränderte Anforderungen. Mit dem Auftauchen des Internets kommunizierten plötzlich Computer auf der ganzen Welt miteinander. Vorher tauschte man Daten aus oder hatte statische Informationen in HTML. Doch wie realisiere ich eine Anwendung die auf dem Zielcomputer Daten eines Servers braucht oder interaktiv ist, ohne das der Anwender jedes Mal eine Anwendung installiert und damit sie auf jedem Rechner läuft und nicht nur auf dem PC unter Windows. Es entstanden mindestens drei Ansätze dieses Problem zu lösen. PHP ist eine Scriptsprache die man in HTML einbetten und mixen kann. Die Ausgabe erscheint dann da wo der PHP Quelltext im HTML steht. Zur Ausführung braucht man ein Modul auf dem Server, der also die ganze Arbeit hat (ein Grund warum der Blog deutlich langsamer als die Webseite ist). Javascript macht das gleiche nur im Browser, verlagert also die Arbeit auf die Clients was eigentlich besser ist, doch dafür muss der Browser auch die Sprachfeatures verstehen was in der Anfangszeit problematisch war, weil Microsoft und Netscape jeweils ihre eigenen Süppchen kochten. Java entwickelt als vollwertige Programmiersprache für Anwendungen die vom Microcontroller bis zum Großrechner alles abdecken sollte, erlaubte es die Arbeit aufzuteilen – sie konnte vollständig auf dem Client laufen, auf dem Server oder verteilt. Das Konzept hat sich nicht durchgesetzt. Java erweis sich als zu viel Speicher verbrauchend, zu langsam und obwohl als da in einer eigenen virtuellen Umgebung ablaufend, als sicher angepriesen, gilt Java neben Adobe Produkten heute als ein Einfallstor für Schadsoftware,.
Java führt mich zur letzten Gruppe: Den Firmenstandards. Denn als Microsoft seine selbst veränderte Java-Engine aufgrund eines Prozesses von Sun nicht mehr ausliefern dürfte entwickelten sie einfach ihren Java-Clone – nur ein bisschen besser: C#. Es ist nicht der erste Firmenstandard. Microsoft hatte auch BASIC für Microcomputer adaptiert. Das Microsoft-BASIC wurde zum Standard, mit der Folge das jeder diese fürchterliche Implementation mit dem Spagetti Code für BASIC hielt – dagegen wehrten sich die Erfinder von BASIC erfolglos. Google musste als Folge natürlich auch eine eigene Sprache kreieren, nämlich Go. Firmenstandards haben Vor- und Nachteile. Der Vorteil ist, das eine Firma eine Sprache schneller weiter entwickeln kann, als wenn man immer mit einem Gremium alles abstimmen muss. Paradebeispiele sind die Entwicklung von BASIC durch Microsoft oder Pascal durch Borland. Der andere ist, dass man nun natürlich auch auf Produkte dieser Firma angewiesen ist.
In der Summe wird es wohl immer mehr Programmiersprachen geben. Auch weil immer neue Konzepte auftauchen. In den Sechzigern war es die Strukturierte Programmierung und die Typisierung von Daten, in den Siebzigern die Objektorientierung, die es enorm erleichterte, Code wieder zu verwenden und Probleme zu abstrahieren. Schon hier gab es aber den Bruch: erfolgreich wurden nicht Sprechen die vollständig objektorientiert waren wie Smalltalk, sondern Sprachen die Objektorientierung mit dem vorigen Modell verheiraten wie C++. (Ob dies angesichts der Fehler von C so sinnvoll ist sei mal bezweifelt).
Doch nicht immer braucht man alles, weshalb Dinosaurier wie FORTRAN noch heute eingesetzt werden, auch weil man bestehende Programme zwar erweitert, aber selten in eine neue Sprache umschreibt. Vor allem kann es auch nicht „die Sprache“ geben, schon alleine weil es zu viele grundlegende Konzepte gibt. Es gibt mindestens drei unterschiedliche Ansätze:
- prozedurale sprachen: Der von meisten am schnellsten verstandenen Ansatz bei dem man die Anweisungen angibt die nacheinander ausgeführt werden. Die meisten Programmiersprachen fallen in diese Kategorie.
- regelbasiette Sprachen: Man definiert nicht dem Algorithmus komplett, sondern Daten, Beziehungen und Regeln die man kennt und der Computer ermittelt die Lösung auf Basis der bekannten Daten und Regeln. Sie waren im Bereich der KI sehr erfolgreich.
- Funktionale Sprachen haben den Ansatz der Mathematik, das Funktionen die Eingangsdaten in die Ausgangsdaten transformieren. Im strengen Sinne kennen diese Sprachen dann keine Blockstrukturen und Wiederholungsstrukturen mehr.
- Manche definieren Sprachen wie SQL als eine weitere Kategorie. Hier gibt man an wie man Daten erhalten will, nicht jedoch wie dies geschehen muss.
Je nachdem welche Problemstellung man hat, wird eine der Gruppen besser geeignet oder schlechter geeignet sein. So wird es auch in Zukunft immer mehr Sprachen geben. ich muss auch sagen ich will nicht die Programmiersprache die alles kann, denn dann wird sie auch unhandlich und schwerfällig. Man kann in Maßen Funktionalität in Bibliotheken auslagern aber wenn eine Sprache schon in den Kernfeatures viel können muss, ist auch der Kern entsprechend groß. Darüber hinaus gibt es natürlich noch die technischen Grundgegebenheiten, Java hat diesen Spagat versucht, vom Microcontroller bis zum Server auf allen Systemen zu laufen, ob im Browser oder als Standalone Anwendung und ist daran gescheitert
Ein Beispiel für eine Sprache die alles können sollte war PL/1. Aus praktischen Gründen (Speicherplatz) wurde allerdings öfter nicht der gesamte Sprachumfang implementiert. Damit wurde es vergleichbar mit anderen Sprachen, nur umständlicher.
Cobol ist ein Beispiel für eine Sprache, die längst nicht mehr wirklich gebraucht wird. Seit Jahrzehnten machen relationale Datenbanken das Gleiche, nur viel einfacher und mit einem Bruchteil des Programmieraufwandes. Das ist wohl der Hauptgrund für das sture Festhalten an Cobol. Welcher Programmierer sägt schon an dem Ast auf dem er sitzt. Und natürlich das alte Prinzip „was der Bauer nicht kennt frißt er nicht.“
Falls man hier auch ueber unbekannte Sprachen sprechen darf, wahrscheinlich meine „Lieblingssprache“ im Bereich „universeller“ interpretierter Programmiersprachen ist CoffeeScript. Wird nach JavaScript transkompiliert, ist also mit allen Programmen/Umgebungen kompatibel, die JavaScript ausfuehren koennen (und das sind inzwischen wirklich sehr viele). Wirft viele Altlasten und Unannehmlichkeiten von JavaScript ueber Bord und hat eine unglaublich elegante Syntax. Einfach mal Googlen 🙂
Für die Hardcore Leute gibt es natürlich auch esoterischen Programmiersprachen:
http://de.wikipedia.org/wiki/Esoterische_Programmiersprache
Das meiste davon ist um irgendwelche Konzepte auszuprobieren und nicht so richtig brauchbar.
Esoterische Programmiersprachen? – Oh ja, Brainf***!
Hab mich damit zwar noch nicht wirklich beschäftigt, aber das Konzept an Sich ist einfach nur abgefahrn.
Ansonsten: eine nette Serie! – Mal sehen, ob ich dazu noch was ausführlicheres schreibe…
Nur das Gute Alte Forth hat noch niemand erwähnt. Dabei heißt es doch so schön:
Forth love if honk then
honk honk
Forth, ja… – hab ich auch schon von gehört, – aber noch nie benutzt, bzw. noch nie gebraucht.
Mich interessiert ja eher noch, ob es sich lohnt, sich intensiver mit Ada zu befassen, aber bisher hat mir hier dazu noch keiner was geschrieben, obwohl ich die Frage hier auch schon mal gestellt habe.
Das ganze u.a. deswegen, weil C für Sicherheitskritische Embbeded Systems ja nun nicht wirklich optimal ist, bzw. die Entwicklung recht teuer werden kann. Dazu gibt es u.a. ja zwar diesen MISRA-C Standard, der aber auch nicht unumstritten ist, wie man bei Heise-Developer nachlesen kann. Aber besser wäre es, eine Sprache zu verwenden, die u.a. für solche Systeme entworfen wurde. Dazu gehört Ada, die aber nun wieder den Haken hat, dass sie mal vom US-Militär in Auftrag gegeben wurde und auch hauptsächlich dort benutzt wird, was einge Leute als störend empfinden könnten.
Forth hatte seine große Zeit in den frühen Achtzigern, es ist sehr kompakt, damals noch kompakter als BASIC, der Dreh und Angelpunkt der Sprache ist der Stack.
Ich selber sehe es mit Programmiersprachen recht pragmatisch: ich nehme die mit der ich am besten auskenne für das Projekt wo sie am besten reinpasst. Das ist meist Delphi, auch weil ich meist Windows Anwendungen mache. Wenn ich irgendwo eine Verbindung zu einem externen Programm machen muss das eine C-Api hat nehme ich C und wenn es was mit Internet sein soll Javscscript oder Java.
Es gibt den Ansatz man sollte jedes Jahr eine neue Sprache lernen um neue Ansätze zu verstehen. Ich halte nichts davon den meiner Meinung nach braucht man Jahre bis man in einer Programmiersprache wirklich gut ist. Man kann, wenn man sich nach Feierabend mit einer anderen Sprache beschäftigt zwar was dazulernen, doch man wird diese kaum produktiv umsetzen, weil man dann in der Geschwindigkeit stark zurückfällt. Alleine bis man die Syntax wirklich verstanden hat und auch nur mal die wichtigsten Routinen auswendig kennt, die man braucht vergehen Monate.
Ich halte aus dem Grund auch nicht viel davon Anfängern eine spezielle Lernsprache oder Nischensprache zu empfehlen. Denn irgendwann wollen sie ein eigenes Programm schreiben und vielleicht an andere weitergeben, die nicht dann erst den Interpreter XYZ installieren wollen.
Forth ist schon Anfang der 70er Jahre eingesetzt worden, z.B. von Radioastronomen zum Nachführen der Antennen. Ist halt die kleinste Sprache nach Assembler.
Ada ist Mitte der 80er Jahre ein bischen in Mode gekommen. Es gab aber mehrere Probleme:
a) technisch
– technisch war nichts neues dran, es wäre eine Ablösung von Pascal und Modula2 gewesen.
– der Sprachumfang ist in den 80ern schon sehr groß geworden, das ganze Ada System passte so gerade eben auf die Rechner. Die einzige vollständige Algol 68 Implementierung (FLACC) war kleiner, und brauchte eine IBM 370.
Für Ada brauchte man mindestens eine mc68020 Workstation (single User) oder eine VAX 11/780. (zu einem Zeitraum als auf diesen Systemen üblicherweise >10 User gleichzeitig gearbeitet haben.)
Die frühen Ada Systeme waren instabil, und der Debugger konnte z.B. eine VAX komplett aufhängen.
– die minimale Programmgröße für ein Ada Programm war für damalige Verhältnisse groß.
– Einige Ada Systeme wurden in den Unis (z.B. Braunschweig) als Beta Systeme gekauft, und wurden nie unter Ada produktiv. (Der Lieferant hatte den Aufwand für die Ada Implementierung überschätzt. Man kann sich nicht auf die libc abstützen, sondern muß alles neu schreiben.)
b) politisch
– Ada ist in den 1980ern immer als (Programmier-)Sprache des Militärs angesehen worden.
– Damit war es insbesondere für einen Teil der Studenten und Universitätsmitarbeiter, die unter dem Eindruck des NATO-Doppelbeschluss standen nicht akzeptabel.
c) usability
– Ich habe in den 1990ern an einem Software Projekt mit >100 Mitarbeitern geholfen. Auf Grund der Größe des Projektes wäre Ada anstelle von C hilfreich gewesen.
– Ada alleine wäre aber nicht ausreichend gewesen, unser Problem lag vor allem im Projektmanagement.
@Andreas Buschmann: Danke für die Auskünfte.
Von der technischen Seite scheint das zwar nicht mehr so ganz aktuell zu sein, dafür aber noch von der politischen. Damit wird man aber wohl leben müssen.
Und von Problemen beim Projektmanagement liesst man ja immer mal wieder. Ich kenn mich da zwar nicht aus, aber nach meinem subjektiven Eindruck scheinen die Probleme immer umgekehrt proportional zum technischen Sachverstand der Manager zu wachsen. Also Sprich: Um so weniger Ahnung die Manager von der Technik haben um so grösser werden die Probleme. Aber das ist ein anderes Thema.
Mal sehen, ob noch jemand was zu Ada zu berichten hat.
Es gibt ja freie ADA Compiler die man mal probieren kann. GNAT dürfte der bekannteste sein, steht unter der GPL, da musst Du also keinen Einfluss des Militärs befürchten.
ADA wurde entwickelt um die Steelman Anforderungen zu genügen. Das war eine Featureliste was eine vernünftige Sprache (für das Militär) können müsste und liest man sich die durch so stehen da schon vernünftige Dinge drin. Interessanterweise kommen selbst halbwegs aktuelle Implementierungen von C,C und Java da nicht an ADA heran:
http://www.adahome.com/History/Steelman/steeltab.htm
Klar war die Liste eine Art Requirement für ADA, aber es ist ja bei Programmiersprachen üblich dass man Dinge die in einer Sprache gut sind in andere übernimmt. Seltsam das da die C-ähblichen Sprachen noch so schlecht abschneiden.
Ada wurde (und wird) nicht nur beim Militär, sondern auch in der Raumfahrt eingesetzt. Ob man es dort auch liebt ist allerdings eine andere Frage…
und um Anjas und Andreas Beitrag zu verbinden: Der Ariane 5 Jungfernflug ging (unter anderem) auch schief, weil einem in ADA programmierten Modul aus Performancegründen nur zwei von sieben variablen gegen eine Exception durch einen Überlauf abgesichert waren. Bei den anderen hielt man es wegen physikalischer oder Flugregimegründen nicht für nötig. Als man die Software von der Ariane 4 unverändert auf die 5 übernahm änderte sich jedoch das Flugregime (höhere horizontale Beschleunigung) und es gab einen Überlauf, der dann zum Abschalten des entsprechenden Moduls führte
Und da sieht man mal wieder, dass man in jeder Sprache Millionenschäden verursachen kann, wenn man sie falsch benutzt. Das ist zugegebenermaßen in C wesentlich einfacher als in den meisten anderen Sprachen.
Der Sprachenvergleich bzgl. der Steelman-Liste ist aber nun wirklich nicht mehr aktuell (C Plusplus Stand von Anfang bis Mitte der 90er). C Plusplus hat seitdem zwei neue Standards gesehen und würde mittlerweile bei 70-80% landen. Das grösste Problem sind halt immer noch die C-Altlasten.
Zu Java kann ich nicht viel sagen, aber ich denke auch das hat sich seitdem noch ganz gut weiterentwickelt.
Die Ariane 501 Problematik ist aber prinzipiell erstmal unabhängig von der verwendeten Programmiersprache. Falscher Ansatz von „reuse“ ist da schon eher die richtige Fehlerursache.
@Arne: Die C Altlasten sorgen dafür das Cpp nicht viel weiter kommen wird. Ich wüsste nicht was da in den beiden letzten Standards an Steelman Forderungen hinzugekommen wäre. Denn diese beziehen sich weniger auf tolle Programmiertechniken, die es erst seit einigen Jahren gibt, als vielmehr Basics wie Verständlichkeit, Typensicherheit, Wartungsfreundlichkeit.
@anja stimmt prinzipiell, aber C hätte z.B. gar keinen Exception Mechanismus mit dem man so einen Überlauf erkennen könnte, da müsste man schon eine eigene Bibliothek programmieren. Hätte man die Sprachmöglichkeiten ausgenutzt und auf die Exception angemessen reagiert, so wäre die Mission vielleicht erfolgreich gewesen. Vielleicht, weil man bei der Untersuchung noch einige andere Fehler feststellte, so wurden die Diagnosedaten des Fehlers für Navigationswerte interpretiert, was erst zum abrupten Kursschwenk führte.
Also was den Ariane 5 Fehler angeht, so würde ich da auch sagen, dass da u.a. Schlampigkeit in der Codeübernahme, oder wie Anja sich ausdrückt, ein falscher Ansatz von „reuse“ dahinter steckte.
Was C angeht: Da die Sprache keinen Exception-Mechanismus hat, wird man Überläufe da natürlich anders prüfen müssen, als mit einem solchen. Aber das sollte nach meiner höchst subjektiven Ansicht bei einem Projekt wie der Ariane dann auch niemanden daran hindern, eine entsprechende Bibliothek zur Fehlerbehandlung zu entwickeln, wenn man die Steuersoftware in C schreiben will. Im Gegenteil meine ich, dass sowas dann sogar ins Pflichtenheft gehört.
… nur würde das keiner machen, wenn es eine Sprache gibt mit der man solche Fehler erkennen kann (eine der Steelman Forderungen) und stattdessen eine Sprache nehmen die die nicht mal die versehentliche Verwendung eines = anstatt einem == in if abfängt ….
Glücklicherweise werden auch die Compiler immer besser und warnen vor bekannten Fallen wie der Verwechslung von = und ==.
Was in CPP bzgl. der Steelman-Forderungen hinzugekommen ist, ist hauptsächlich Teil 9, Parallel Processing. Dazu kommen Exceptions und einige Array-Operationen, die mit Typen aus der Standardbibliothek machbar sind, inklusive Bereichsprüfungen. Auch die C-Strings haben längst einen sicheren Ersatz.
Das Problem ist halt, dass man diese ganzen schönen Dinge nicht benutzen muss. Man kann weiterhin 70er Jahre C Stil schreiben, wenn man denn so blöd sein will. Und das wollen auch heutzutage noch viel zu viele Entwickler. Eine geeignete Sprache für so sicherheitskritische Bereiche wie Raumfahrt wird CPP deshalb auch nie werden, da muss ich Dir recht geben.
Also wenn man Sprachen vergleicht dann immer der Kern, denn die Bibliotheken kann man austauschen, was viele nicht kapieren und dann ihre Implementierung mit Softwareprodukt xyz als Referenz nehmen. Genauso zählen Compilerwarnings nicht dazu, wenn die Sprache die Verwendung von = in if erlaubt, dann ist die Sache damit klar, auch heute die meisten Compiler in Standardeinstellung das als Fehler sehen.
Diese abwärtskompatibilität ist wie ich schrieb auch ein Grund warum alte Sprachen noch eingesetzt werden. Sie ist aber meist von Nachteil weil man es heute besser weiss. Es gibt es bessere Implemtierungen von Strings als die in C. Sehr übel ist dann wenn man wie in CPP den C Standard nur erweitert anstatt wie in Java gleich alles abzuschaffen was sich als schlecht erwies nur um C-Programmier zu ködern – das bekommt man auch 20 Jahre später nicht mehr aus dem Standard heraus.
Manchmal sind Firmenstandards ein Segen. Seit Borland der einzige ernstzunehmende Anbieter von Pascal ist können sie ihr Delphi erweitern wie sie wollen. Die Stringbibnliotehk wurde schon zweimal geändert von den maximal 255 Zeichen langen Pascalstrings auf ein System mit Referenzzähöern und 32 Bit Länge (maximal 2 Milliarden Zeichen) und dynamischer speicherverwaltung ohne das man als Programmierer dauernd selbst den Speicher holen und freigeben muss und einmal vom Ansi auf den Unicode. Interessanterweise hat bei der Umstellung das letztere mir mehr Probleme gemacht da zahlreiche Fremdkomponenten die ich hatte im C-Stil Strings mit Zeigern bearbeitet haben.
Compileranbieter haben zwar ihre eigenen Implementierungen, aber die CPP Standardbibliothek ist tatsächlich Teil des Sprachstandards und somit nicht austauschbar. Was natürlich immer noch nichts daran ändert, dass sie viel zu wenig benutzt wird.
Okay, ich glaube, in sicherheitskritischen Bereichen wie der Raumfahrt wird sich C/C vielleicht nicht durchsetzen, aber dank des MISRA-C Standards verbreitet sie sich auch dort. Und Software für Systeme der Bodenkontrolle oder zur Datenauswertung wird durchaus auch in C/C entwickelt, wie ich in Stellenanzeigen der ESA schon gesehen habe.
Welche Sprache (jetzt mal abgesehen von Ada) haltet Ihr denn in sicherheitskritischen Bereichen für Sinnvoll?
@Arne: Was ist denn der sichere Ersatz für die C-Strings? – Die Cpp Stringbibliothek? Oder was?
Bezüglich der Cpp-Standardbibliothek fällt mir noch ein, dass in den Entwicklerrichtlinien zum Programm Stellarium drin steht, dass man zumindest die STL, bzw. STL-Container nur dann verwenden sollte, wenn es auf Geschwindigkeit ankommt. Ansonsten möge man Qt-Container vorziehen, weil sie einfacher zu benutzen sind… – kann ich allerdings nicht beurteilen, weil ich Qt nicht kenne.
Bezüglich der Strings im allgemeinen bin ich mir jetzt zwar nicht ganz sicher, aber intern werden die doch sicherlich des öfteren mit Zeigern bearbeitet. Die Frage ist nur, ob man sich als Entwickler um diese Zeiger kümmern muss, oder ob sie durch das Sprachkonzept bedingt vor den Entwicklern verborgen bleiben. Und da ist es sicher ein Vorteil, wenn sie verborgen bleiben, man sich also nicht darum kümmern muss.
> @Arne: Was ist denn der sichere Ersatz für die C-Strings? – Die Cpp Stringbibliothek? Oder was?
Ja, bei std::string wird alles verborgen und man muss sich keine Gedanken um Überlauf oder Speicherallokation machen.
Aber wir schweifen langsam ab. Was mich mal interessieren würde, gibt es bekannte große Projekte, die in einer funktionalen Programmiersprachen gemacht wurden?
Okay, aber was, wenn man jetzt nicht in Cpp sondern in C entwickelt? – Gibt es auch für reines C eine sichere Stringbibliothek?
Ob es da ganze Projekte gibt, weis ich nicht, aber ich hab mal gelesen, dass bei dem unter Unix resp. Linux beliebten Editos Emacs ziemlich viel mit LISP gearbeitet wurde, vor allem was Erweiterungen angeht. Und die Skriptsprache für AutoCAD war (ist?) ein LISP-Dialekt.
@Arne: std::string ist alles andere als sicher. Das beginnt schon damit, dass der []-Operator „undefined behaviour“ zeigt, wenn der selektierte Index größer als die String-Länge ist. Auch bei der Verwendung von Iteratoren lebt man hochgradig gefährlich. Das beginnt schon mit der Gefahr einfacher copy&paste-Fehler, wenn man nicht alle Referenzen gleichlaufend ersetzt:
std::string s,t;
// assign s and t (not shown)
…
for(std::string::const_iterator sit = s.begin(); sit != s.end(); sit ) { … }
…
for(std::string::const_iterator sit = t.begin(); tit != s.end(); sit ) { … }
So was kann dann während der Testphase auch durchaus wiederholt gutgehen (etwa, wenn String s immer „nach“ t alloziert wird und folglich höhere Speicheradressen hat, so dass die Ende-Bedingungtit != s.end() zufälligerweise eben doch erreicht wird) und im Realbetrieb dann grandios scheitern. Richtig spannend wird es dann dadurch, dass jeder schreibende Stringzugriff alle Iteratoren invalidiert. Wie viele C -Programmierer haben das wirklich parat und achten da auch akribisch drauf? 90%, 95%, 99%? Und was ist mit den verbleibenden 1 bis 10%? Schreiben die dann unsicheren Code?
Letztendlich sind alle Programmiersprachen ein „Eiertanz“ zwischen den drei Zielen „Einfachheit“ (für den Programmierer), „Effizienz“ (der Nutzung der CPU) und „Sicherheit“ (dem reproduzierbaren Verhalten bei Fehlern). Je mehr man eines pusht, desto mehr verliert man meist die anderen.
Kai