POLL (Programmiersprachen)
-
rüdiger schrieb:
nman schrieb:
Lustig, ich hätte ja einen Haufen Kritikpunkte an <iostream> anzubringen, aber der wäre mir bestimmt nicht soo bald eingefallen.
Wenn es eine Bewertung für die "Objektorientiertheit" gäbe, wären die Streams vermutlich das Objektorientierteste an der ganzen Standard Library
Vorallem, wenn man bedenkt, das diese sogar Mehrfachvererbung einsetzen. Also, OOD im Extremeinsatz!
Egal wie man es macht, es ist nicht richtig.
-
Ontopic: 60% für C++. Na, das ist ja nochmal glimpflich ausgegangen.
-
Artchi schrieb:
Ontopic: 60% für C++. Na, das ist ja nochmal glimpflich ausgegangen.
Nein, dieses Java-Gelumpe ist immernoch vor C
-
Artchi schrieb:
Ontopic: 60% für C++. Na, das ist ja nochmal glimpflich ausgegangen.
Wenn in einem C++-Forum dieser Poll mal mit < 50% für C++ endet ist die Sprache sowieso dem Tode geweiht
MfG SideWinder
-
TactX schrieb:
Artchi schrieb:
Ontopic: 60% für C++. Na, das ist ja nochmal glimpflich ausgegangen.
Nein, dieses Java-Gelumpe ist immernoch vor C
Du hast das J-Wort benutzt! Neeeeeeeeeeeeiiiiiin! Weißt du,was du damit auslösen kannst?
-
Das Ding heißt F-Wort. (c) Southpark
MfG SideWinder
-
Artchi schrieb:
TactX schrieb:
Artchi schrieb:
Ontopic: 60% für C++. Na, das ist ja nochmal glimpflich ausgegangen.
Nein, dieses Java-Gelumpe ist immernoch vor C
Du hast das J-Wort benutzt! Neeeeeeeeeeeeiiiiiin! Weißt du,was du damit auslösen kannst?
Hmmmm, eine NULL-Pointer-Exception?
-
mathik schrieb:
von design patterns muss eigentlich jeder schon mal was gehört haben, wenn er den anspruch erwägen will, objektorientiert programmieren zu können. ich meine ich hätte hier im c++-magazin auch eine einführung dazu gesehen.
zum thema vererbung: es ist ein sehr mächtiges werkzeug in OO, das aber viel zu oft falsch angewandt wird, was zu schwer wartbaren spaghetticode führt. dazu sind folgende artikel lesenswert:
http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.htmlKannst oder willst du meine Frage nicht beantworten?
Keine Sorge, ich kenne Design-Patterns und das liskovsche Prinzip.
-
Dein Posting enthält offensichtlich gar eine Frage.
MfG SideWinder
-
rüdiger schrieb:
mathik schrieb:
von design patterns muss eigentlich jeder schon mal was gehört haben, wenn er den anspruch erwägen will, objektorientiert programmieren zu können. ich meine ich hätte hier im c++-magazin auch eine einführung dazu gesehen.
zum thema vererbung: es ist ein sehr mächtiges werkzeug in OO, das aber viel zu oft falsch angewandt wird, was zu schwer wartbaren spaghetticode führt. dazu sind folgende artikel lesenswert:
http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.htmlKannst oder willst du meine Frage nicht beantworten?
Keine Sorge, ich kenne Design-Patterns und das liskovsche Prinzip.
sorry. für mich hatte das sich so angehört als ob du von design pattern bisher nichts gehört hast... wenn es so ist, dann kannst du im GoF das Decorator-Pattern nachschlagen. dort gibt es auch ein bsp. mit streams. oder einfach googeln. ich finde das decorator pattern ist eins der wichtigen überhaupt.
ich habe zudem irgendwie das gefühl, dass für dich die programme objektorientiert sind, die vererbung ohne ende einsetzen. ich sehe das nicht so. vererbung um sinnvoll polymorphie zu anzuwenden: ja. vererbung um implementation wiederzuverwenden: in sehr vielen fällen nein. Hierfür ist delegation meistens besser geeignet (siehe hierzu den artikel von javaworld "why extends is evil").
und zum thema c++-streams vs. java-streams:
in java ist alles mögliche ein stream: dateien, sockets, unicode-to-ascii-converter, zip-compresser, encrypter/decrypter,...diese kann ich einfach beliebig kombinieren: z.b. komprimierten und verschlüsselten ascii datenstrom ohne new lines absenden:
UnicodeToAsciiOutputStream (new ZipOutputStream (new NewLineRemover(new RSAEncrypter(keys..., new BufferedOutputStream(socket.getOutputStream)))))
wenn ich meine eigenen streams erstellen will, um in dieses mächstige "stream-framework" neue funktionalität reinzuhängen muss ich lediglich von OutputStream (oder InputStream) ableiten und die write- Methode (oder read) implementieren. fertig!in C++ muss ich irgendsoeine komische "streambuf"-klasse ableiten und irgednwelche kryptischen operationen überschreiben, wie z.b. sputbackc, sputc, sgetn... wirklich sehr intuitiv!
-
mathik schrieb:
sorry. für mich hatte das sich so angehört als ob du von design pattern bisher nichts gehört hast... wenn es so ist, dann kannst du im GoF das Decorator-Pattern nachschlagen. dort gibt es auch ein bsp. mit streams. oder einfach googeln. ich finde das decorator pattern ist eins der wichtigen überhaupt.
Keine Sorge, wenn ich wirklich wissen will, was es ist, habe ich schon meine Quellen.
ich habe zudem irgendwie das gefühl, dass für dich die programme objektorientiert sind, die vererbung ohne ende einsetzen.
Nö, wie kommst du dadrauf? Glaube kaum, dass du meine Programme kennst. Ich benutz sehr selten Vererbung. Aber eigentlich glaube ich nicht, das ich Tipps von dir brauch oder haben will, wie ich bessere Programme schreibe. Danke.
und zum thema c++-streams vs. java-streams:
in java ist alles mögliche ein stream: dateien, sockets, unicode-to-ascii-converter, zip-compresser, encrypter/decrypter,...diese kann ich einfach beliebig kombinieren: z.b. komprimierten und verschlüsselten ascii datenstrom ohne new lines absenden:
UnicodeToAsciiOutputStream (new ZipOutputStream (new NewLineRemover(new RSAEncrypter(keys..., new BufferedOutputStream(socket.getOutputStream)))))
wenn ich meine eigenen streams erstellen will, um in dieses mächstige "stream-framework" neue funktionalität reinzuhängen muss ich lediglich von OutputStream (oder InputStream) ableiten und die write- Methode (oder read) implementieren. fertig!in C++ muss ich irgendsoeine komische "streambuf"-klasse ableiten und irgednwelche kryptischen operationen überschreiben, wie z.b. sputbackc, sputc, sgetn... wirklich sehr intuitiv!
Geht in C++ doch auch wunderbar. Schau dir Boost.Iostream an. Da hast du zB bereits fertige Bzip2/Gzip-Sachen etc.
-
mathik schrieb:
und zum thema c++-streams vs. java-streams:
in java ist alles mögliche ein stream: dateien, sockets, unicode-to-ascii-converter, zip-compresser, encrypter/decrypter,...diese kann ich einfach beliebig kombinieren: z.b. komprimierten und verschlüsselten ascii datenstrom ohne new lines absenden:
UnicodeToAsciiOutputStream (new ZipOutputStream (new NewLineRemover(new RSAEncrypter(keys..., new BufferedOutputStream(socket.getOutputStream)))))
wenn ich meine eigenen streams erstellen will, um in dieses mächstige "stream-framework" neue funktionalität reinzuhängen muss ich lediglich von OutputStream (oder InputStream) ableiten und die write- Methode (oder read) implementieren. fertig!in C++ muss ich irgendsoeine komische "streambuf"-klasse ableiten und irgednwelche kryptischen operationen überschreiben, wie z.b. sputbackc, sputc, sgetn... wirklich sehr intuitiv!
es ist immer wieder das gleiche bei diesen java versus C++ threads: es werden äpfel mit birnen verglichen.
ihr dürft nicht vergessen, das C++ ein ganzes stück älter als java ist und dass die designer von java u.a. C++ als beispiel genommen haben, um dinge zu verbessern. von daher ist es klar, dass unter java einiges benutzerfreundlicher gelöst ist als unter C++, aber das ist kein grund über C++ abzulästern.
man schimpft ja auch nicht über oldtimer-PKW nur weil heutige autos voller high-tech stecken. manchmal ist weniger eben mehr
-
vista schrieb:
man schimpft ja auch nicht über oldtimer-PKW nur weil heutige autos voller high-tech stecken. manchmal ist weniger eben mehr
Hälst Du C++ für den Oldtimer unter den Programmiersprachen? Halt so ne Hobby-Sprache für Liebhaber?
-
rüdiger schrieb:
Nö, wie kommst du dadrauf? Glaube kaum, dass du meine Programme kennst. Ich benutz sehr selten Vererbung. Aber eigentlich glaube ich nicht, das ich Tipps von dir brauch oder haben will, wie ich bessere Programme schreibe. Danke.
fühlst du dich irgendwie persönlich angefriffen? ich dachte du wolltest wissen, was das decorator-pattern will, da du nochmal speziell nachgefragt hast....
ich möchte hier eine sachliche diskussion führen. musst nicht alles so persönlich nehmenrüdiger schrieb:
Geht in C++ doch auch wunderbar. Schau dir Boost.Iostream an. Da hast du zB bereits fertige Bzip2/Gzip-Sachen etc.
es geht mir nicht um irgendwelche fertigen Bzip2/Gzip-Sachen, sondern um das prinzip, wie einfach erweiterbar java-streams (bzw. "decorator-streams") sind und wie kompliziert es bei stl-streams ist.
es ist immer wieder das gleiche bei diesen java versus C++ threads: es werden äpfel mit birnen verglichen.
ihr dürft nicht vergessen, das C++ ein ganzes stück älter als java ist und dass die designer von java u.a. C++ als beispiel genommen haben, um dinge zu verbessern. von daher ist es klar, dass unter java einiges benutzerfreundlicher gelöst ist als unter C++, aber das ist kein grund über C++ abzulästern.
man schimpft ja auch nicht über oldtimer-PKW nur weil heutige autos voller high-tech stecken. manchmal ist weniger eben mehrdas stimmt. aber ich verstehe nicht, warum die aus sowas nicht lernen und es im nächsten c++-standard nicht besser als in java oder sonst wo machen...
c++ ist eine super-tolle eierlegendewollmilchsauprogrammiersprache. allerdings könnte sie auch mal modernisiert werden. insbesondere bei den bibliotheken (und nö, D ist nicht die modernisierung ;))
-
mathik schrieb:
rüdiger schrieb:
Geht in C++ doch auch wunderbar. Schau dir Boost.Iostream an. Da hast du zB bereits fertige Bzip2/Gzip-Sachen etc.
es geht mir nicht um irgendwelche fertigen Bzip2/Gzip-Sachen, sondern um das prinzip, wie einfach erweiterbar java-streams (bzw. "decorator-streams") sind und wie kompliziert es bei stl-streams ist.
Es geht dabei nicht nur um ein paar nützliche Stream-Implementierungen, sondern um eine Library, die es einem einfach macht, eigene Streams zu bauen. So wie du es forderst.
Schau mal hier: http://www.boost.org/libs/iostreams/doc/index.html
Deshalb ist deine negative Kritik unberechtigt, da deine Forderung bereits erfüllt wurde. Jeder der ernsthaft eigene Streams bauen will, kann damit loslegen. Das es vielleicht nicht nach der Nase von Personengruppe X geht, sollte hier nicht interessieren, da es nicht ausschliesslich einen Lösungsweg gibt.mathik schrieb:
aber ich verstehe nicht, warum die aus sowas nicht lernen und es im nächsten c++-standard nicht besser als in java oder sonst wo machen...
Du kannst ja gerne eine Referenzimplementierung programmieren oder eine Spezifikation schreiben und dem C++-Komitee als Proposal vorlegen. Es hindert dich niemand am nächsten Standard mitzuwirken und deine Liblingskonzepte in C++ einfliessen zu lassen.
mathik schrieb:
c++ ist eine super-tolle eierlegendewollmilchsauprogrammiersprache. allerdings könnte sie auch mal modernisiert werden. insbesondere bei den bibliotheken
Im C++2009-Standard wird es einige Verbesserungen, Vereinfachungen und Erweiterungen geben. Mach dir da mal keine Sorgen...
-
mathik schrieb:
rüdiger schrieb:
Nö, wie kommst du dadrauf? Glaube kaum, dass du meine Programme kennst. Ich benutz sehr selten Vererbung. Aber eigentlich glaube ich nicht, das ich Tipps von dir brauch oder haben will, wie ich bessere Programme schreibe. Danke.
fühlst du dich irgendwie persönlich angefriffen? ich dachte du wolltest wissen, was das decorator-pattern will, da du nochmal speziell nachgefragt hast....
ich möchte hier eine sachliche diskussion führen. musst nicht alles so persönlich nehmenNein, ich fühle mich nicht persönlich angegriffen. Ich verstehe nur nicht, warum du in jedem Beitrag bisher mich versuchst zu belehren.
rüdiger schrieb:
Geht in C++ doch auch wunderbar. Schau dir Boost.Iostream an. Da hast du zB bereits fertige Bzip2/Gzip-Sachen etc.
es geht mir nicht um irgendwelche fertigen Bzip2/Gzip-Sachen, sondern um das prinzip, wie einfach erweiterbar java-streams (bzw. "decorator-streams") sind und wie kompliziert es bei stl-streams ist.
Das war ja nur ein Beispiel. Also schau dir Boost.Iostream an, damit ist das ziemlich leicht.
Und naja, Java hat ja auch keine ideale Standard-Library. Ich habe erst erfahren, das für Java ein Pfad eine Datei ist. Sehr verwirrend. Könnten die mal überarbeiten...
-
vista schrieb:
es ist immer wieder das gleiche bei diesen java versus C++ threads: es werden äpfel mit birnen verglichen.
Sehe ich nicht so. Aepfel und Birnen sind zwei verschiedenen Sachen. Bei SE-Designs geht es darum, dasselbe Problem zu loesen. D.h. es gibt mehrere Loesungen fuer das gleiche Problem. Der Knackpunkt sind die Preferenzen. Es geht dabei darum, die Vor- und Nachteile abzuwaegen. Das Resultat ist ein trade-off. Wie bereits gesagt - es geht um Preferenzen - jeder hat eigene. Daher kann eine Zielloesung nicht jeden zufriedenstellen, da man unterschiedliche Preferenzen hat. Insbesondere heisst das, dass man nicht berechtigt ist die realisierte Loesung in Frage zu stellen, wenn man die Intention der Designer nicht kennt.
-
Insbesondere heisst das, dass man nicht berechtigt ist die realisierte Loesung in Frage zu stellen, wenn man die Intention der Designer nicht kennt.
Bitte, sein wann denn das? Ich habe jedes Recht alles und jeden zu kritisieren. Wir leben schlieslich nicht in China.
Davon leben ja auch die Entwickler, von konstruktiver Kritik, die weniger konstruktiver Kritik kann man ja ignorieren, muss man aber nicht.
Präferenzen schön und gut, aber diese Sachen wie Design-Patterns haben sich nicht umsonst etabliert. In dieser Hinsicht sind die moderneren Sprachen wie Java oder C# schon besser Designt. Deswegen bin ich echt gespannt auf C++x9, weil ich ja C++ als Sprache schon mag, aber Angesicht der Frikerrei die unumgänglich bei dieser Sprache ist, sind nunmal andere Sprachen attraktiver.
Templates Programming ist ja schön und gut, aber wer braucht das wirklich. Dazu kommt noch der Präprozessor, das Include-System und die 1000te von String-Klassen. Bei Templates kann man immernoch keine vernünftige Aufteilung von Interface und Implementation machen, immer wenn man irgendwas in der Template-Klasse ändert muss man das 10.000 Zeilen lange Programm von vorne compilieren.
-
mathik schrieb:
das stimmt. aber ich verstehe nicht, warum die aus sowas nicht lernen und es im nächsten c++-standard nicht besser als in java oder sonst wo machen...
c++ ist eine super-tolle eierlegendewollmilchsauprogrammiersprache. allerdings könnte sie auch mal modernisiert werden. insbesondere bei den bibliotheken (und nö, D ist nicht die modernisierung ;))
Machen sie ja. aber anders als du denkst. du musst verstehen, dass C++ eine sehr alte sprache ist, in der unglaublich viele Programme geschrieben wurden. jede veränderung an der Basis würde sofort viele zeilen code ungültig machen. Hier sind ganz klar wirtschaftliche interessen vorzuziehen, denn sonst würde der neue standard nicht nur nicht benutzt werden,im gegenteil, er würde von wirtschaftsseite total ignoriert. Deshalb werden alle änderungen auch in den std::tr1 bzw std::tr2 namespace untergebracht. Und ja, dort gibt es etliche änderungen, die viele kritikpunkte aushebeln.
Präferenzen schön und gut, aber diese Sachen wie Design-Patterns haben sich nicht umsonst etabliert. In dieser Hinsicht sind die moderneren Sprachen wie Java oder C# schon besser Designt. Deswegen bin ich echt gespannt auf C++x9, weil ich ja C++ als Sprache schon mag, aber Angesicht der Frikerrei die unumgänglich bei dieser Sprache ist, sind nunmal andere Sprachen attraktiver.
Design patterns haben sich in OO umgebungen etabliert. das ist schon richtig. Aber C++ ist keine reine OO umgebung, und Schema F würde dann vielleicht nur in ausnahmefällen richtig funktionieren
Templates Programming ist ja schön und gut, aber wer braucht das wirklich.
schau mal in die locale bibliothek. vorallem use_facet. Schau mal nach boost, wo mit template programming absolut flexible bibliotheken geschrieben wurden, die sich im alltag bewährt haben(boost::function, boost::tuple, boost::spirit,...)
und die 1000te von String-Klassen.
jetzt mal ganz ernsthaft: was gefällt dir an dem std::string net? dass er kein multibyte kann? das ist meiner meinung nach nicht so schlimm, da der string auf geschwindigkeit ausgelegt ist(und am ende dann doch mit wide charactern sehr gut klar kommt).
-
DEvent schrieb:
Präferenzen schön und gut, aber diese Sachen wie Design-Patterns haben sich nicht umsonst etabliert.
Und finden auch in der Stdlib ihren Einsatz. Oder was sind Funktionsobjekte, Iteratoren, Ein- und Ausgabe-Operatoren bei Streams? Alles keine Patterns? Das gerade das eine spezielle Pattern nicht zum Einsatz kommt, macht natürlich eine ganze Library unbrauchbar.
DEvent schrieb:
In dieser Hinsicht sind die moderneren Sprachen wie Java oder C# schon besser Designt.
Kann sein, auch wenn ich es ein wenig mühselig fand, Jahre lang ohne typisierbare Container arbeiten zu müssen. Komisch, ist auch nicht perfekt...
DEvent schrieb:
Templates Programming ist ja schön und gut, aber wer braucht das wirklich.
Von sich auf andere schliessen, ist immer gut.
DEvent schrieb:
Dazu kommt noch der Präprozessor, das Include-System
Präprozessoren gibts auch für andere Sprachen. Weiß nicht wie die alle heißen, aber waren z.B. in Java die Vorgänger von den Annotations. Hat man sich damals eindeutig von C++-Präprocessor inspirieren lassen. Das include-System wird aber nach C++2009 durch ein sogenanntes Module-Build-System ergänzt werden, dann müssen wir das Include-System nicht mehr benutzen. Das entsprechende Proposal wurde jedenfalls vom Komitee als interessant und wichtig eingestuft. (für 2009 aber aus Zeitmangel "geparkt") Warum informiert ihr euch nicht über die Arbeit des C++-Komitees?
DEvent schrieb:
und die 1000te von String-Klassen.
Dieses Thema kommt immer wieder hoch, und keiner sagt, was ihn stört? Weiterhin hat die Stdlib nicht 1000 String-Klassen, sondern nur zwei typisierte Templates. string und wstring. Das eine für Ascii und das andere für UCS. Mehr braucht man nicht für die Laufzeit-Strings.
DEvent schrieb:
immer wenn man irgendwas in der Template-Klasse ändert muss man das 10.000 Zeilen lange Programm von vorne compilieren.
Das hat aber nichts mit C++ zu tun, sondern den mangelnden export-Features seitens der Compiler. Wenn dich das Compilieren stört, kannst du im einfachsten Fall die PCHs einschalten. Wenn du export-Schlüsselwort haben willst, kauf dir einen Compiler der das kann (und den gibt es bekanntlich). Aber was hat die C++-Sprache damit am Ende zu tun?