Das hier wird wahrscheinlich mal ein längeres Posting, also sagt nicht, ich hätte euch nicht gewarnt... ;)

Ich muß zunächst mal ein bißchen ausholen. Ich habe mir drei Kriterien erstellt, nach denen ich eine Sprache bewerte. Natürlich haben auch Sprachen, die diese Kriterien nicht alle erfüllen oft ihre Berechtigung (z.B. Skriptsprachen). Die wären:

1) Die Sprache muß komplett sein. Das soll heißen, daß man die Sprache in sich selbst darstellen können muß. Dieses Kriterium wird eigentlich von den meisten Sprachen richtigen Sprachen erfüllt: man kann einen C-Compiler in C schreiben, einen PHP-Parser in PHP, und einen BASIC-Interpreter in BASIC. Es gibt natürlich auch nützliche Sprachen, die dieses Kriterium nicht erfüllen. Shellskripte sind z.B. sehr nützlich, aber mit reinem Shellskript kann man schlecht nen Parser programmieren.
BTW die KI-Scriptsprache von AOE2 ist natürlich auch nicht komplett, aber die Standard-KI-Gegner von AOE2 sind komplett in der Scriptsprache geschrieben. Kein Wunder sind die manchmal etwas beschränkt *g*
BTW die zweite: Was mich mal interessieren würde: Sind Turingmaschinen komplett?

2) Die Sprache muß kompakt sein. Das sollte eigentlich offensichtlich sein. Mit 100+ Keywörtern kann ich nichts anfangen. Und wozu braucht man ein AND wenn's && genauso tut? Pascal und Basic fliegen hier also ganz klar raus. Assembler übrigens auch.

3) Die Sprache muß rein sein. Im Prinzip heißt das, daß man auch ohne irgendwelche Stdlibs ein Programm komplett erstellen kann, und daß man alle Standardfeatures der Sprache selbst nachbauen kann. Eine Fallstudie:
Wenn man WriteLn in Pascal benutzt, erstellt der Compiler für jedes einzelne Argument einen eigenen Funktionsaufruf. Aus
WriteLn("Hallo ", name, "!");
macht der Compiler also insgesamt drei Funktionsaufrufe auf Funktionen, die man als normalsterblicher Programmierer nicht direkt aufrufen kann, und die man auch nicht selber nachbauen kann.
Im Gegensatz kann man die C-Funktion printf() sehr wohl selbst in reinem C programmieren.

---
Nach dieser Einführung kann's losgehen. Übrigens, wenn ihr denkt, die obigen Kriterien sind unsinnig, dann ist der Rest fast schon uninteressant für euch.
Wie ihr sicherlich bemerkt habt, erfüllt C alle diese Kriterien so gut wie sonst kaum eine Sprache. Leider, leider, verdient C++ den Namen C++ nicht, denn dieser Name läßt ja auf ein besseres C schließen, was C++ nicht uneingeschränkt ist, denn mit einigen Traditionen wird auf rüdeste Weise gebrochen. Der Name "D" wäre eigentlich angebrachter.

Und je tiefer man in die C++-Welt kommt, desto mehr Dinge fallen einem auf. Ich trage hier nunmal alles zusammen, was ich gefunden habe:

- RTTI, also RunTime Type Information. Dieses Feature fügt zusätzlichen Code bzw. Daten in die Executable ein, damit man von einer beliebigen Klasse zur Laufzeit den Klassentyp bestimmen kann. Zum Glück läßt sich dieses Feature an- und ausschalten.

- Exceptions sind eigentlich das allergrößte Übel, vor allem deswegen, weil man nicht um sie herumkommt (wenn man die OOP-Features verwenden will).
Für Exceptions erzeugt der Compiler zusätzliche Daten und Code _und_ ruft compiler-spezifische Bibliotheksfunktionen auf. Ein eindeutiger Verstoß gegen Kriterium #3.

- Automatische Konstruktion und Destruktion globaler Daten. Wenn man eine Variable global definiert (und diese ist eine Klasse mit Konstruktor), dann muß beim Programmstart der Konstruktor, und beim Programmende der Destruktor aufgerufen werden. Dies trifft übrigens auch auf lokale static-Variablen und static-Membervariablen von Klassen zu.
Damit das funktioniert, erstellt der Compiler compilerspezifische Datenblöcke, die dann von der RTL beim Starten abgearbeitet werden. Dies ist ein eindeutiger Verstoß gegen Kriterium #3.

- Namespaces. Namespaces verstoßen ziemlich eindeutig gegen Kriterium #2. Zudem kann ich keinen Grund dafür sehen, Namespaces zu verwenden. Wenn ein Projekt _wirklich_ so groß ist, dass man Namespaces bräuchte, dann ist das ein eindeutiges Zeichen dafür, dass es in mehrere dynamische Libraries aufgeteilt werden muß (am besten noch mit Pluginfunktionalität und schon hat man sogar ein neues Feature, zusätzlich zum übersichtlichen Code).

- xxx_cast: Diese Dinger (const_cast, dynamic_cast, static_cast, reinterpret_cast) sind nun wirklich _absolut_ unnötig. Alle diese Dinge, mit der Ausnahme von dynamic_cast, lassen sich durch normales C-Casting auch erreichen. Jetzt argumentieren die C++-Verfechter natürlich mit Typensicherheit. Tut mir leid, aber das kann ich absolut nicht nachvollziehen. Von den tausenden (wenn nicht gar millionen ;)) Bugs, die ich bis jetzt in meine Programme eingebaut habe, waren vielleicht 3-4 auf Grund von fehlerhaftem Casting.
dynamic_cast ist absoluter Quatsch, denn diese Art des Casting erstellt zusätzlichen Code, der zur Runtime ausgeführt wird. Das widerspricht nicht nur dem gesunden Menschenverstand, sondern benötigt auch noch compiler-spezifische Bibliotheksfunktionen und ist damit ein grober Verstoß gegen Kriterium #3. Zudem gibt es _keine_ Anwendung von dynamic_cast, die man nicht auch mit virtuellen Funktionen realisieren könnte.
Ganz abgesehen davon: Haben die Hanseln überhaupt mal nachgedacht, wieviele Tastenanschläge man für "reinterpret_cast<xxx>" braucht? Das ist doch nicht mehr normal! Damit wird nun auch gegen Kriterium #2 verstoßen.

- Sprache und Standardbibliothek sind zu eng miteinander verknüpft. Ich hab den Standard zwar nie gesehen, weil man ihn wohl nirgendwo online kriegt (auch son Hammer...), aber von dem, was sich erkennen läßt, läßt sich darauf schließen, dass die Sprache zu eng mit der Standardbibliothek verbunden ist. So weit sogar, dass die Features der Standardbibliothek ernsthaft als Features der Sprache angepriesen werden. Ein weiterer Verstoß gegen Kriterium #3

- Implizite Referenzen (also & in Parametern und Rückgabewerten). Das ist eigentlich mein schwächster Kritikpunkt, denn es macht durchaus Sinn, aber nur als const-Referenz. Damit kann man dem Compiler nämlich sagen er solle doch bitte einfach nen Pointer auf etwas übergeben, anstatt das ganze Objekt im Speicher hin- und herzukopieren.
Nicht-const-Referenzen sind dagegen ein Werk des Teufels, denn man kann als Caller nicht mehr erkennen, ob die Funktion den übergebenen Parameter verändert. Wenn eine Funktion also einen Parameter verändern will, dann soll sie gefälligst einen ganz normalen Pointer entgegennehmen.

Alles in allem gesehen ist C++ also bei weitem keine reine Sprache mehr, und verdient eigentlich nicht, als Nachfolger von C gesehen zu werden. Zumindest nicht als C++. Wenn, dann als D, oder was weiß ich.
Zum Glück kommt man um die meisten dieser unreinen "Features" herum, nur um Exceptions leider Gottes nicht. Wie ich schmerzhaft herausfinden mußte hat jeder Konstruktor und Destruktor einen impliziten try/catch-Block :((

---
Ich bin für eine neue Sprache ("C+"? *g*), die die guten Aspekte von C++ in sich vereint, und den ganzen esoterischen Quatsch wegläßt. Die Sprache wäre also C mit folgenden Erweiterungen:

- Variablen-Deklarationen innerhalb von Funktionen
- Klassen wie bei C++; zusätzlich gibt es ein fail-Schlüsselwort mit dem man die Fehlfunktion eines Konstruktors anzeigen kann. Templates können von mir aus auch drin sein. Zudem muß es möglich sein, Konstruktor und Destruktor explizit aufzurufen.
- inline-Funktionen (gab's IIRC offiziell bei C noch nicht; gcc unterstützt sie trotzdem)
- operator-overloading; operator-overloading kann echt ziemlich nützlich sein, und wenn jemand unbedingt << und >> für Streams verwenden will, dann ist das sein persönliches Problem.

Vielleicht, ganz vielleicht, könnte man auch Referenzen im C++-Stil dazunehmen. Aber da sträubt sich mein Innerstes irgendwie dagegen *g*

Ach ja, und ich bin gegen die Aufnahme einer STL, denn die würde nur schlechten Programmierstil fördern.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hm. Wirklich interessant :)
Aber eigentlich wäre es ja unnötig, und würde nur für noch verwirrung sorgen wenn jetzt noch ein C mit ein paar erweiterungen rauskommen würde...

Ausserdem sind einige der #3 Verstöße in meinen augen eigentlich gar keine :)
Weil C++ eine eigenständige sprache ist und zB static_cast und so schlüsselwörter sind sind sie ja fixe bestandteile der SPRACHE selbst, und die muss man ja nicht nachbasteln könnenn oder?

[url="http://www.thelordoftherings.com/cgi-bin/get-image.pl?ID=alan-lee-058 "]-N/A-[/url]
[url="http://www.microsoft.com/germany/ms/unternehmensinformationen/historie.htm "]Mean cats eat parakeets![/url]

Hat dich Richard Stallman bezahlt, Prefi?

Zu deiner Frage 1: Turingmaschinen sind komplett, weil aus dem Resultat heraus die Erkenntnis kommt, daß eine Turingmaschine die Unvollkommenheit eines Computers verkörpert.

Der Rest ist wie immer Ansichtssache, vor allem da du als alter Makrofetischist so derbe über die cast_xxx herziehst und deren typsichere Konvertierung zur Lauf- oder Kompilierzeit bemängelst. Irgendwie etwas paradox, nicht?

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Nein, RMS bezahlt micht nicht. Ich hätte natürlich nichts dagegen *g*

Ich hab übrigens eigentlich nur wirklich über Runtimeconversion hergezogen. Im Zusammenhang von Makros wäre static_cast evtl. das einzige, was etwas Sinn bringen könnte. Da reinterpret_cast aber nur (wenn ich das richtig verstanden habe) ne andere Schreibweise für normales C-Casting ist, ist es doch ziemlich unnütz, oder?

Das Problem ist ja auch nicht, dass C++ so viele Erweiterungen hat, das Problem ist, dass man nicht um sie herumkommt. Dadurch dass C++ so viel unkontrollierbares Zeugs im Hintergrund betreibt hat man ein echtes Problem sobald man mal etwas außerordentlicheres Zeugs machen will. Kein Wunder haben die Linuxer, nachdem sie für 0.0.2 Versionen oder so C++ verwendet haben, sofort wieder auf reines C zurückgeschaltet.

Gibt's irgendwo einen Beispiel für eine Turingmaschine in der Turingmaschine? Ich habe mal was von Roger Penrose gelesen, bei dem er davon ausgeht, dass Computer lediglich erweiterte Turingmaschinen sind. Daraus leitet er dann im Endeffekt ab, dass ein Computer nicht wirklich denken werden kann. Allerdings begründet er seine Annahme, Computer seien mit Turingmaschinen in diesem Kontext gleichzusetzen, nicht weiter.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Öhm... Ich gehe davon aus, dass das hier erst ab dem 100-mal lesen verstanden werden muss von normalsterblichen

Der Overhead in C++ ist mir ehrlich gesagt vollkommen schnurzpiepe, denn darauf habe ich als Programmierer keinen Einfluß, solange ich nicht in den Kerndateien rumpfusche (was ich sicherlich nicht vorhaben werde).

Die ganzen Typumwandeler resultieren ja im Endeffekt darauf, daß C++ das gute, alte C noch intus hat und daher gezwungenermaßen für die Stabilität von C++ Programmen diese Schlüsselwörter miteinbringt. Schließlich muß ein C++ Programm via extern "c" {} auch den alten Stil kompilieren können und der Standard ist nachwievor, daß beide Sprachen akkurat kompiliert werden.

Hm, Penrose's Ansichten habe ich nicht gelesen, allerdings verstehe ich nicht, wie er auf den Gedanken kommt, daß Computer nichts weiter als erweiterte Turingmaschinen sind. Eine Turingmaschine ist ja bereits ein Computer, wenn auch in sehr abstrakter und sehr einfacher Form.

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

ich trinke cola!

Another1

...relaxing..atm =)
... und Schweiz suckt!

LOL!

----------------------------------------
[url="mailto:polymorph@gdnmail.net"]Polymorph[/url]
Lead Programmer of Paroxysm - Alien Encounters

Hmm... die Frage ist, wie würdest du einen Computer als Turingmaschine modellieren? Soll etwa der ganze Prozessor + RAM zusammen den Zustand bilden, und das "Band" wären quasi Tastatur/Bildschirm oder was?

Ich trinke keine Cola. Zumindest im Moment nicht ;)

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

wtf is überhaupt eine turingmaschine??? :)

[url="http://www.thelordoftherings.com/cgi-bin/get-image.pl?ID=alan-lee-058 "]-N/A-[/url]
[url="http://www.microsoft.com/germany/ms/unternehmensinformationen/historie.htm "]Mean cats eat parakeets![/url]

@Prefect: Ja, denke schon. Wäre zumindest am sinnvollsten. Jedenfalls kann man nen Computer durch nen anderen Computer simulieren, ein Computer ist also berechenbar -> geht also auch auf ner Turingmaschine. Wenn nicht, hast du Churches Gesetz geknackt =)

@Gollum: www.google.de -> Turingmaschine eingeben. Da findet sich astreines Material! Die hier is ganz vernünftig: http://www.dbg.rt.bw.schule.de/lehrer/ritters/info/turing/turing.htm

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

@prefect:
ich weiß garnit was du hast.
1: wie du selber gesagt hast, kann man RTTI ausschalten, also, was solls?
---
2: ausnahmen: was hast denn sonst für alternativen?

1. programm beenden. spitze. beende mal die software im kühlreaktor eines kernkraftwerkes einfach so,weil irgendwo ein fehler ist.
2. n fehlercode zurückgeben. hm, toll. hilft, um bugfixes zu schreiben. na, und mach das ma in 10min, wenn o.g. fall eintritt.
3. selber fehler-funktionen machen und im programm aufrufen. und hier setzt das ausnahmen-konzept von c++ an.
und das ist eigentlich nur dazu da, um zu wirken, wo du mit den anderen methoden nit mehr weiter kommst.
außerdem wird durch diesen mechanismus das ganze programm lesbarer, da exceptions explizit vom code getrennt sind.
und da isses bei realistisch großen programmen a bissel wichtiger, daß die monatelang durchlaufen können, und dafür halt n bissel größer und langsamer sind, als das sie ständig gewartet werden müssen und dafür schneller sind.#
---
3. von welcher implementierung gehst du da aus?
---
4. namespaces. was sind bei dir große programme? also, 4mio. zeilen code ist da durchaus drin. und es gibt systeme, die bieten keine dlls an. und wenn du ne wetterberechnungs-software machst, dann kannst meinetwegen aufspalten (machen die auch!), aber du brauchst immer noch eine unmenge code um wetterdaten darzustellen. und da machen namespaces echt sind, da du nicht gezwungen bist, dir für jede fkt nen anderen namen auszudenken, um sie eindeutig zu halten.
datenkapselung nennt man das, oder?
außerdem gibts zum abschalten immernoch die using-direktive
---
5. xxx_cast dient NUR dazu, daß typenkonzept von c++ da zu brechen, wo es notwendig ist. dafür sind sie da, und deswegen sind sie auch so häßlich zu schreiben (reinterpret_cast is numal gefährlich und deswegen lang, damit dus nit zu oft benutzt)
und so sicher sind c-casts auch nicht. vor allem sind c-casts unleserlicher, weniger explizit, als die von c++.
---
6. sprache und standard sind zu eng verknüpft. was soll denn das eigentlich heißen? hast dir mal die c++-VCL von borland angeguckt? wo isn da standard?
außerdem, woran läßt sich das erkennen?
und der eigentliche sinn des standards? zu STANDARTISIEREN?? was ist daran falsch, wenn viel mit einem internationalen einheitlichen standart gearbeitet wird, der protabilität von programmen, sowie deren lesbarkeit vereinheitlicht und erleichtert?
keiner zwingt dich, den standard zu benutzen. mach einfach nirgends ein include<> hin.
---
7. ich finde es sehr elegant, objekte über referenzen zu ändern. das ist ausdrucksstark! und was wird "void addiere_um_2( int &i )" wohl machen? den int in ruhe lassen, klar. dann isses ja auch ne sehr sinvolle funktion.
wenn ich son ding sehe, dann ist eigentlich klar, daß es was ändern wird.

so. :-)

Hm...

Zu 7.) Wenn ich was mit Call by reference in Parameterlisten lese, dann gehe ich NICHT davon aus, daß unbedingt etwas verändert wird. Kommt ja schließlich drauf an, WAS übergeben wird. Ne Primitive ist ja klar, die kann man entweder lesen oder verändern. Aber bei Objekten in C++ gehe ich nicht mehr davon aus, daß diese Objekte verändert werden sollen, vor allem nicht, wenn's ne konstante Referenz ist. Dann sieht das eher aus wie eine Übergabe eines Objekts, dessen Konstruktoren nicht aufgerufen werden sollen.

Außerdem ist C/C++ in keinster Weise irgendwie portabel. Reines C/C++ ja, aber der Funktionsumfang beschränkt sich dann auf die Sprache selber plus die C/C++ Runtime Libraries und die STL. Alles andere ist absolut plattformspezifisch (man bedenke die dos.h oder die conio.h). Also, was Portabilität anbetrifft, ist Java echt der Hammer. Sollte man nicht glauben, aber was man einmal in Java bastelt, daß funzt auf Solaris, UNIX, Linux, MacOS, OS/2Warp oder Windows überall gleich. Benutzt man noch Swing, dann ist sogar das Look-and-feel überall gleich =). Dumm nur, daß JITs nur in Browsern Verwendung finden. JITs als Standalones wäre mir da lieber, weil einige Dinge echt an der Performance nagen.

Das soll jetzt aber nicht heißen, daß ich meinem C++ untreu werde, nein nein =)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

portabilität heißt bei c++ nit, daß du den selben source auf jedem anderen system benutzen kannst, sondern daß du gleiche, auf verschiedenen systemen abgebildete routinen hast, die platform unabhängig verwendet werden können und, daß es relativ einfach ist, code zu portieren (vorausgesetzt er ist auch so gut geschrieben, daß eine portierung möglich ist).
die stl ist hierbei ein verdammt guter ansatz, sonst passiert das, was damals mit pascal passiert ist: mehrere versionen, die eigentlich nix miteinander zutun hatten. und das ist ehrlich mal mist.
und da heutzutage code nicht mehr nur geschrieben wird, um gleich wieder gelöscht zu werden (der muß verkauft und vertrieben werden!) braucht man halt standard-container und algorithmen.

c++ ist eh nicht das beste was gibt. aber es ist ne verdammt effektive sprache, wenns darum geht, riesige programme zu machen. und bei denen sieht auch das tolle c ziemlich alt aus, weil es weniger ausdrucksstark ist und probleme weniger explizit repräsentiert und dadurch schwerer zu warten ist.

und noch zu referenzen: ich find, man sollte nicht zu schlau mit den teilen umgehen, eben, damit jemand anders sich noch reinfitzt. <- das ist dann eben gutes (schnittstellen-)design...

Kerl, erzähl mir nix von Portabiliät und C++, daß ist mein täglich Brot (beinahe). Die Dogmata der Software Engineering sagen klar und deutlich, daß Portabilität die bestmöglichste Art und Weise für das Umsetzen eines Codes auf einer anderen Maschine darstellt.

Leider ist C++ in vielen Belangen nicht portabel. Angenommen, ich entwickel eine Klasse, die eine oder mehrere Threads nebenläufig behandeln soll. Dann ist schonmal klar, daß der Threadcode auf einem Windowssystem anders implementiert wird als auf einem UNIX/Linux-System. Und das ist eben die Krux, daß man vielzuviel Anpassungen vornehmen muß. Das fängt ja schon damit an, daß man auf den Standard-Windowssystemen in ASCII programmieren muß (von der MFC mal abgesehen), dagegen auf UNIX/Linux zwangsweise auf Unicode umsatteln muß. Das nervt aber tierisch, daß man andauernd zwischen char und t_wchar unterscheiden muß! Ich meine, als C entwickelt wurde, war UNIX auch kein Fremdbegriff und die durchgängige Implementierung von 16-Bit Zeichen wäre durchaus im Bereich des Möglichen gewesen. Das damals 16 Bit eine Domäne von Mainframes gewesen ist, war natürlich ein blöder Haken an der Sache...

Is ja auch egal, jedenfalls ist C++ im Vergleich zu Java extrem unportabel. Ich erinnere nur an solche als "deprecated" bezeichneten Schlüsselwörter wie far oder near für die Zeigerimplementierung auf 16 oder 32 Bit Rechnern. Genauso dumm wie die Tatsache, daß auf alten Rechner wie 286ern eine Adresse 16 Bit hatte (genau wie int) und ab 286ern 32 Bit sowohl bei Adressen als auch bei int Einzug gefunden hatten.

Ich bin sehr dafür, daß aus C++ irgendwann mal "D" wird und der ganze imperative Scheiß aus C wegfliegt. Dann hat man wenigstens bei der Portierung einige Joker in petto, die man bei C++ nicht hat...

Cu und n8

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

zu 1: Mir geht's da eigentlich mehr ums Prinzip. Ich dachte, das wäre deutlicher zu erkennen.

zu 2: Wie du selbst sagst, sind Rückgabewerte eine Alternative zu Exceptions. Auch in C-Programmen sind Fehler aufgetreten...
Übrigens... exception-Handlers sind nicht der Weisheit letzter Schluß. Wenn man mit ihnen nicht richtig umgeht, kann es durchaus weiterhin zu Problemen kommen (z.B. Null-Pointer oder nicht richtig initialisiertes Objekt). Und dann und wann gibt's ja auch Exceptions, die sich nicht so harmlos behandeln lassen, und bei denen man gezwungen ist, das Programm zu beenden.

zu 3: Ich verstehe die Frage nicht. Automatische Konstruktion globaler Daten benötigt _immer_ die Mitwirkung einer RTL, anders geht's einfach nicht. Es ist also keine Frage der Implementierung.

zu 4: Wenn jemand ein System ohne DLLs verwendet ist das denk ich mal die eigene Schuld. Außerdem gibt es auch immer noch die Option, statisch zu linken. Außerdem: C++ führt doch das Prinzip von OOP ein, und Klassen sorgen doch an sich schon für Datenkapselung. Jede weitere Kapselung wäre besser in Libraries aufgehoben.

zu 5: Ich habe nie gesagt, dass C-Casts sicher sind. Aber dass sie schwerer zu lesen sein sollen, als xxx_cast - das ist hoffentlich ein Witz, oder? Wenn ich nun z.B. von einem (char *) auf ein (short *) casten will, dann will ich da casten, und mich nicht mit dem Compiler herumschlagen, weil der unbedingt wissen will, ob ich nun dynamisch oder statisch caste, oder ob ich reinterpretiere. Das ist völlig unnütz.

zu 6: Du hast mich falsch verstanden. Ich bin nicht gegen eine Standardbibliothek, aber viele tun gerade so, als ob die Features der STL ein Feature von C++ wären, und das sollte eigentlich nicht so sein.

zu 7: Nicht alle Funktionen haben so aussagekräftige Namen wie addiere_um_2 (und wer codet eigentlich auf Deutsch ;)). Und wenn ich eine Variable auf diese Weise übergebe, dann sehe ich das im code nicht. Und hier liegt der Hund begraben. Wenn nun der Implementator der Funktion im stillen Kämmerchen beschließt, dass die Funktion das übergebene Objekt vielleicht doch verändern sollte, dann gute Nacht.

Zu der Portabilitätssache: Eine "reine" Sprache (also != Java ;)) ist genau dann portabel, wenn die Bibliotheken, die du verwendest portabel sind. Schluß aus ende. Wenn du pthreads verwendest, dann kommst du auf fast allen Systemen gut klar (auch auf Windows).

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hm, Java ist vollständig portabel, solange die JRE auf dem neuesten Stand ist =) Was bringt mir ein Applet in JRE 1.4, wenn IE 6.0 nur JRE 1.3.1 (wenn überhaupt) rafft. Das Problem bei Java ist ja, daß Java permanent weiterentwickelt wird. Jede neue Stufe des JDK und der JRE samt VM hat zur Folge, daß eine Aufwärtsinkompatibilität auftritt. Wenn man jedesmal auf ein Update der Browser warten müßte, wäre Java schon tot.

Egal, Java ist von allen mir bekannten Sprachen noch die Portabelste von allen.

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)