The_Muh schriebMeine frage bezog sich ja auch auf auf die einfachheit der umsetzung von netzwerk-kram.

Ich bin mir sehr sicher, dass es für vieles bereits fertige Module gibt, ansonsten halt „from scratch“ mit Sockets.

Es sei gesagt, dass die Frage nach der richtigen, oder gar besten Programmiersprache so gut wie immer, auch wenn man sich bemüht objektiv zu bleiben, eine religiöse ist.

Wenn es Dein Ziel ist, auf pragmatischem Wege Arbeit zu erledigen, bei der es nicht vordergründig auf Performance, sondern auf Deine eigene Effizienz ankommt, wären die heute üblichen großen Skriptsprachen eigentlich alle zu empfehlen. Konret hieße das: Python, Perl und Ruby. Alle drei haben eine große Community (somit Bibliotheken, Dokumentation und Support) und erlauben es Dir, verschiedene Paradigmen zu nutzen. Generell ist an diesen Sprachen hervorzuheben, dass sie versuchen nicht "im Wege zu stehen".

Weiters gehören alle diese Sprachen zu einer Familie, die sich als "dynamisch" versteht. Damit ist nicht nur die dynamische Typisierung, oder dass man sich nicht von Hand um die Speicherverwaltung kümmern muss, sondern generell ein interaktiver, inkrementeller Stil der Entwicklung unter möglichster Vermeidung von Kontextwechseln und unnötiger Ablenkungen durch die Sprache an sich (die nicht zur Problemlösung beitragen, sondern oft Teil desselben sind) gemeint.

Welche dieser Sprachen man wählt, ist eigentlich egal, wobei das sich wie mit allen Religionen verhält; ihre Jünger haben sie alle.

(Dass ich andere "Skriptsprachen" hier nicht erwähne heißt nicht zwangsläufig, dass ich sie für ungeeignet halte, JavaScript zum Beispiel wäre sehr zu empfehlen; nicht nur fürs Web.)

Strenggenommen kannst Du ohnehin erst beurteilen, ob die Sprache "zu langsam" ist (eigentlich an sich schon eine falsche Betrachtungsweise, denn am meisten lässt sich nach wie vor durch gute Algorithmen, danach durch weitere Optimierung machen, nicht durch die Wahl der Sprache), nachdem das Programm bereits umgesetzt wurde. Davon abgesehen sind nicht "Sprachen" langsam, sondern allenfalls Implementierungen derselben.

Wenn es Dir aber darum geht, hardwarenah, oder auf Betriebssystem-Ebene zu Programmieren, vielleicht generell den Computer besser kennenzulernen, solltest Du C lernen. C ist quasi die Lingua Franca der Betriebssystemprogrammierung, nicht nur unter unixoiden Systemen, und stellt ein lokales Optimum für die hardwarenahe Programmierung von Maschinen der Von-Neumann-Architektur dar. Eine bequeme Sprache ist es nicht; vieles, was heutzutage als selbstverstädlich empfunden wird ist nicht im Standard enthalten (was nichts zwingend schlechtes ist) und Dinge wie händische Speicherverwaltung können eine gravierende Fehlerquelle darstellen. Auch Assembler wäre hier eine Möglichkeit, aber das Verhältnis von Aufwand zu Nutzen wird wohl für die meisten Anwender zugunsten von C liegen.

C++ solltest Du lernen, wenn Du es entweder beruflich brauchst, oder ein Masochist bist.

Auch Java solltest Du lernen, wenn Du denkst, dass es Deine berufliche Laufbahn erfordert, ansonsten bietet es eher wenig (die Sprache, nicht die JVM), was Du nicht in anderen Sprachen ohne die Java-eigen Nachteile haben könntest. (Die da wären: Verbosität, vorgeben was der Entwickler "will" und "braucht", insgesamt komplizierende Tendenz, nicht nur im Wege zu stehen, sondern steinewerfend Blockaden zu errichten).

Funktionale Sprachen wie Haskell sind es sicherlich wert, studiert zu werden, da sie Dir eine andere Sichtweise auf Berechenbarkeit (Turing-Maschine vs. Lambda-Kalkül) eröffnen. (Insbesondere streng) funktionale Programme sind in der Regel leichter zu warten und subjektiv "berechenbarer". Es ist schlicht einfacher, über eine Funktion Aussagen zu treffen, die jeweils bei gleicher Eingabe das gleiche Ergebnis liefert, als in Sprachen, welche die referenzielle Transparenz nicht gewährleisten. Auch was Nebenläufigkeit angeht, hat man es in streng funktionalen Sprachen einfacher, da das Hauptproblem jener der Zugriff auf und die Zuweisung an veränderbare Datenstrukturen ist. Davon abgesehen ist die generelle Herangehensweise eher deklarativ, als dem Computer die einzelnen Schritte, welche zum Ziel führen, vorgeben zu müssen. Die interessantesten Sprachen sind hier zur Zeit meiner Meinung nach Haskell, Erlang, die ML-Familie, sowie Clojure; wobei Haskell sicherlich die strengste unter diesen ist, Clojure (die dynamischste der genannten) und Erlang im Bereich Nebenläufigkeit brillieren. Auch für die genannten Sprachen gibt es ausreichend Bibliotheken, wenn auch nicht im Maße eines CPAN, und sie haben gute, hilfreiche Communities, wie es heute zum guten Ton gehört.

Smalltalk ist vordergründig durch die Erfahrung interessant, welche das integrierte System, welches mehr oder weniger untrennbar mit der Sprache verbunden ist, bietet. Was die Sprache an sich angeht, so ist die extrem konsequente Objektorientierung und die ihr eigene Dynamik am augenfälligsten. Meiner Meinung nach DIE objektorientierte Sprache schlechthin (auch wenn Common Lisps CLOS flexibler ist) und Wert, angeschaut zu werden. Da es sich bei so gut wie allen relevanten Smalltalk-Systemen um Image-orientierte Mikrokosmen handelt, in welchen wirklich alles zur Laufzeit einsehbar und veränderbar ist und manchmal ein Jahrzehnte alter Fundus an Code im Image auf die Erforschung wartet, kommt das ganze eher einem Rummelplatz für Programmierer als "harter Arbeit" nahe.

Wenn Du aber eine Sprache haben willst, die Du Dir zu dem machst, was Du Dir unter einer guten Programmiersprache vorstellst, dann lerne Lisp. Keine Sprachfamilie macht es so einfach, unter verschiedenen Paradigmen zu arbeiten und die Sprache an sich zu formen. Lisp ist die Mutter aller dynamischer Sprachen und inkrementeller Entwicklung; eine der beiden ältesten Sprachen in heutiger Verwendung und gleichzeitig immer auch eine der modernsten, da der einzelne Programmierer sie sich durch die Mächtigkeit der syntaktischen Abstraktion, welche die Homoikonizität der S-Expressions in Verbindung mit dem Makro-System gewährleisten, ermöglicht. Egal ob das relativ strenge, minimalistische Scheme, die eierlegende Wollmilchsau Common Lisp, oder die Neue im Bunde, Clojure, die funktionalste der dreien: Sie alle bieten diese relativ seltene Freiheit der syntaktischen Abstraktion. Auch wenn ich, wie oben erwähnt, der Bezeichnung von Programmiersprachen als "schnell" skeptisch gegenüberstehe, so sei gesagt, dass beispielsweise Common Lisp in Benchmarks (welche IMMER fragwürdig sind) häufig gar in der Nähe von Spachen wie C anzutreffen ist. Unter Clojure und ABCL stehen alle Java-Bibliotheken bequem zur Verfügung und Common Lisp gleicht einen relativen (es hat sich gebessert) Mangel an Bibliotheken durch ein äußerst bequemes und flexibles FFI aus, in welchem Bindings schneller geschrieben, als die meisten Java-APIs verstanden sind.

Welche dieser, oder anderer Sprachen man lernt, ist letzten Endes Geschmacksache und Frage der persönlichen Anforderungen und Ziele. Deine Vorgaben lassen sich letztlich mit allen diesen Sprachen und theroretisch sowieso mit jeder Turing-vollständigen Sprache umsetzen, die Frage ist nur: Wie?

Jede Aussage anderer ist letztlich zum größten Teil Meinung und Religion, auch meine eigenen Aussagen machen da keine Ausnahme. Vor allem manche Kommentare in diesem Thread haben mir geradezu die Haare zu Berge stehen lassen, also bedenke vor allem, dass man sich sein eigenes Bild machen muss und es viele Sprachen gibt, die es wert sind gelernt zu werden. Mein abschließender Tipp ist, sich eine Sprache zu wählen, die größmöglichste Freiheit erlaubt, ohne unstrukturiert und chaotisch zu sein. Aber wie gesagt: Das alles bitte cum grano salis.

Also im Prinzip alles ausser C++.

HTH

Enorm! Aus dieser Übersicht könntest du einen Wiki-Artikel basteln. Allerdings fürchte ich, dass einiges nur "Eingeweihten" verständlich ist.

Objektorientierung kommt ein bisschen zu kurz. Und die pauschale Ablehnung von C++ ist mir zu harsch. Gut - es gibt da bessere Lösungen (und man muss ja nicht unbedingt auf Java ausweichen), aber trotzdem sollte man sich das ansehen, und wenn es nur darum geht, sich im Wust von Qt/KDE-Anwendungen zurechtfinden zu können.

Ich würde mir eine gute Grundlage in Lisp legen. Damit kommt man in funktionalen Sprachen anschließend leichter zurecht. Ansonsten auf alle Fälle C und mindestens eine Skriptsprache. Wobei die Reihenfolge jetzt eigentlich auf dem Kopf steht, d.h. vom Einfacheren zum Schwierigeren z.B.: Python -> C -> Lisp und das dann ganz nach Geschmack ausbauen.

Python (oder Ruby, aber das ist immer noch recht "exotisch") hat den Vorteil, dass gleich in Objekte mit reingeschnüffelt werden kann. C ist "lingua franka", da kommt man nicht drum rum. Und Lisp, wie gesagt, um sich eine sichere Grundlage, nicht nur für funktionale Programmierung, zu legen.

Außerdem empfiehlt sich ein intensiverer Blick auf Bash, denn dem entgeht man kaum - und nichts geht so schnell für kleine Probleme, als sich ein paar Zeilen Shellskript zusammenzuhauen.

Was fehlt? Reguläre Ausdrücke (regular expressions), in Sonderheit ihre Anwendung "sed" und wenn irgend möglich "awk". Die bilden ein Universalwerkzeug, das man aber wie Notenlesen regelrecht trainieren muss. Es gehört ein gewisser Hang zum Masochismus dazu, aber es soll tatsächlich Leute geben, die reguläre Ausdrücke "vom Blatt" lesen (und genießen) können.

Wie auch immer, ich empfehle eine gute, praxisorientierte Grundlage zu legen und darauf ganz nach Bedarf und Lust und Laune aufzubauen. (Soo schlecht war der Einstieg mit FreeBASIC nun auch wieder nicht.) Programmiersprachen lernen kann zum Hobby werden.

Nachtrag:
Ganz vergessen, wenn es um systemnahe Programmierung geht, sollte man sich unbedingt auch Lua ansehen. Lua-Programme werden in immer mehr andere Anwendungen eingebunden. Und anderes, wie beispielsweise der WM Awesome, setzt Lua-Kenntnisse voraus, will man es richtig einrichten.

bernarcher schriebUnd die pauschale Ablehnung von C++ ist mir zu harsch.

linopolus schrieb Was ist an C++ so schlecht? Dachte immer lieber C++ als C(kenn allerdings C++ nur ein bisschen und C gar nicht).

Ich möchte mich nicht großartig darüber auslassen, was nun meiner Meinung nach so schlecht an C++ ist, da kann man per Google genügend ausführliche Rants finden, oder, was noch viel besser wäre, sich sein eigenes Bild machen.

Kurz gesagt ist C++ ein Bastard: der gründlich gescheiterte (wenn man Erfolg nicht an Nutzerzahlen misst) Versuch eine objektorientierte Sprache für C-Programmierer zu erschaffen. Java ist die Neuauflage dieses Versuches und etwas besser gelungen, was es noch lange nicht gut macht.

C++ zeichnet sich vor allem durch Komplexität aus, sowohl aus syntaktischer (wer das bestreitet hat noch nie versucht, sich einen Parser für C++ auch nur vorzustellen) als auch semantischer Sicht. Mir hilft diese Komplexität in keinster Weise, im Gegenteil. Der Schlüssel zu einem sauberen Design ist es, einem Programmierer alle nötigen Türen offen zu halten, indem man unnötige Restriktionen so weit es möglich ist verhindert (Scheme ist hier ein gutes Beispiel) – der Weg den C++ eingeschlagen hat (das sukzessive Anhäufen aller erdenklichen Features) führt zu nichts Gutem.

Zum Thema C++ als objektorientierte Sprache möge man nach Alan Kay googlen. Ach, ich übernehme das kurz mal:

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

Ja, er hats erfunden und ja: der Mann weiß, wovon er spricht. Späte Bindung und Dynamik, alles ist ein Objekt, Polymorphie. Das sind die Kernpunkte Kays, nicht die Perversion, die Stroustrup da auf die Menscheit losgelassen hat.

Als ich elf oder zwölf Jahre alt war habe ich mir Borland C++ zusammengespart und war begeistert (allerdings eher von C als von C++, das mir selbst damals schon seltsam vorkam), wirklich. Damals hat man für so etwas richtig Geld ausgeben müssen, oder bei einem der wenigen örtlichen Geeks kopiert. Ich kannte nichts anderes, C++ schien die Zukunft zu gehören, das Internet war in den Kinderschuhen. Heute kann man sich ausführlich informieren und hat bessere Alternativen.

Natürlich ist es nicht schlecht, sich auch mit schlechten Dingen ein wenig auszukennen, so viel sei zugestanden.

Ganz davon abgesehen halte ich Objektorientierung für überbewertet (ohne ein Gegner davon zu sein).

Zu guter Letzt auch hier wieder der Hinweis, dass es sich um meine persönlichen, subjektiven Eindrücke handelt. Um aber, bei aller Relativierung, doch ehrlich zu bleiben muss ich sagen: Wer C++ wirklich MAG, den kann ich nur bedauern.

bernacher schriebPython -> C -> Lisp

Das wäre mit Sicherheit eine von mehreren vernünftigen Möglichkeiten, ja.

Außerdem empfiehlt sich ein intensiverer Blick auf Bash, denn dem entgeht man kaum - und nichts geht so schnell für kleine Probleme, als sich ein paar Zeilen Shellskript zusammenzuhauen.

Ein bisschen Shellprogrammierung schadet nie.

Soo schlecht war der Einstieg mit FreeBASIC nun auch wieder nicht.

Sehe ich genauso. Ich habe mit dem ROM-Basic des CPC464 angefangen und lebe auch noch.

[...] Es gibt aber eben heute auch zahlreiche Alternativen zu diesen Konstrukten.
[...] Man kann heute in C++ ausgesprochen elegant programmieren und trotzdem effizient
[...]Dies wird durch den kommenden Sprachstandard noch weiter zunehmen.
[...] eine breite Auswahl an Mitteln zur Verfügung.

Genau das bestätigt meinen Eindruck. Alte Features werden von neuen abgelöst, die alten bleiben bestehen, diese neuen Features werden einst die neuen alten sein und das ganze Spiel beginnt von vorne. Vor allem der "kommende Sprachstandard" ist eine, um in der Metapher zu bleiben, geradezu messianische Hoffnung auf eine erlösende Verbesserung, welche die Werkzeuge, die man benutzt "schon irgendwie hinbiegen" wird. Warum sollte es im mächtigen C++ nötig sein, auf den neuen Standard zu warten, warum ist man nicht in der Lage, diese Sprache selbst brauchbar zu machen? Sicher, über Bibliotheken kann man einiges erreichen, aber einiges ist zu wenig, um C++ zu einer "guten" Sprache zu machen.

Das Gefährliche an der C++ inhärenten Komplexität, am Anhäufen von Features, ist, dass es das Gefühl vermittelt, viel zu "können", viel zu "verstehen" und einfach alles mit diesem Wust an Wissen umsetzen zu können. Wenig wissen zu müssen um viel erreichen zu können ist die hohe Kunst guten Sprachdesigns.

[...] bisher unerreichtes Niveau an Portabilität erreichen, ohne im eigenen Code eine einzige Fallunterscheidung hinsichtlich der Plattform machen zu müssen. [...] Man muss ja im Übrigen bemerken, dass Portabilität in anderen Sprachen - vor allem deshalb gut gelingt, weil die Anzahl der Compiler und Laufzeitsysteme dort vergleichsweise gering ist.

Wenn etwas schlechtes eine gute Eigenschaft hat, wird es dadurch zu etwas Gutem?
Diese Eigenschaft ist nicht die Konsequenz der Sprache an sich, sie ist die Konsequenz der Arbeit, die in diese Bestrebung geflossen ist. Wenn man genug Aufwand betreibt, lässt sich auch mit schlechten Werkzeugen einiges erreichen. Wer sagt Dir, dass wenn nicht C++ sondern XY** die Rolle des (noch?) Platzhirsches inne hätte, diese positive Eigenschaft nicht schon viel früher, oder viel besser hätte umgesetzt werden können? Spekulation, ja, aber deshalb nicht weniger wahr.

Mit Masochismus hat das überhaupt nichts zu tun. Man ist vielleicht geneigt, so etwas über jede Sprache zu behaupten, die man nicht gut genug kennt und einem kompliziert erscheint. (Ich hätte da eine ganze Reihe von Kandidaten ...)

Das nicht alles, was einem kompliziert erscheint, kompliziert sein muss, ist wohl war. Aber was, wenn C++ einfach wirklich unverhältnismäßig komplex und die schlechtere Alternative zu Dingen ist, die Du nicht kennst?

Natürlich ist man nicht notwendig Masochist, wenn man C++ benutzt; diese Floskel als solche zu erkennen traue ich eigentlich jedem hier zu. Wenn jedoch ich es nutzte, so wäre ich ein Masochist.

ED: Irgendwie hat dise Forensoftware ein Eigenleben, das sie fast für den Turing-Preis qualifizieren würde.

The_Muh schriebGenerell bin ich kein fan von Strikter Objekt Orientierung. Ich erkenne durchaus die stärken von OOP, auch wenn ich es in FB nie wirklich kennengelernt habe (siehe seite eins). Eine Sprache die mir OOP vorschreibt, möchte ich derzeit nicht lernen. Dafür hab ich bisher zuwenig erfahrung mit OOP - und ich sehe für manche einsatzgebiete keinen Sinn in OOP. Wenn ich ne Schleife schreibe die auf nen tastendruck wartet, und bis zum tastendruck ein "Bitte Taste Drücken" ausgiebt, dann brauch ich dafür kein Objekt.

Wie gesagt denke ich persönlich, dass OOP überbewertet wird – was nicht heißt, dass es generell etwas schlechtes ist. Zur Erläuterung greife ich Dein Beispiel in abgewandelter Form auf.

Nehmen wir an, Du wolltest jedes Element eines Arrays quadrieren. Das erste was Dir in den Sinn kommen mag ist eine Schleife, in welcher Du über das Array iterierst. Wenn Du DIESEN Ansatz in einer (vernünftigen) objektorientierten Sprache umsetzen willst, so gebe ich Dir Recht: es bietet keinerlei Vorteile, sich in irgendeiner Weise mit Objekten auseinanderzusetzen und die Umsetzung wäre wahrscheinlich ungelenk. Allerdings bietet Dir die jeweilige Sprache ja ihre eigenen Mittel und ihre eigenen unterstützten Paradigmen an. Zum Beispiel in Smalltalk:

#(1 2 3 4) collect: [:e | e * e].

Schön und gut, was soll da der Vorteil zur gewohnten Schleife sein? Ganz einfach: #(...) ist ein Objekt der Klasse Array, ihm wird die Nachricht collect: gesendet, welche als Argument eine anonyme Funktion (einen Block) empfängt, der seinerseits an jedes Objekt e (e für Element) die Nachricht * sendet, welche als Argument wiederum das Objekt e empfängt und das Ergebnis zurückgibt. Collect sorgt dafuer, dass dieser Block für alle Elemente des Arrays aufgerufen und die jeweiligen Ergebnise als Array zurückgegeben, quasi gesammelt, werden.

Moment. Hatte ich nicht einen Vorteil versprochen? Also, davon abgesehen, dass du keine off-by-one Fehler produzieren wirst, die zwangsläufig auch bei wirklich guten Programmierern nach der 10000 for-Schleife mal auftreten, sollte Dir aufgefallen sein, dass alles Genannte entweder Objekt oder Nachricht ist. Das ist Smalltalk, mehr gibt es im Prinzip nicht zu wissen. (Natürlich musst du Datenstrukturen unt Ähnliches kennenlernen, aber das Fundament der Sprache, das was sie ausmacht, was Du zu erwarten hast, ist damit geklärt. Stelle dem einmal Sprachen wie C++ gegenüber und du weisst, was ich mit Komplexität meine.) Alles ist ein Objekt und Objekten sendet man Nachrichten. Man bittet sie quasi darum, etwas zu tun. Wie sie das machen ist für Dich als Bittsteller erst einmal vollkommen egal. Ein einfaches Konzept, ein mächtiges Konzept. Trotz, und gerade ob, seiner Einfachheit bietet es eine elegante Möglichkeit, alle Programmieraufgaben zu bewältigen.

Langer Rede kurzer Sinn: Nicht jede OOP-Sprache ist unnötig komplex und "einschränkend". Auch wenn Smalltalk nur dieses eine Paradigma unterstützt, so tut es dies wenigstens optimal.

Bei lisp weiß ich nicht ob (bzw wie schnell) ich mich an die (umgekehrte) Polnische Notation gewöhne. Wer Jahrelang in der Schule die normale Notation nutzt, und auch mit dieser Programmiert, der guckt erstmal doof, wenn plötzlich "+ 1 1" = "2" ist.. das sieht einfach unnartürlich aus.

Ja, bei mathematischen Ausdrücken mag die Prefix-Notation ungewohnt und fremdartig sein, aber wie steht es mit sqrt(x) in C? Oder print "hallo" in Basic?

Lisp ist einfach konsequent, indem es Syntax auf ein Minimum reduziert. Durch diese Reduktion wird syntaktische Abstraktion soweit erleichtert, dass sie auch wirklich genutzt werden kann.

Ruby sieht ganz nett aus. Der Wikipedia-Artikel macht richtig apitit auf die Sprache 🙂. Allerdings weiß ich nicht wie verbreitet Ruby auf Unixoiden Systemen ist, und ich glaube nicht das ein Compiler existiert der das Problem lösen könnte. Python dagegen ist auf fast allen Maschinen zu finden, die sich mit einem Linux-kernel schmücken.
</code>

Ja, Python ist verbreiteter, aber ich denke nicht, dass Du mit Ruby in eine "exotische" Nische gedrängt wirst. Meine persönliche Meinung zu Perl, Python und Ruby ist wirklich, dass es fast egal ist, welche der Drei man benutzt. Fast.

<code>
Eine weile hab ich übrigens auch mit TCL / TK geliebäugelt... ich fand den Syntax hochinteressant, aber anfragen in div. IRC-Channels hat ergeben, das sich diese sprache nicht lohne. (Zumal die performance meist schlecht ist. wer mal aMSN benutzt hat wird wissen was ich meine).

Nicht lohnen ist meines Erachtens dummes Geschwätz. Erstens liefert Dir Tcl/TK eines der wenigen wirklich bequem und intuitiv zu benutzenden plattformübergreifenden Toolkits für GUI-Anwendungen (die, wenn man weiß wies geht seit 8.5. auch vernünftig aussehen), zweitens bietet die Sprache an sich auch so manche interessante Eigenschaft. (Homoikonizität, einfache, konsequente Syntax). Sicher, meine erste Wahl wäre es nicht, aber Tcl ist lange nicht so schlecht, wie sein Ruf es vermuten ließe.

Was es noch gibt? REBOL.

T.M. schrieb Das seh ich durchaus nicht so und gehe davon aus, dass der ganz überwiegende Teil von C++ auch in dem neuen Standard bestehenbleibt,

Genau das sage ich auch.

[Abschnitt über Verbesserungen bezüglich Standardisierung]

Natürlich ist es eine gute Sache, dass man Standards etabliert, keine Frage, aber das trifft nicht den Kern meiner Aussage. Meine Kritik richtet sich dagegen, dass der primäre Ansatz von C++ es nicht ist, einfache aber mächtige Abstraktionen zu schaffen, sondern grundsätzlich zu kompliziert und nicht aus sich selbst heraus wirklich offen für Erweiterungen zu sein.

Du denkst, die STL sei eine gute Sache. Dies ist nachvollziehbar, weil sie ein Problem für C++ gelöst hat. Fein. Ich bestreite das nicht, was ich sage ist: In anderen Sprachen GÄBE es das Problem gar nicht, welches die STL für C++ lösen musste.

Aus diesem Satz spricht viel Negatives. Also erstens wartet man nicht tatenlos, sondern arbeitet weltweit jeden Tag mit C++ wie es ist. Ich wüsste, ehrlich gesagt nicht, was an C++ nicht brauchbar sein sollte.

Ein Bauer im Mittelalter hätte mit Sicherheit auch nicht gewusst, was man an der Drei-Felder-Wirtschaft verbessern, oder warum er lesen und schreiben lernen sollte. (Nicht, dass ich Dich beleidigen wollte)

Aber wohlan, wir können ja auch gerne zu Potte kommen. Zeige mir doch einmal, wie du in C++ ein syntaktisches Konstrukt einführst, welches dir 1. Eine Datei öffnet, 2. Deinen Code im Kontext der geöffneten Datei laufen lässt, 3. Die üblichen Aufräumarbeiten durchführt. Konkret heißt das: Implementiere in C++ ein Konstrukt, welches einen Kontext etabliert, in dem Dein Code, der lekikalisch von diesem Konstrukt umgeben ist, ausgeführt wird. Das ist eine faire Chance mir zu zeigen, dass es in C++ nichts zu vermissen gibt. Ich bin gespannt, ob C++ mittlerweile da ist, wo andere Sprachen in den sechziger Jahren waren und wenn ja, wie das ganze aussieht.

Ich vermute einfach, in der Beurteilung dessen, was eine gute und brauchbare Sprache ist, gehen die Meinungen zu weit auseinander.

Da hast Du vollkommen Recht und ich sage ja die ganze Zeit das es zwangsläufig auf Folgendes hinausläuft: Allah ist der Chef! Nein, wir landen alle im Nirvana! Schwachsinn, wir werden alle mit Jesus im Himmel Brot und Fische teilen.

Sogar die in C++ entweder unlösbare, oder nur sehr schwer lösbare Aufgabe, die ich Dir aufgetragen habe wird Dich nicht umstimmen können. Mehr noch, wenn ich Dir die einfache und klare Lösung in ein paar Zeilen zeige, wirst Du ihren Wert nicht erkennen. Warum? Allah! Nein, Jesus ... oder ... ähm ...

Demnach wäre Lisp die allerbesteste, BASIC die zweitbeste usw. Man erinnere sich, was das B in BASIC bedeutet. Man blicke auch auf Haskell unter diesem Gesichtspunkt.

Lisp hat gute Chancen auf einen ersten Platz, ja, aber man muss bedenken, dass es sich dabei um eine Sprachfamilie handelt. Jedes Lisp hat Stärken und Schwächen. Es gibt Raum für Verbesserungen. Was Basic da soll verstehe ich nicht. Zwar macht Basic vieles Einfache einfach, scheitert jedoch daran, das Schwere einfacher zu machen. Haskell ist nicht meine erste Wahl, ich bevorzuge, trotz der guten Typenableitung, dynamisch (aber streng) getypte Sprachen. Trotzdem beschäftige ich mich damit, lerne davon und sehe die relativen Stärken.

T.M. schriebDu meinst, Du willst C++-Code, meinetwegen eine Funktion, in anderen Code einbetten, der in einer Datei steht, und dies zur Ausführung bringen?

Nein. Was ich möchte ist ein Konstrukt, welches Dir folgendes ermoeglicht:

with_open_file(file_descriptor, "/foo/bar/baz")
{
    frobnicate(frob);
    while (i_wanna) {
       read(...)
       ...
       ...
    }
}

Was ich außerdem will ist, dass dieses Konstrukt auch die nötigen Aufräumarbeiten durchführt. Wie Du das ganze umsetzt ist Deine Sache. Die Hauptsache ist: Kontext einer geöffneten Datei, Filedescriptor binden, Code im Kontext ausführen, aufräumen.

Und das mit einer bis hinab auf stark optimierten Maschinencode compilierten Sprache?

Das sind gute Lisp-Implementationen auch.

Falls Dir Diese Aufgabe nicht liegen sollte (hehe), eine Alternative:

Ein Objekt soll gedruckt werden, die Druckmethode wird nach einem Medium und der Klasse des Objekts ausgewählt. Beide Parameter stehen erst zur Laufzeit fest, da sowohl das Objekt, als auch das Medium durch Usereingabe festgelegt werden. Die Lösung soll objektorientiert sein, sprich polymorph, kein if, kein case. Ganz normale OOP. Mal sehn wie C++ sich schlägt.

danlei schrieb

with_open_file(file_descriptor, "/foo/bar/baz")
{
    frobnicate(frob);
    while (i_wanna) {
       read(...)
       ...
       ...
}

Sorry, aber was soll das sein? Eine Funktion, die eine Datei liest und meinetwegen zeilenweise ausgibt?

ifstream i("Dateiname", ios::in);
string line;
while (getline(i, line))
{
       cout << line << endl;
}

Was für Aufräumarbeiten? Dieses code-Schnipsel ist dicht, da gibt's nichts aufzuräumen. Und, ja, das geht für beliebig grosse Dateien mit beliebig langen Zeilen.

Update, ahhh, stopp, es ging um einen geöffneten Dateideskriptor. Da muss ich kurz nachlesen...

Es sieht so aus, als ob die klassischen fstream-Klassen dies nicht unterstützen, unter anderem deshalb, weil es mehrere verschiedene Arten gibt, Filedeskriptoren darzustellen. Es ist ja übrigens zu bemerken, dass es sich hier um ein Schnittstellenproblem handelt. Wo hört nun die Sprache auf und wo fängt die Laufzeitumgebung bzw. das Betriebssystem an?

Die boost-Bibliothek "Iostreams" bietet allerdings neu implementierte, generische stream-Klassen an, die man sehr elegant auf alles mögliche legen kann, sogar auf Sockets und sonstwas, auch auf Filedeskriptoren. Es existiert dazu eine eine Klasse file_descriptorDer resultierende Code ist nicht viel schwieriger als obiger.