POLL (Programmiersprachen)
-
Lustig, ich hätte ja einen Haufen Kritikpunkte an <iostream> anzubringen, aber der wäre mir bestimmt nicht soo bald eingefallen.
-
rüdiger schrieb:
mathik schrieb:
nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
die sind nicht Objektorientiert?
was heißt schon objektorientiert. nur weil es in einer klasse gepackt ist?
versuch mal die streams in c++ und in java zu erweitern. in java wird das decorator-pattern angewandt, was die sache um einiges einfacher, intuitiver und flexibler macht.
-
mathik schrieb:
rüdiger schrieb:
mathik schrieb:
nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
die sind nicht Objektorientiert?
was heißt schon objektorientiert. nur weil es in einer klasse gepackt ist?
versuch mal die streams in c++ und in java zu erweitern. in java wird das decorator-pattern angewandt, was die sache um einiges einfacher, intuitiver und flexibler macht.
Jetzt sind wir wieder bei dem Problem mit der Definition von OOP. Also ja, ich halte sie für Objektorientiert, da man Signale an Objekte schickt. Außerdem wird ja sogar Vererbung benutzt. Aber gut "decorator-pattern" (was immer das seien mag), habe ich bisher in noch keiner Definition von Objektorientiert gehört. Aber du kannst mich ja sicher aufklären.
btw. bei C++ kann man Streams mit Vererbung erweitern, also das hört sich zumindest ziemlich Objektorientiert an
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
-
mathik schrieb:
nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
Wie schon meine vorredner sagten: die stream lib ist an anderen stellen nicht ganz so toll. Wobei man sagen muss, dass genau die objektorientiertheit an einigen stellen der lib das Bein bricht. thema templates+virtual(merkt man vorallem an der codecvt facet, die wär so cool, wenn man die funktionen mit back inserter iteratoren ansprechen könnte... stattdessen gibts an anderer stelle ne funktion, die nen size_t als maximal rückgabewert annimmt, und nen int zurückgibt kopf->wand).
-
rüdiger schrieb:
mathik schrieb:
rüdiger schrieb:
mathik schrieb:
nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
die sind nicht Objektorientiert?
was heißt schon objektorientiert. nur weil es in einer klasse gepackt ist?
versuch mal die streams in c++ und in java zu erweitern. in java wird das decorator-pattern angewandt, was die sache um einiges einfacher, intuitiver und flexibler macht.
Jetzt sind wir wieder bei dem Problem mit der Definition von OOP. Also ja, ich halte sie für Objektorientiert, da man Signale an Objekte schickt. Außerdem wird ja sogar Vererbung benutzt. Aber gut "decorator-pattern" (was immer das seien mag), habe ich bisher in noch keiner Definition von Objektorientiert gehört. Aber du kannst mich ja sicher aufklären.
btw. bei C++ kann man Streams mit Vererbung erweitern, also das hört sich zumindest ziemlich Objektorientiert an
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
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.html
-
rüdiger wird sicherlich wissen, was design-patterns sind. Ihm ging es um das decorator-pattern speziell. Mir würde jetzt auch nicht einfallen, was das Pattern macht (kann man aber nachschlagen, deshalb nicht so schlimm). Ich bezweifel aber, das man alle Java- und C#-Techniken (oh man, ich habe das Wort Java benutzt, das gibt Krieg) auf C++ übertragen und somit kennen muß. Denn genauso kann es umgekehrt sein: erzähl mal einem Java-/C#-Programmierer was von Hardcore-C++-Designtechniken. Der wird dich mit staunenden und unwissenden Augen anschauen. Aber das ist nicht schlimm, weil er nunmal kein C++ programmiert.
-
Artchi schrieb:
rüdiger wird sicherlich wissen, was design-patterns sind. Ihm ging es um das decorator-pattern speziell. Mir würde jetzt auch nicht einfallen, was das Pattern macht (kann man aber nachschlagen, deshalb nicht so schlimm). Ich bezweifel aber, das man alle Java- und C#-Techniken (oh man, ich habe das Wort Java benutzt, das gibt Krieg) auf C++ übertragen und somit kennen muß. Denn genauso kann es umgekehrt sein: erzähl mal einem Java-/C#-Programmierer was von Hardcore-C++-Designtechniken. Der wird dich mit staunenden und unwissenden Augen anschauen. Aber das ist nicht schlimm, weil er nunmal kein C++ programmiert.
Design Patterns sind doch nicht abhängig von Java. Das du mit generischer C++-Hardcore-Programmierung einen Java-Prgogrammierer (der so gar nicht programmieren kann) beeindrucken kannst, klar. Aber alles was objektorientiert ist (und somit in beiden Sprachen möglich sein sollte) kennen auch Programmierer beider Sprachen.
MfG SideWinder
-
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?