Junge Junge...

[Capt'N Coax]

...ich finds echt faszinierend.

C++ Gurus müssen echt Hardcore 370 Tage im Jahr "ICH PENN NICHT MEHR" Typen sein, deren einziger Sinn neben Scheißen, Essen, Trinken derjenige welche ist, sich Bücher in den Kopf zu stecken von Typen, die mindestens 371 Tage im Jahr C++ programmieren und sogar aufs Scheißen verzichten.

Wie zum Geier, kann mir das einer erklären, schafft es sonst einer, sich mit 3 Millionen Tretminen und 5 Millionen "Best tricks to write extensive wild pointer code and expensive memory leaks" auseinander zu setzen, ohne den Glauben an die Menschheit und den Typen zu verlieren, der diese Sprache entwickelt hat. Mein lieber Walpurgon, deine sieben Habitate gegen meinen Stroustrup.

Ich sitz' hier mit 5 Büchern (Eben jener Stroustrup, 2 * Scott Meyers, 1 mal der werte Herr Jamsa, falls ich Stroustrup's Formulierungen nicht verstehe, und, bitte nicht schlagen, C++ in 21 Tagen, wobei bemerkt sei, dass ich dieses Buch schon seit 98 besitze und es nie, NIE komplett gelesen habe) und...ich fang den Satz nochmal von vorne an.

Also, ich sitz' hier mit 5 Büchern die man den Autoren nach von absolut pillepalle bis relativ fortgeschritten bezeichnen kann, nur um zu merken das die Art und Weise wie mein Verständnis von C++ sich entwickelt hat größtenteils für die Tonne ist.

Auch diesen Satz formuliere ich am besten noch einmal um:
Bin ich zu doof für die Sprache oder lässt C++ einen absichtlich an seinem Verstand zweifeln? Ist die Sprache absichtlich so konstruiert worden, dass tausende von "Effektiver C++ programmieren" Büchern geschrieben werden können, ohne dass den Autoren auch nur annähernd der Stoff ausgeht?

Ich weiß jetzt warum es C++ Gurus soviel Spaß macht in eben dieser Sprache zu programmieren:
Es ist vergleichbar mit SM oder seltsamen Bondage Ritualen, vergleichbar mit komischen Riten merkwürdiger Eingeborenenvölker oder Leuten, die sich einfach gerne quälen, um am Ende Ihrer Leidensstrecke stolz zurückblicken zu können auf die vielen fantastilliarden Stunden, die sie mit dem Erlernen einer Sprache verbracht haben, welche man bestenfalls mit "tricky" umschreiben kann.
Man sollte, denke ich, allerdings nicht fragen, ob's sich gelohnt hat. Man sollte, denke ich ebenfalls, nicht darauf hinweisen, dass es besser konzipierte Sprachen gibt, die den selben Zweck ähnlich gut erfüllen könnten. Und ich sollte weiter meinen Speichermanager implementieren, von dem ich genau weiß, dass er mir mindestens drei Beine beim Kompilieren ausreißen wird, und 5 Arme, wenn ich versuche das Ding EFFEKTIV zu betreiben.
Aber irgendwie, ich weiß auch nicht, macht's ja schon Spaß :)

Wollte das nur mal loswerden,
Coax


ps.:
Fachfragen wie "Na dann sag mir doch vernünftige Alternativen zu C++, Klugscheisser" wird der geschätzte Autor nicht beantworten, weil er

a) keine Ahnung von anderen Sprachen außer Java hat, was kein vollständiger Ersatz ist, und
b) nicht den Schimmer einer Ahnung hat, warum er diesen Beitrag überhaupt verfasst hat, hat er doch

1., keine Ahnung von anderen Sprachen*, und
2., auch keinen entsprechenden Memberstatus, die anderen, ebenfalls hochgeschätzten Mitgliedern dieses Boards, mit dermaßen sinnlosen Kommentaren zu seiner Weltanschauung zu belästigen. *börps*


*außer Java

[hofmetzger]

Du forderst sinnlose Kommentare mit deinem Text doch irgenwie heraus ;)

Java mag ich nicht, die Sprache sitzt imho zwischen den Stühlen.
C++ kann ich. Kanns sehr wohl nicht freakig, aber es ist meist schnell genug (im Ggs. zu dem, was ich in Java fabriziere).
Python iss geil. Aber halt Skripsprache, so muss ich auf Stand-alones verzichten.
Delphi ist gut um was zusammenzuklicken.
Basic kann ich schon garnicht mehr.

Was hat C# so drauf?

[Coda]

Ja C++ ist komplex - aber das hat auch seine Vorteile ;)

"The right tool for the right job" ist die Devise. Wenn du keine Anwendung dafür hast, kannst du ruhig C#/Java oder andere RAD Sprachen verwenden.

Best tricks to write extensive wild pointer code and expensive memory leaksDa bist du aber mit C weit bessere berate als mit C++. Weil gescheiter C++ Code vermeidet sowas durch Design eigentlich. In C bist du gezwungen sowas zu schreiben - naja bis auf die memory leaks.

Auch diesen Satz formuliere ich am besten noch einmal um:
Bin ich zu doof für die Sprache oder lässt C++ einen absichtlich an seinem Verstand zweifeln? Ist die Sprache absichtlich so konstruiert worden, dass tausende von "Effektiver C++ programmieren" Büchern geschrieben werden können, ohne dass den Autoren auch nur annähernd der Stoff ausgeht?Hihi. Du hast schon irgendwie recht - es gibt erst seit kurzem überhaupt Compiler die die Sprache ganz implementieren.

Ach ja: Es gibt auch durchaus Dinge die mit Java eklig sind. Z.B. Vektorklassen ohne Operatorenüberladung.

[Capt'N Coax]

Du forderst sinnlose Kommentare mit deinem Text doch irgenwie heraus ;)
So sollte es auch sein ;)


[...]
Was hat C# so drauf?
Ich hab's nur mal wirklich kurz getestet. Tendiert IMO wirklich sehr stark zu Java, was die Technologie ja auch impliziert. Hat mir aber recht gut gefallen, .NET trägt da natürlich auch zu bei. Eine Gui hat man sich mit VS .Net ruppzupp zusammengeklickt. Das nervt bei Java irgendwie, schreibe den Code da aber auch von Hand, weil mir das Eclipse Plugin nicht so wirklich gefallen hat (Ich steh' halt auf Eclipse :)). Naja, Layout Manager Ahoi. Sollte mir bald mal ein paar gute 3rd Partys raussuchen.


Ach ja: Es gibt auch durchaus Dinge die mit Java eklig sind. Z.B. Vektorklassen ohne Operatorenüberladung.


Was wirklich VIELE Leute kritisieren. Aber Leute nicht vermissen, die nur Java kennen. Stichwort: Mehrfachvereerbung...

[Demirug]

Ja C++ ist komplex - aber das hat auch seine Vorteile ;)

Die aber irgendwie immer weniger werden.

[Capt'N Coax]

Ja C++ ist komplex - aber das hat auch seine Vorteile ;)
[...] Weil gescheiter C++ Code vermeidet sowas durch Design eigentlich.

Das Problem ist das Erreichen einer Stufe, auf der man seinen Code als geschickt bezeichnen kann.

Ich hatte schonmal in C++ programmiert, so gegen 98, dann 2002/03, dann fast nur Java, jetzt wieder C++ (dafür intensiver).

Das Problem ist IMO, das wenn man beruflich nicht unbedingt 8 Stunden am Tag C++ programmiert, es schwierig ist, sich "geschickte" Programmierung anzueignen.

Jeder gute Programmierer wird dir in seiner Lieblingssprache spontan 20 Regeln aufsetzen können, die UNBEDINGT beachtet werden müssen.

In den meisten Büchern, Vorlesungen etc. pp. wird einem beigebracht, wie man die Syntax korrekt implementiert und wie man simple Algorithmen angeht. Was schlicht nicht gelehrt wird, ist auch nur annäherungsweises KORREKTES Programmieren.

Ich weiss das eine der goldenen Regeln besagt, dass man sich als Programmierer selbst entwickeln muß. Allerdings ist man nach oder während eines solchen Evolutionsprozesses geneigt, die Qualität solcher Veranstaltungen in Frage zu stellen.

3 GUTE Bücher sind mehr wert, als jede Vorlesung/ jeder Unterricht, dem ich bis jetzt beiwohnen durfte.

Ein Beispiel sind die Implementation von Copy-Konstruktoren und Zuweisungsoperatoren, und daraus die resultierenden Fehler, sollte man diese unter Umständen nicht selbst erstellt haben oder sich wenigstens daraus resultierende Verhaltensweisen verdeutlicht haben.

Das Verhalten einer solch (schlecht) implementierten Klasse ist schlicht undefiniert. Weil man nicht weiß, was intern geschieht. WICHTIGES Hintergrundwissen wird schlicht übergangen, aus welchen Gründen auch immer. Allerdings fehlen selbst die Hinweise zu solchen Problematiken in fast jedem Buch und erst recht in fast jeder Vorlesung etc. DAS ist schon etwas traurig.

Aber ich wollte eigentlich nicht über das Ausbildungsystem jammern. Mir ging es nur darum zu betonen, dass C++ nicht unkritisch ist, wenn man es versucht nach Schulsystem zu programmieren.

[EgonOlsen]

Jeder gute Programmierer wird dir in seiner Lieblingssprache spontan 20 Regeln aufsetzen können, die UNBEDINGT beachtet werden müssen.Ja, aber jeder 20 andere... :biggrin:

[Grestorn]

So schlimm finde ich C++ gar nicht.

Im Gegensatz zu Java und C# muss man sich an jeder Programmstelle nur immer im Klaren sein, ob man für eine Instanz selbst verantwortlich ist (und sich deswegen auch um deren Bereinigung kümmern muss) und ob man mit einer Kopie einer Instanz arbeitet oder ob man lediglich einen Pointer auf eine fremdverwaltete Instanz hat.

Um diese Fälle zu unterscheiden, muss der Code gezielt dokumentiert sein und man sollte sich an einige Namenskonventionen halten. "constness" hilft auch enorm.

Ein Beispiel für eine solche Konvention: GetBlaBla"-Routinen liefern einen Pointer auf etwas, das mir aber nicht gehört. Soll ich das auch nicht verändern können, sollte die Get-Routine einen const-Pointer liefern.

"CreateBlaBla"-Routinen liefern mir eine Kopie von etwas. Das muss ich selbst freigeben und kann alles damit machen.

Innerhalb einer Klasse(-nbibliothek) sollte man sich auf eine Philiosophie einigen. Also entweder die Klassen machen alles über Kopien, arbeitet intensiv mit Copy-Konstruktoren, operator= und Clone-Funktionen. Im Desktuktor wird bei Collection-Klassen alles mit freigegeben (Agregat) usw.

Das kostet Performance, aber wenn man es durchhält sorgt es für stabilen Code.

Oder man entscheidet sich für die "so wenig Kopieren wie möglich"-Philosophie. Auch da kann es Copy-Kontruktoren geben, aber man vermeidet die möglichst. Es werden Pointer, keine Kopien geliefert. Und der Client entscheidet selbst, wenn es notwendig wird, eine Kopie anzulegen und arbeitet sonst direkt mit der Original-Instanz.

Diese Philiosophie ist oft deutlich performanter, erfordert aber deutlich mehr Aufmerksamkein und Sorgfalt vom Programmierer um Speicherlecks und Crashes zu vermeiden.

Von den anderen Dingen, die C++ wirklich kompliziert machen - Templates z.B. - will ich erst mal nicht anfangen... :)

Unterm Strich bleibt: Ja, C++ ist deutlich komplexer und schwerer als C# oder Java. Aber es ist letztlich viel Transparenter, der Programmierer weiß immer genau exakt was passiert. Das ist bei anderen Sprachen oft nicht der Fall.

Genau deswegen spricht man bei C++ ja auch von der hardwarenächsten Hochsprache.

[maximAL]

Unterm Strich bleibt: Ja, C++ ist deutlich komplexer und schwerer als C# oder Java. Aber es ist letztlich viel Transparenter, der Programmierer weiß immer genau exakt was passiert.
na, wenn man erstmal verzweifelt wild pointer jagt... :wink:
klar kann man viele probleme vermeiden, aber das macht auch ne menge arbeit...

[Coda]

na, wenn man erstmal verzweifelt wild pointer jagt... Valgrind, etc. machen daraus eine Aktion von weniger als einer Minute wenn's gut läuft. Erstens bekommt man memleaks sofort angezeigt, zweitens weiß man auch an welcher Stelle sie entstanden sind.

Natürlich ist ein GC angenehmer, aber auch da muss man auf Dinge achten, die vielen nicht bewusst sind.

Ich muss aber dazu sagen, dass ich auch recht lange gebraucht habe bis ich in C++ gut zurecht gekommen bin.

[Senior Sanchez]

Ich bin gerade am versuchen C++ zu lernen (hatte schon nen paar anläufe) und versuche mich momentan am Buch "C++ in 21 Tagen" (ich lasse mir aber mehr zeit). Die erste Woche war eigentlich ziemlich pillepalle, mal sehen wie die nächste wird.

Wie ist dieses Buch aber ansich einzuschätzen? Eher schrott oder doch zu gebrauchen?

[micki]

Die aber irgendwie immer weniger werden.
weil die leute verlernen damit umzugehen und hoffen dass ihnen der compiler bei allem den ar.... abwischt.

MfG
micki

[ScottManDeath]

boost (http://www.boost.org) macht das Leben um einiges leichter, insbesondere die SmartPointer (mit all ihren möglichen Nachteilen) erleichtern das Memorymanagement doch um einiges.

[Demirug]

weil die leute verlernen damit umzugehen und hoffen dass ihnen der compiler bei allem den ar.... abwischt.

MfG
micki

IMHO liegt es eher daran das die Konkurenz besser wird. Es ist nur logisch das C++ irgendwann genauso verdrängt wird wie es selbst C verdrängt hat.

[micki]

IMHO liegt es eher daran das die Konkurenz besser wird. Es ist nur logisch das C++ irgendwann genauso verdrängt wird wie es selbst C verdrängt hat.
c wurde nicht verdrängt sondern um ein ++ ergänzt. die konkurenz ist 'anders', aber nicht besser. es ist zwar eindeutig zu sehen, dass gerade anfänger mit der konkurenz besser zurechtkommen, aber jemand der sich wirklich mit der sache auskennt (und nicht nur stumpf code eintippt) und genauen weiß was hinten am compiler auch rauskommt, fährt besser mit c++.

das Dilemma ist leider, dass die anfänger mal c++ ausprobieren und dann einen der neuen konkurenten und sehen, dass der konkurent ja soviel schnellere libs hat, als was sie mit c++ gemacht haben und überschlagen von der ganzen menge an fertigen libs, setzt sich sojemand nicht mehr an c++ um es einmal ordentlich zu machen. nur deswegen schnippel die meisten studis mit java oder c# rum.

ein weiteres Dilemma ist, dass man jemandem nicht ansehen kann wie gut er mit c++ zurecht kommt, deswegen weiß die personalabteilung erstmal garnichts außer "er kann c++... sagt er".
bei den konkurenten kann man jeden studenten der ein wenig OOP gelernt hat nehmen und ihn mal eben stumpfarbeiten durchführen lassen, z.B. Datenbank tools und muss sich nicht wirklich sorgen, dass er zuwenig erfahrung hat um es ordentlich zu machen dank z.b. den dau-collectors ;)

das schlimme ist, wenn ich mir sowas wie "code of the day" bei flipcode ansehe, von den ganz 1337-h4x0rn und sie es schaffen einen 3ds loader in c++ zu schreiben, es ihnen aber nicht auffällt, dass bei den ganzen "new" nicht ein einziges "delete" vorhanden ist, würde ich auch jeden den ich mal einstellen sollte zwingen die 'konkurenz' zu benutzen.


aber gerade deswegen ist jemand der wirklich gut c++ kann (nicht einfach nur libs kennt die er suboptimal anwenden könnte) teuer und gut ;), auf der anderen seite sollte man sich nicht gegen die konkurenz stellen, sondern sie als highlevel scripting einbauen, ich denke das ist die zukunft.
die die das können, können den core in c++ schreiben und haben über alles kontrolle und die die dann content generieren müssen, schnell und günstig, die dürfen sich dann mit highestlevel scripting beschäftigen.
wenn ich für die spielebrange sprechen darf, würde ich sagen, es wäre optimal wenn mittels einer engine 99% der arbeit von graphikern und gamedesignern/-scriptern gemacht wird und nur noch ein programmierer für support und kleinigkeiten (z.b. komplexere scripte oder script-lib) zuständig ist.

MfG
micki

[noid]

c++ richtig schreiben und programmieren sind 2 paar schuhe.

um eleganten, modularen code mit wiederverwendbarkeit zu schreiben benutzt man design patterns etc. das lernt man am anfang aber nicht, sondern kommt unter umständen irgendwann mal dazu.
kann auch nicht jeder, was die guten (die die sowas anwenden ohne nachzudenken) von den schlechten trent.

[Coda]

das schlimme ist, wenn ich mir sowas wie "code of the day" bei flipcode ansehe, von den ganz 1337-h4x0rn und sie es schaffen einen 3ds loader in c++ zu schreiben, es ihnen aber nicht auffällt, dass bei den ganzen "new" nicht ein einziges "delete" vorhanden ist, würde ich auch jeden den ich mal einstellen sollte zwingen die 'konkurenz' zu benutzen.Also auf Flipcode treiben sich imho immer noch die fähigeren Leute rum. Nach sowas müsste man eher bei Gamedev fahnden ;)

[Hardwaretoaster]

Ich will ja jetzt nicht nerven, aber:
Ich hatte vor, mich in den Ferien mal etwas mit c++ zu beschäftigen, um wenigstens die Grundzüge zu kennen, momentan kann ich nur delphi.
Ein Teil hat mich doch etwas verschreckt, kann mir jemand einen Tipp geben, welches Buch/welche Bücher für den Anfänger gut zu bewältigen sind?

[Senior Sanchez]

Ich will ja jetzt nicht nerven, aber:
Ich hatte vor, mich in den Ferien mal etwas mit c++ zu beschäftigen, um wenigstens die Grundzüge zu kennen, momentan kann ich nur delphi.
Ein Teil hat mich doch etwas verschreckt, kann mir jemand einen Tipp geben, welches Buch/welche Bücher für den Anfänger gut zu bewältigen sind?

Ich würde mich nicht unbedingt als Anfänger bezichtigen (mehr als Fortgeschrittener), aber ich arbeite momentan mit dem Buch "C++ in 21 Tagen". Leider habe ich zu diesem noch keine Meinung aus der Community vernommen, aber ich komme damit recht gut klar, wenn gleich vieles für mich pillepalle war/ist. Aber die schweren Sachen kommen ja noch ;)

[Coda]

Pillepalle?

http://spirit.sourceforge.net/distrib/spirit_1_8_2/boost/spirit/tree/common.hpp

...

[Senior Sanchez]

Pillepalle?

http://spirit.sourceforge.net/distrib/spirit_1_8_2/boost/spirit/tree/common.hpp

...

Hast du meinen Post genau gelesen?
Was ich mit pillepalle meine, war das, was ich bisher in dem Buch durchgearbeitet habe und das waren so Dinge wie Variablen, Konstanten, Elemente zur Programmsteuerung, Klassen (noch ohne Vererbung)..... also noch keine Zeiger, keine Templates, kein Operatorüberladen, keine Polymorphie, kein STL etc. ;)

Und was ich da nannte, ist größtenteils z.B. mit Java identisch. Gut Klassen, weichen etwas ab, aber es ist nicht wirklich schwer zu begreifen, wenn man Java beherrscht.

[darph]

Was schlicht nicht gelehrt wird, ist auch nur annäherungsweises KORREKTES Programmieren.Duz stimmt so nicht ganz. Hier in Passau gibt es eine Vorlesung "Software Engineering" (Pflicht im Grundstudium) und daraufhin ein Praktikum, welches sinnigerweise Software Engineering Praktikum heißt. Für die Zulasung dafür braucht man ein "Praxis der Programmierung" Praktikum, und dort wird (Praktomat (http://sourceforge.net/projects/praktomat/) sei Dank) jedes verdammte Leerzeichen, das von den Java Code Conventions (wir machen hier nur Java) abweicht, negativ bewertet. Abgesehen davon wird dann eben auch der Programmierstil bewertet, also nicht nur die Funktionalität. Klar, nichts gegen exzessive Praxiserfahrung, wie du schon sagtest, aber man versucht es wenigstens.

[icemanemp]

Sag ich auch mal was dazu, auch wenn es keine interessiert ;)

@Hardwaretoaster
Es reicht ein Anfängerbuch, damit du die Unterschiede bemerkst und verstehst und natürlich viele neue Dinge komplett lernst. Erst wenn du die Basics von C++ kannst würde ich mich an spezielle Themen wagen. Delphi macht dir vieles sehr einfach wie Objektbehandlung. Oder sehr viele Klassenkonstruktionen gibt es in Delphi gar nicht. Delphi hat hier eine sehr einfach Klassensyntax (Vererbung, Polymorphie). C++ hat hier einige Dinge mehr die du z.B. mit Klassen machen kannst, aber nicht musst.
Hier sagt einer doch z.B. c++ in 21 Tage. Wenn net nimm das. Die C++ Gurus können dir wahrscheinlich schwer helfen bei deinen Vorkenntnissen mit Delphi.
Kommt eben noch drauf an wie gut du Delphi kannst! Viele können mal eben Programm zusammenbauen, aber bei Themen wie Klassen, Vererbung, Verwaltung der Objekte, eigenen Ereignisse, Ereignissbehandlung, Threading und was es sonst noch so alles gibt, haben viele unterschiedliche Erfahrungen. Viele Bücher behandeln aber auch alle besprochenen Themen und noch mehr.

@micki
Dein Konzept stellt sich jeder Arbeitgeber vor!
Am besten sollen so wenig wie möglich Leute an einem Programm arbeiten. Die Arbeiter Geld kosten. Z.B. nur die, die viel Ahnung von kaufmännischen Dingen haben die Software mal schnell per Skripting und visuellen Entwicklungstools zusammenbauen! Kommt auf etwa das selbe raus wie bei den modernen Entwicklungsmethode, die einen Programmierer durch leicht pflegbaren und immer gleichen Quellcode (Quellcodeformatierungsstandards) austauschbar/ersetzbar machen.
Wäre aber leider das Ende für sehr viele Programmierer. Wenn so was fertig wäre, dann bräuchte man ja gar keine Programmierer mehr...
Das Problem deiner Vision und vieler anderer wird sein so eine Engine bzw. seine eigene Programmiersprache bzw. Programmierumgebung in die vorhandene Software umzusetzen! Kommt darauf an wie komplex die Geschichte werden soll, wenn nicht sehr komplex, dann werden aber deine 99% bei weitem nicht erreicht. Wenn man die 99% abdecken will, dann braucht man bestimmt nicht nur eben so 30-40 Programmierer und eine perfekte Softwareplanung mit Anwendung aktueller Softwareentwicklungsmethoden, sondern schon sehr viele mehr Ressourcen! Schätze ich!

[Hardwaretoaster]

@icemanemp
so groß sind meine DelphiKenntnisse nicht, eher nur praktisch, Theorie war bis jetzt fürdie Schule nicht notwendig, aber ich denke, wenn ich die Grundlagen in C++ hab', klappt auch das andere eher, weil wohl dort nicht mehr so streng getrennt wird, c++ soll da ja sehr strikt sein.

[Coda]

Wäre aber leider das Ende für sehr viele Programmierer. Wenn so was fertig wäre, dann bräuchte man ja gar keine Programmierer mehr...So etwas wird es nie geben.

[Trap]

IMHO liegt es eher daran das die Konkurenz besser wird. Es ist nur logisch das C++ irgendwann genauso verdrängt wird wie es selbst C verdrängt hat.
Die Konkurrenz wird besser? Naja, sie wird C++ ähnlicher, sowohl an Features als auch in der Komplexität.

[icemanemp]

@Hardwaretoaster
Hört sich so an, als ob ihr nur mit der Maus auf Komponenten OnClick-Ereignisse benutzt habt um Text in Listboxen aufzunehmen oder Texte umzudrehen... So Standard Delphi-Anfänger Tutorialdinge halt... Oder lieg ich falsch?

Tja Programmiersprachen in der Schule sind für den A....
Ist es ja besser PAP's verstehen und zeichnen zu lassen.

Aber wenn du C++ komplexer Sachen kapierst, kommt dir Delphi wie ne Skriptsprache vor. Wobei man mit Delphi auch schöne Sachen machen kann. Muss es ja verteidigen ;) aber gibt ja sogar Software mit der Unternehmen Millionen verdienen die auf allen möglichen Sprachen geschrieben wurden z.B. auch Delphi ;)

@Coda
Sry. Stimmt so nicht von mir der Satz! Wie eine alter Assemblerhase bei uns sagte: "Es gibt keine fertige Programme! Wenn ein Programm fertig ist und bugfrei, dann ist es veraltert!".

[micki]

@micki
Dein Konzept stellt sich jeder Arbeitgeber vor!
Am besten sollen so wenig wie möglich Leute an einem Programm arbeiten. Die Arbeiter Geld kosten. Z.B. nur die, die viel Ahnung von kaufmännischen Dingen haben die Software mal schnell per Skripting und visuellen Entwicklungstools zusammenbauen! Kommt auf etwa das selbe raus wie bei den modernen Entwicklungsmethode, die einen Programmierer durch leicht pflegbaren und immer gleichen Quellcode (Quellcodeformatierungsstandards) austauschbar/ersetzbar machen.
Wäre aber leider das Ende für sehr viele Programmierer. Wenn so was fertig wäre, dann bräuchte man ja gar keine Programmierer mehr...
Das Problem deiner Vision und vieler anderer wird sein so eine Engine bzw. seine eigene Programmiersprache bzw. Programmierumgebung in die vorhandene Software umzusetzen! Kommt darauf an wie komplex die Geschichte werden soll, wenn nicht sehr komplex, dann werden aber deine 99% bei weitem nicht erreicht. Wenn man die 99% abdecken will, dann braucht man bestimmt nicht nur eben so 30-40 Programmierer und eine perfekte Softwareplanung mit Anwendung aktueller Softwareentwicklungsmethoden, sondern schon sehr viele mehr Ressourcen! Schätze ich!
naja, mit programmierern meinte ich halte die, die den core schreiben. die scripter bzw c# leute, die nur noch highest level zeug machen, werden dann natürlich in massen und billig sein. gibt ja jetzt schon genug firmen die studenten nur noch unbezahlt praktikum machen lassen, die dann aber genau dasselbe wie sonst bezahlte arbeitskräfte machen.
klar ist es extrem aufwendig so einen guten core zu entwickeln, natürlich! das beste beispiel ist die unreal engine. dort sitzen die nur daran soeinen core zu entwickeln und kaufen alle anderen auf damit es auch der einzige gute ist. wie gut der core ist sieht man daran wie einfach es ist für hobby mod-programmierer ein spiel zu machen, natürlich auch für proffesionelle teams. während der aufwand jedes jahr sehr viel größer wird, können die teams klein bleiben, weil die engine viel kompensiert. das zeigt auch trotz des preises der verkaufserfolg der engine. für die 250 000$ die du mindestens dafür zahlst, bekommst du mehr als dir 10enginecoder in einem jahr coden würden und es ist günstiger. du kannst ein level für ein spiel zusammenstecken, relativ unabhängig davon was für ein spiel du machen möchtest, die level mit lauter events vollstopfen und mit scripts steuern, coder brauchst du nicht sonderlich viele dafür.

auf programmierer wird man nie verzichten können, aber das sieb das den core von den c#/java/js/lua... codern trennt wirt immer schärfer und ich kann mir nicht vorstellen, so nett es auch sein mag bei z.b. c# alles nötige fertig als lib serviert zu bekommen ohne jemals z.b. einen balanced Tree implementiert zu haben, dass es eines informatikers traum ist einer von tausenden in seiner 1m*1m celle zu sein mit wenig aussicht auf besserung weil er durch jeden anderen studierten austauschbar wäre.
ich könnte mir aber vorstellen dass im gegenzug viele gerne als einer der wenigen programmierer bei epic an der engine arbeiten würden.



MfG
micki

[Neomi]

Die meisten "Vorteile" anderer Sprachen gegenüber C++ sind doch nur Einschränkungen gegenüber C++. Die fehlenden Einschränkungen werden allerdings erst dann zum Nachteil, wenn ein unachtsamer Programmierer dadurch sein Zerstörungspotential entfalten kann. Es gibt einfach viel mehr Möglichkeiten, etwas falsch zu machen. Richtig genutzt dagegen verwandeln sich diese potentiellen Nachteile in mächtige Werkzeuge, von denen so manch andere Sprache nur träumen kann.

[icemanemp]

auf programmierer wird man nie verzichten können, aber das sieb das den core von den c#/java/js/lua... codern trennt wirt immer schärfer und ich kann mir nicht vorstellen, so nett es auch sein mag bei z.b. c# alles nötige fertig als lib serviert zu bekommen ohne jemals z.b. einen balanced Tree implementiert zu haben, dass es eines informatikers traum ist einer von tausenden in seiner 1m*1m celle zu sein mit wenig aussicht auf besserung weil er durch jeden anderen studierten austauschbar wäre.

Wenn du dir alle neue Entwicklungsmethoden anschaust, dann ist das leider so, das Programmierer bald keine Spezialisten sein werden. Aber zum Glück dauert das noch länger, so lange bis alle Firmen, diese Methode einsetzen und alte Programmiersprache mit dazugehörigen Betriebssystem usw. aussterben.
Manche Zukunftsfilme weichen doch gar nicht von der uns bevorstehenden Realität ab... (aber das geht jetzt zu OT). 1x1m reicht doch aus für das Arbeitervolk :)

@micki
Mit dem Beispiel Epic triffst du es nicht finde ich. Epic ist leider nicht Godfather of Gameprogramming. Grafikengines wird es genug geben... Konkurrenz belebt das Geschäft und das ist gut so. Natürlich ist es schön, das man dann weniger Arbeit hat mir Highlevel-Programmierung, aber heutzutage sieht man eben noch vielen Spielen an das sie auf bestimmten Engines basieren, wenn man 3-4 Spiele mit der gleichen Engine gesehen hat.

@Thema
um was ging es eigentlich nochmal konkret? :)

[grakaman]

naja, mit programmierern meinte ich halte die, die den core schreiben. die scripter bzw c# leute, die nur noch highest level zeug machen, werden dann natürlich in massen und billig sein.

Wer über ein gutes Verständnis von C#, VB oder Java verfügt, für den sollte imo der Umstieg auf C++ dann relativ leicht fallen. Und bei vielen Dingen braucht man auch bei .NET API Calls oder COM Interop, wenn Funktionalitäten benötigt werden, die eben nicht 0815 out of the box sind. Und richtig effizient arbeitet man imo auch nur, wenn man zumindest ein relativ umfangreichen Überblick über ein gesamtes Framework hat.

[maximAL]

Die meisten "Vorteile" anderer Sprachen gegenüber C++ sind doch nur Einschränkungen gegenüber C++. Die fehlenden Einschränkungen werden allerdings erst dann zum Nachteil, wenn ein unachtsamer Programmierer dadurch sein Zerstörungspotential entfalten kann. Es gibt einfach viel mehr Möglichkeiten, etwas falsch zu machen. Richtig genutzt dagegen verwandeln sich diese potentiellen Nachteile in mächtige Werkzeuge, von denen so manch andere Sprache nur träumen kann.
dummerweise schmeissen bücher, tutorials, andere programmierer etc. nur so mit "gefährlichen" sachen um sich, sodass man gerade als anfänger kaum daran vorbei kommt.
zudem gibts natürlich auch echte verbesserungen, wie garbage collectors, pattern matching, moderne typsysteme (was C++ eher dürftig mit den templates zu kompensieren versucht) etc.

[Ganon]

Ich finde Objective-C(++) immer noch am schönsten. :D Aber das sagte ich, glaube ich, schon mal wo anders. *ggg*

[Coda]

Das must du auch, sonst wärst du kein Apfelmensch :tongue:

[Ganon]

Ne, aber auch mal jetzt nicht als MacUser gesprochen. Objective-C ist wirklich schön. :)

[Coda]

Ja - vor allem schön langsam :biggrin:

[Ganon]

Merke ich nix von :P

;)

[Neomi]

zudem gibts natürlich auch echte verbesserungen, wie garbage collectors, pattern matching, moderne typsysteme (was C++ eher dürftig mit den templates zu kompensieren versucht) etc.

Der einzige "Vorteil" eines direkt integrierten Garbage Collectors gegenüber einem in C++ implementierten ist der, daß der... sagen wir mal "Programmierer" ihn nicht umgehen kann. Ich halte es eher für einen Fehler, den Leuten zu erlauben, ihren Speichermüll einfach im System liegen zu lassen. Schlechter Stil.

Pattern Matching sagt mir zwar was, aber warum sollte man solche Algorithmen nicht auch per C++ umsetzen können? Oder meinst du irgend ein Sprachfeature und nicht nur vordefinierte Funktionen? Bei den modernen Typsystemen brauche ich auch erstmal ein Beispiel.

[Coda]

Merke ich nix von :P

;)Der Klassenoverhead ist auf jedenfall enorm durch das ganze extreme RTTI Zeuch. Ist natürlich auch praktisch...

Trotzdem finde ich die Sprache vom Aufbau nicht sehr schön, weil das Objektive Zeuch nicht richtig integriert sondern eher aufgesetzt wirkt.

zudem gibts natürlich auch echte verbesserungen, wie garbage collectors, pattern matching, moderne typsysteme (was C++ eher dürftig mit den templates zu kompensieren versucht) etc.
Es gibt GC Implementierungen für C++ (Boehm GC)
Pattern matching ist ein library feature und z.B. in boost vorhanden.
C++ hat auch RTTI; Templates sind ein ganz anderes Konzept.

[icemanemp]

Der einzige "Vorteil" eines direkt integrierten Garbage Collectors gegenüber einem in C++ implementierten ist der, daß der... sagen wir mal "Programmierer" ihn nicht umgehen kann. Ich halte es eher für einen Fehler, den Leuten zu erlauben, ihren Speichermüll einfach im System liegen zu lassen. Schlechter Stil.

Ich weiss nicht wie das unter Java ist, aber unter .Net gibt es doch Situtationen in denen du per Hand zerstören musst, da der GC irgendwelche Abhängigkeiten zwischen Objekten nicht auflösen kann und dann das eine vor dem anderen zerstört.

Da ich nur Zerstörung von Hand kenne, kann ich über Vorzüge von GC nichts erzählen. Kenn nur die verschiedenen Arten von GC's aus Java. Da muss man dann nämlich noch aufpassen, das bei Echtzeit-Anwendungen der GC net zu viel % vom CPU-Durchsatz frisst. Bei Mehrprozessorsystem ist das ohne eingreifen von aussen, dann verherrend.

Naja was man durcheinander gemacht hat räumt man auch wieder auf ;)

[grakaman]

Ich weiss nicht wie das unter Java ist, aber unter .Net gibt es doch Situtationen in denen du per Hand zerstören musst, da der GC irgendwelche Abhängigkeiten zwischen Objekten nicht auflösen kann und dann das eine vor dem anderen zerstört.

Du kannst bei .NET ein Objekt nicht explizit zerstören. Du kannst höchstens seine Referenz löschen, damit es unter Umständen schneller collected wird oder eben den GC anweisen jetzt zu collecten. Aber manuell kannst du das nichts zerstören.

[Ganon]

Der Klassenoverhead ist auf jedenfall enorm durch das ganze extreme RTTI Zeuch. Ist natürlich auch praktisch...

Trotzdem finde ich die Sprache vom Aufbau nicht sehr schön, weil das Objektive Zeuch nicht richtig integriert sondern eher aufgesetzt wirkt.


War mir schon klar. ;)

Nunja. Das "Objective-Zeugs" wirkt sicherlich aufgesetzt, weil man Nachrichten an Objekte schickt. Das Ganze ist im Prinzip ja nur ein "Front-End" zu der C-Routine obj_msg() (oder so ähnlich, ist schon spät ;)).

Was natürlich die Sache auch extrem flexibel macht, wie z.B. mit dem Datentyp "id" oder Nachrichten an "nil".

Klar. Für High-Performance-Entwicklungen ist ObjC nicht geeignet. Dafür umso besser für "normale" Anwendungen, wie man ja an OS X sieht (ohne jetzt weiter darauf einzugehen, das wäre OT).

[maximAL]

Pattern Matching sagt mir zwar was, aber warum sollte man solche Algorithmen nicht auch per C++ umsetzen können? Oder meinst du irgend ein Sprachfeature und nicht nur vordefinierte Funktionen? Bei den modernen Typsystemen brauche ich auch erstmal ein Beispiel.
ich hab mir mal eben ein blödes beispiel aus dem anus gezogen:
type animal = Dog | Cat;;

let rec sort_out l a = match l with
[]->[] |
(h::t)->( match h with
x when x=a->sort_out t a |
_->h::sort_out t a );;
(layout will nicht anders :P )
nun, was das ganze tut sollte wohl klar sein.
aus einer liste des types animal eine tierart aussortieren und die verbleibende liste zurückgeben.
pattern matching: l, die liste, wird erst [] geprüft, also ob die liste lehr ist, wenn nicht, wird sie gegen (h::t) geprüft, also ob es eine liste mit kopf und schwanz ist (wobei auch gleich h für den kopf und t für die restliste deklariert wird)
haben wir eine liste mit kopf, wird der kopf gegen einen "beliebigen" wert gematcht, also x=h gesetzt und dieser mit when geprüft, ob er gleich dem auszusortierenden animal a ist.
_ ist ein wildcard-pattern, wenn sonst nichts geht -> das geht immer
der rest dürfte klar sein

typsystem: ich glaube polymorph will es genannt werden, hab da schon mehrere bezeichnungen gelesen.
jedenfalls sollte auffallen, dass man nirgendwo angibt, welchen typs die parameter l und a sein sollen. das findet der compiler allein raus. l ist eine liste, weil man es gegen eine leere liste [] matcht.
a ist erstmal "irgendwas". wenn man das ganze dann mit einer liste von animals aufruft und ein animal zum aussortieren übergibt, weiss der compiler auch den typ von a (und das l nicht irgendeine, sondern eine liste des typs animal sein muss). man kann das ganze somit für alle möglichen listen verwenden, genau wie ein template.

wie gesagt, nur ein kleines bespiel. gerade das typsystem gefällt mir. zb. einfach in einer funktion ein tripel (x,y,z) zurückgeben können, ohne erst irgendwo eine passende struktur definieren zu müssen (oder sich das auch irgendeiner lib zu klauben) ist im programmieralltag sehr angenehm.

@coda: klar gibts alles mögliche irgendwo in libraries. aber ich sehe doch noch einen gewaltigen unterschied zwischen dem nutzen von standard features und sich irgendwo irgendeine library zu organisieren, die die meissten programmierer noch nie benutzt haben.

[Coda]

Klar. Für High-Performance-Entwicklungen ist ObjC nicht geeignet. Dafür umso besser für "normale" Anwendungen, wie man ja an OS X sieht (ohne jetzt weiter darauf einzugehen, das wäre OT).Qt lässt grüßen. Obwohl das ja auch C++ Erweiterungen definiert.

[Neomi]

ich hab mir mal eben ein blödes beispiel aus dem anus gezogen: ...

Das mag ja durchaus eine tolle Sprache sein und ohne die genauer zu kennen, will ich auch nicht schlecht darüber reden, aber für mich wär das nichts.

Ich bin eher der Typ Programmierer, der den Typ für eine Variable bestimmen will, anstatt die Entscheidung dem Compiler zu überlassen. Ich halte es für ein Unding, eine Definition einem (egal wie guten) Stück Software zu überlassen. Ich wehre mich ja sogar gegen jede Deaktivierung von Compilerwarnungen. Die sollte man nicht per Option loswerden, sondern durch Codebereinigung. Und auch Speicher sollte liebevoll behandelt werden. Wer schon einen Speicherblock in die Welt setzt, sollte wenigstens soviel Anstand zeigen, sich unmittelbar vor dessen Ableben noch persönlich zu verabschieden.

[maximAL]

Ich bin eher der Typ Programmierer, der den Typ für eine Variable bestimmen will, anstatt die Entscheidung dem Compiler zu überlassen.
wenns dir spass macht, kannst du den typ auch explizit angeben.
aber templates fallen für dich dann wohl auch flach?

[sth]

Eine Programmiersprache wirklich lernen kann man meiner Ansicht nach ohnehin nur, in dem man sich ein kleines Projekt aussucht (und sei's nur eine selbstgestrickte Übungsaufgabe), sich dran setzt und dabei halt das Buch auf dem Schreibtisch liegen hat um nachzulesen wenn man irgendwo nicht mehr weiterkommt. Man mag' zwar ein paar mal kräftig auf die Fresse fallen aber daraus lernt man.

Ich persönlich bin nicht so der riesige C++-Freak. Ich nutze es zwar auch für einige Sachen aber bin nicht so sehr bewandert in vielen Dingen. Ich muss mir irgendwann mal die Zeit nehmen und mich noch ein wenig tiefer reinarbeiten, d.h. ich kann zwar im Moment C++ schreiben und mittels der allgemeinen Denkweise der objektorientierten Programmierung Modelle und Lösungen schaffen und implementieren aber richtig "C++ programmieren" würde ich das noch nicht nennen.

Irgendwie bleibe ich bei vielen Sachen - frei nach dem Motto "für jede Aufgabe das richtige Werkzeug" - bei C hängen. Natürlich gibt es Sachen, wo ich sage, dass C nicht das angemessene Werkzeug ist (und dementsprechend C++ oder Java verwende) aber für viele andere Sachen finde ich es recht angemessen, da die Implementierung in der Regel schnell geht und das Ergebnis meistens auf Anhieb recht rund läuft bin ich eigentlich mit C sehr zufrieden. Dabei spielt natürlich auch eine Rolle, dass man sich mit der Zeit einfach gewisse Programmier-Pattern angewöhnt hat, die sich in der Praxis bewährt haben.

Man muss allerdings aufpassen, dass die Sprache nicht zurückbeißt. Spätestens wenn man an mehreren Stellen auf Doppel oder sogar Dreifach-Pointer angewiesen ist würde ich sagen, dass man vielleicht das Konzept überdenken und dabei vielleicht die Sprache wechseln sollte, denn sowas gibt am Ende nur eines: Frust und Verzweiflung.
Der absolut undurchsichtige Code, den einige selbsternannte Gurus manchmal produzieren, ist nicht meine Welt. Ich mag lieber klare und durchschaubare Lösungsansätze.

Java ist da netter und wesentlich pflegeleichter, aber irgendwie habe ich immer ein ungutes Gefühl wenn ich an den GC denke ;) Für Programmiereinsteiger zwar eine Erleichterung, aber es macht denen den Umstieg auf andere Sprachen erst einmal schwer und die Leute, die von anderen Sprachen kommen kriegen zwischendurch schon manchmal leichte Bauchschmerzen wenn sie nicht mehr selbst über ihren Speicher bestimmen können (wenn auch man sagen muss, dass es ja eigentlich unbegründed ist). Desweiteren bin ich von der Performance von Java - auch wenn es mittlerweile kein allzugroßes Problem mehr ist - immernoch ein bisschen enttäuscht (aber jetzt bitte keine "Java ist schnell, nur Swing ist langsam"-Diskussion. Ich meine damit nicht nur Swing).

[Neomi]

aber templates fallen für dich dann wohl auch flach?

Nö, Templates unterliegen doch auch der vollen Kontrolle des Programmierers. Ein "NBuffer <Struktur_meiner_Wahl>" ist ja kein "NBuffer <such_dir_was_aus>". Templates sind zwar generisch, aber deshalb noch lange nicht undefiniert.

[maximAL]

Nö, Templates unterliegen doch auch der vollen Kontrolle des Programmierers. Ein "NBuffer <Struktur_meiner_Wahl>" ist ja kein "NBuffer <such_dir_was_aus>". Templates sind zwar generisch, aber deshalb noch lange nicht undefiniert.
das obige typsystem funktioniert ja auch so - nur, dass der typ zb. anhand der parameter bestimmt wird und nicht noch explizit angegeben werden muss.

[Coda]

@coda: klar gibts alles mögliche irgendwo in libraries. aber ich sehe doch noch einen gewaltigen unterschied zwischen dem nutzen von standard features und sich irgendwo irgendeine library zu organisieren, die die meissten programmierer noch nie benutzt haben.Ich war anscheinend bei was anderem - dachte du meinst Regex und co. Das was du meinst ist anscheinend eine Art RTTI, das hat C++ auch.

Und ich bin auch ein Fan von statischen Typen. Für generische Dinge kann man immer noch Templates oder RTTI einsetzen.

[Neomi]

das obige typsystem funktioniert ja auch so - nur, dass der typ zb. anhand der parameter bestimmt wird und nicht noch explizit angegeben werden muss.

Für mich klang "das findet der compiler allein raus" weniger nach einer anderen Art der Definition und mehr nach Ermessen des Compilers. Wie dem auch sei, ich sage ja nichts gegen die Sprache.

[Coda]

Es gibt einen auch einen Unterschied zwischen einem dynamischen Typsystem und Templates. Bei Templates kann man nämlich noch immer bestimmen welche Typen identisch sein sollen, etc. Das geht bei Scheme, Lisp & Co. nicht.

Beispiel: template<class T> T max(T a, T b) { return a>b ? a : b; }

Das funktioniert so nämlich nicht mit max(1,2.0), weil der Compiler nicht entscheiden kann ob's jetzt ein int oder ein double als Rückgabewert sein soll. Man muss dann schon max<int>(1,2.0) machen damit es präzise definiert ist.

[ScottManDeath]

wie gesagt, nur ein kleines bespiel. gerade das typsystem gefällt mir. zb. einfach in einer funktion ein tripel (x,y,z) zurückgeben können, ohne erst irgendwo eine passende struktur definieren zu müssen (oder sich das auch irgendeiner lib zu klauben) ist im programmieralltag sehr angenehm.


Das kann man mit der aktuellen (leider noch nicht von jedem Compiler implementierten) C++ Standardbibliothek (http://www.open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html)auch. Dazu muss man die Sprache nicht erweitern sondern fügt es als Libraryfeature hinzu.

Typesichere tupels:


tuple<float,int,string> func()
{
return make_tuple(0.0f,1,"Hello");
}

tuple<float,int,string> ret = func();
float a = get<0>(ret);
int b = get<1>(ret);
string c = get<2>(ret);

[Ganon]

Mal ne Frage. Ist es nicht leichter aufzuzählen was C++ NICHT kann? Wird man da nicht schneller fertig? *gg*

Ne, ich finde die "Macht" von C++ schon nicht schlecht. Nur leider bricht man sich 3 Finger dabei, wenn man "die Macht" nutzen will. *ggg*

[maximAL]

Es gibt einen auch einen Unterschied zwischen einem dynamischen Typsystem und Templates. Bei Templates kann man nämlich noch immer bestimmen welche Typen identisch sein sollen, etc. Das geht bei Scheme, Lisp & Co. nicht.

Beispiel: template<class T> T max(T a, T b) { return a>b ? a : b; }

Das funktioniert so nämlich nicht mit max(1,2.0), weil der Compiler nicht entscheiden kann ob's jetzt ein int oder ein double als Rückgabewert sein soll. Man muss dann schon max<int>(1,2.0) machen damit es präzise definiert ist.
OCaml hat kein dynamisches typsystem, sondern ein statisches (wenn auch polymorph)!
zudem gibt es da keine impliziten typumwandlungen (auch nicht int->float)

@ScottManDeath: war schon klar, dass jetzt einer mit sowas kommt :wink:
und ich seh immernoch einen unterschied zwischen einem sprachinternen feature und einer bibliothek (von der syntax ganz zu schweigen *shrug*)

[Coda]

Also ob die Syntax von OCaml so schön ist - darüber lässt sich auch wunderbar Nachmittage-lang streiten :D

und ich seh immernoch einen unterschied zwischen einem sprachinternen feature und einer bibliothekDas kannst du bei C++ nicht trennen, sonst hat es nichtmal nen String-Datentyp ;)

[maximAL]

Also ob die Syntax von OCaml so schön ist - darüber lässt sich auch wunderbar Nachmittage-lang streiten :D
na hässlicher als die von C(++) sicherlich nicht :biggrin:
wenn sich die programmierer wenigstens mal angewöhnen würden, bei x-fach verschachtelten template-konstruktionen ein paar typedefs zu benutzen...

@string: jaaa, nur ist der string zumindest schon ewig standard, wie oft wird man tuple sehen? darum gehts: einer benutzt es mal, die meissten nicht und wehe man muss mit dem code von jemand anderem arbeiten
---------------

zudem nachmal zu der sache mit den beschränkungen gegenüber C(++): natürlich sind höhere sprachen immer beschränkt. sinn ist nicht nur, einfacher programmieren zu können, sondern auch sicherer. zb. indem man viele gefährliche sachen erst gar nicht zulässt bzw. vom compiler verwalten lässt.
leider herrscht ja in der regel die meinung: "C++ ist nicht schuld, der programmierer ist nur zu blöd [aber ich bin natürlich schlau und mach keine fehler]".
gerade dieses denken halt ich für unsinnig, da es völlig normal ist, dass sich in einem programm fehler einschleichen, je umfangreicher, desto mehr. und bei C++ natürlich wieder besonders gefährliche.
oft hab ich den eindruck, dass sich manche förmlich in ihrer männlichkeit bedroht sehen :|

[ScottManDeath]

Das kannst du bei C++ nicht trennen, sonst hat es nichtmal nen String-Datentyp ;)

Jups. Java und .NET bekommen wie alle anderen Sprachen ihre Funktionalität durch die mitgelieferte Standardbibliothek. Ohne diese sind sie in ihrem Nutzen doch recht eingeschränkt.

@maximAL
Wenn du die Ocaml Standardbibliothek (http://caml.inria.fr/pub/docs/manual-ocaml/manual034.html)weg lässt, fehlen Dir auch Texteingabe, Textausgabe, Sting operationen, Stack, Map,.... die Liste ließe sich noch fortsetzen.

Wenn ein <insert language here> Programmierer seine Standardbibliothek nicht kennt, kann er die Sprache auch nicht mal ansatzweise nutzen. Die Standardbibliothek gehört zu jeder Sprache dazu und kann nicht wirklich unabhähnig davonbetrachtet werden.

Deswegen überzeugt mich Dein Argument gegen das C++ std::tuple nicht wirklich.

[Coda]

na hässlicher als die von C(++) sicherlich nicht Das ist ein antrainiertes hässlich oder schön finden.

Auf der Ebene werde ich mich aber sicher nicht weiter über Sprachen streiten, das ist lächerlich.

[maximAL]

ich weiss gar nicht, warum sich immer alle gleich angegriffen fühlen...

[Coda]

Mit "Ebene" meinte ich hier das Syntaxlevel, nicht die Konservation ;)