Verleitet C++ zum komplizierteren denken?

Nexus schrieb:

+fricky schrieb:

das ist doch ein typisches beispiel. da will einer ein simples pointer-array haben und wir gleich mit boost, shared_ptrs und vector<blubb> zugetextet.

Klar, der Anfänger soll auch nicht denken, dass Rumfrickeleien mit Zeiger-Arrays in C++ die übliche Methode sind, um mehrere Werte gemeinsam zu speichern.

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind. zeiger und arrays und auch arrays von zeigern sind keine rumfrickelei, sondern sehr effiziente, maschinennahe konstrukte, die durch nichts ersetzbar sind (ausser man programmiert gleich in assembler). hätte er gefragt, wie man am besten mit einem boost::tr1::std::shared_ptr::was_weiss_ich umgehen kann, wäre es was anderes gewesen. aber so seid ihr mit euren antworten weit übers ziel hinausgeschossen. leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?

abc.w

+fricky schrieb:

leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?

Weil C++ zum komplizierteren Denken verleitet?

Badestrand

+fricky schrieb:

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind.

Man sieht aber immer wieder wie sich Anfänger das Leben schwer machen, einfach weil sie vector, shared_pointer usw nicht kennen.

Nexus

+fricky schrieb:

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind. zeiger und arrays und auch arrays von zeigern sind keine rumfrickelei, sondern sehr effiziente, maschinennahe konstrukte, die durch nichts ersetzbar sind (ausser man programmiert gleich in assembler).

Ja, vielleicht. Da dieser Teil der Anfänger in C++ allerdings sehr gering ist, halte ich es für gerechtfertigt, nicht von einem Bytemanipulierer auszugehen. Und sich durch maschinennahe Sprachmittel unnötige Mühen aufzubürden, wo ein High-Level-Konstrukt viel besser geeignet ist, sehe ich als Frickelei an. Für sehr viele Fälle sind die Zeiger und Arrays eben schon ersetzbar.

+fricky schrieb:

hätte er gefragt, wie man am besten mit einem boost::tr1::std::shared_ptr::was_weiss_ich umgehen kann, wäre es was anderes gewesen. aber so seid ihr mit euren antworten weit übers ziel hinausgeschossen. leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?

Leider kennt man als Anfänger weder Boost noch std::vector . Viele C++-Einsteigerbücher sind zudem schlecht, sodass die Wahrscheinlichkeit gar nicht mal so klein ist, dass man von wichtigen Teile der Standardbibliothek nie gehört hat. Wieso sollten wir ihm keine Methoden vorschlagen, die er noch nicht kennt? Meine Erfahrung im C++-Forum zeigt, dass es schon oft Leute gab, denen so ein Hinweis enorm geholfen hat.

Ich wette, dass viele C++ Neulinge/Anfänger zur STL/boost/whatever greifen, nur damit sie nicht durch andere C++ler gebasht werden ala "du noob, wieso nimmst du char* du C-frickler.".

Scheint wohl daher zu kommen, dass C Elemente in C++ kreisen verpöhnt sind.

Einfaches Beispiel: printf().

Meiner Meinung nach ist printf, sprintf, fprintf [...] um einiges effizienter sowie einfacher in der Handhabung als cout und die ganzen streams.

Bloß doof, dass man gleich angeschnauzt wird, wenn man ein printf in C++ code einbaut. Dabei sind format strings so komfortabel. Klar, wenn man nicht aufpasst, kann man mit dem format-string böse scheisse anstellen. Aber mit den c++ streams bekommt man das ganz gewiss auch hin. Da bin ich mir sicher.

Das Argument "format strings sind kryptisch" kann man nicht gelten lassen. Es dauert keine 5 Minuten bis man die formatstrings es voll drauf hat.

Insbesondere wenn man sauber tabellarisch etwas ausgeben möchte, sind printf & co perfekt. Mit cout kanns schon etwas hässlich werden, ganz zu schweigen von dem "<<" Inferno.

Die STL hat zwar die Absicht Arbeit abzunehmen - das tut sie auch - wenn man denn weiß was genau hinter den Kullissen geschieht. Wenn man das weniger weis, dann wird die Fehlersuche zum Abenteuerlabyrinth.

~john schrieb:

Die Ursache ist einfach. Personen scheitern an C++ und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

Vielleicht solltest du hier genauer erläutern warum die Leute den Fehler bei sich selber suchen sollen und warum sie es einsehen sollen. Es ist doch die Sprache c++ die gerade für Anfänger fehleranfällig ist.

Es ist doch so: Leute versuchen sich in C++, tappen in jedes vorhandene Fettnäpfchen (von denen C++ genug bereitstellt), kommen kaum voran. Zufällig/aus Frust versuchen sie eine modernere Sprache und *ding*, schau an schau an, auf einmal machen die Fortschritte und das Ergebnis kann sich bereits nach kurzer Zeit sehen lassen. Vielleicht solltest du nun diesen Leuten erklären warum sie den Fehler bei sich selbst suchen sollen, wenn es denn auch einfacher geht. Denn diese Leute haben gemerkt, dass segfaults nicht sein müssen. Diese Leute haben gemerkt, dass aufwändige debugging sessions sich in Grenzen halten können. Diese Leute haben gemerkt, dass es mit weniger Aufwand auch schneller voran gehen kann.

Setzt man das Resultat an erster Stelle in der Prioritätenhierarchie, so wird die Rechtfertigung des nicht zu vernachlässigbaren Mehraufwands seitens C++ schwierig.

Achja: "moderne Sprachen sind was für Weicheier/Faule" ist keine Rechtfertigung. Das ist Stursinn.

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

Nexus schrieb:

+fricky schrieb:

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind. zeiger und arrays und auch arrays von zeigern sind keine rumfrickelei, sondern sehr effiziente, maschinennahe konstrukte, die durch nichts ersetzbar sind (ausser man programmiert gleich in assembler).

Ja, vielleicht. Da dieser Teil der Anfänger in C++ allerdings sehr gering ist, halte ich es für gerechtfertigt, nicht von einem Bytemanipulierer auszugehen. Und sich durch maschinennahe Sprachmittel unnötige Mühen aufzubürden, wo ein High-Level-Konstrukt viel besser geeignet ist, sehe ich als Frickelei an. Für sehr viele Fälle sind die Zeiger und Arrays eben schon ersetzbar.

naja, aber dadurch, dass der durchschnittliche C++ benutzer die lowlevel-fähigkeit seiner sprache meidet, wie der teufel das weihwasser, gibts viele c++ programmierer, die lowlevel-mässig keinerlei bezug haben. ich selbst hab schon einige male erlebt, dass leute in schlimme bedrängnis geraten sind, weil sie in C++ so programmiert haben, wie ihr es in eurem forum propagiert. der schlechte ruf von c++ im embedded bereich kommt fast nur daher, dass highlevel-programmierung und abstraktion bis zum erbrechen gepflegt werden, während alle lowlevel-möglichkeiten als 'grundsätzlich schlecht und fehleranfällig' und als 'c-altlasten' verteufelt werden.

DieFaustAufsAuge schrieb:

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

*hahaha*, ja der ist lustig. allein das hier:

Array<int>()-1-2-3-4-5

absolut intuitiv und lesbar. dagegen verblassen alle meine lästereien über operatorüberladung.

Badestrand

+fricky schrieb:

dagegen verblassen alle meine lästereien über operatorüberladung.

Das stimmt, zum Glück kann's jetzt aber auch schon Kommas

Blue-Tiger

Also ich erwisch mich hin & wieder dabei, dass ich statt eines

for (int i = 0; i < v.size(); ++i)
    cout << v[i] << '\n';

erstmal ueberlege, ob das nicht schoener mit std::copy und output-iteratoren werden wuerde.

abc.w

+fricky schrieb:

*hahaha*, ja der ist lustig. allein das hier:
Array<int>()-1-2-3-4-5
absolut intuitiv und lesbar. dagegen verblassen alle meine lästereien über operatorüberladung.

Ja, total intuitiv, ein Array von negativen Zahlen von -1 bis -5?

Array<int>()-1-2-3-4-5

Ist das die moderne Form von <°)))><< ??

volkard

oooooooooooooooooooo schrieb:

Array<int>()-1-2-3-4-5
Ist das die moderne Form von <°)))><< ??

Laßt doch mal diese Zeile in Ruhe. Das war Unfug, mal schnell hingekackt, um was ganz anderes zu testen. Außerdem ist das eine Spielerei, keiner sagt dort, andere müssten das so machen.

Nexus

+fricky schrieb:

naja, aber dadurch, dass der durchschnittliche C++ benutzer die lowlevel-fähigkeit seiner sprache meidet, wie der teufel das weihwasser, gibts viele c++ programmierer, die lowlevel-mässig keinerlei bezug haben. ich selbst hab schon einige male erlebt, dass leute in schlimme bedrängnis geraten sind, weil sie in C++ so programmiert haben, wie ihr es in eurem forum propagiert.

Wir (zumindest ich) propagiere keineswegs, man brauche über Low-Level-Dinge nichts zu wissen. Nicht ohne Grund habe ich in jenem Thread Zeiger-Arrays mit new und delete erklärt. Es ist zweifelsohne von Nutzen, sich mit maschinennahen Sprachmitteln auszukennen, das bestreite ich gar nicht. Aber trotzdem heisst das nicht, man sollte diese so oft wie möglich anwenden, in sehr vielen Fällen sind eben Abstraktionen wie std::vector , boost::shared_ptr & Co. die bessere Wahl.

Wir sollten etwas von den Extremen wegkommen. Natürlich ist es weder angebracht, in C++ reines C zu programmieren, noch ausschliesslich moderne High-Level-Konstrukte anzuwenden und nicht mal Zeiger zu kennen. Dass der durchschnittliche C++-Programmierer von Low-Level-Sprachmitteln keine Ahnung hat oder sie sogar meidet, stimmt übrigens auch nicht. Manuelle Speicherverwaltung, Zeigerarithmetik und solche Dinge braucht man in C++ bei gutem Design zwar nicht mehr exzessiv, aber wenn man sie nicht kennt, ist man früher oder später trotzdem aufgeschmissen.

DieFaustAufsAuge schrieb:

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

Interessant, dass ihr Threads, in denen es um Spielereien und Experimente geht, als Massstab für die "Kompliziertheit" von C++ nehmt.

*john 0

+fricky schrieb:

leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?

Da wäre erstmal das Wort "übertrieben" zu streichen. Den meisten C Programmieren ist nicht bewußt, was für Probleme mit den einfachen C Konstrukten einhergehen. Oftmals wird auch der falsche Vergleich zwischen C ohne jedes Errorhandling und vollständigen Errorhandling in einer andere Sprache gezogen, und dann wundert man sich warum das in anderen Sprachen anscheinend so kompliziert ist.

Nexus schrieb:

Wir sollten etwas von den Extremen wegkommen. Natürlich ist es weder angebracht, in C++ reines C zu programmieren, noch ausschliesslich moderne High-Level-Konstrukte anzuwenden und nicht mal Zeiger zu kennen. Dass der durchschnittliche C++-Programmierer von Low-Level-Sprachmitteln keine Ahnung hat oder sie sogar meidet, stimmt übrigens auch nicht.

naja, aber dann frage ich mich warum bei einigen nur grütze rauskommt. mal ein beispiel: ich habe eine software bestehend aus RTOS, netzwerkprotokollen (tcp/ip, udp), webserver, telnet-server, ftp server, scriptsprache, treiber für WLAN mit WPA2, treiber für ethernet, USB-host, treiber für verschiedene I/O schnittstellen wie RS232, CAN, I2C, SPI, FAT16/32-filesystem, sd-card treiber (ich hoffe, ich hab nichts vergessen) in etwa 200K ROM und ~40K RAM untergebracht, alles in C geschrieben. ein mitbewerber hat ähnliches in C++ versucht, aber bei ihm waren die 256K ROM seines controllers schon mit tcp/ip, ethernet-treiber, webserber und 'ner XML-library voll. die haben C++ so benutzt, wie 99% aller c++ progger, nämlich auf 'schönes C++', templates, OOP+vererbung, C++-exceptions und die STL gesetzt. dann war plötzlich ende. irgendwie waren sie nach dem schock am überlegen, ob sie 'n halbes jahr softwareentwicklung übern haufen werfen oder einen controller mit mehr speicher einsetzen (was ein re-design der hardware bedeutet hätte). weiter hab' ich nix mehr von denen gehört.

Nexus schrieb:

DieFaustAufsAuge schrieb:

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

Interessant, dass ihr Threads, in denen es um Spielereien und Experimente geht, als Massstab für die "Kompliziertheit" von C++ nehmt.

ich finde, dieses selbstgemachte for_each (auch wenn's nur ne machbarkeitsstudie ist) ist schon ziemlich kompliziert.

volkard

+fricky schrieb:

ich finde, dieses selbstgemachte for_each (auch wenn's nur ne machbarkeitsstudie ist) ist schon ziemlich kompliziert.

Du hast meine compilezeitberechneten Primzahlen in C mit rekursiven includes anscheinend nicht geshen.

volkard schrieb:

Du hast meine compilezeitberechneten Primzahlen in C mit rekursiven includes anscheinend nicht geshen.

ich glaub nicht. hast du 'nen primzahlentest wie miller-rabin mit template metaprogramming programmiert, oder wie?

*john 0

dffffffffffffffff schrieb:

Meiner Meinung nach ist printf, sprintf, fprintf [...] um einiges effizienter sowie einfacher in der Handhabung als cout und die ganzen streams.

Es mag vielleicht einfacher auf den ersten Blick sein, aber es ist nicht typsicher! Während es bei printf nur ärgerlich ist wird es bei scanf richtig gefährlich. Der nächste Exploit steht schon in der Tür. Übrigens sind generell funktionen mit Ellipsen eine Gefahrenquelle und sollten grundsätzlich vermieden werden, weil man eine typischere Übergabe der Parameter grundsätzlich nicht garantieren kann. Dazu kommt das die ganzen "printf" Funktionen nicht mit C++ Templates kompatibel ist, d.h. in C++ tut man sich keinerlei Gefallen auf die Formatstrings zu setzen.

dffffffffffffffff schrieb:

Aber mit den c++ streams bekommt man das ganz gewiss auch hin. Da bin ich mir sicher.

Mal wieder Unsinn von jemandem der sich überhaupt nicht auskennt. Die Streams sind im Gegensatz zu printf typsicher, und es werden keine Ellipsen verwendet. Und das sind die Hauptkritikpunkte an printf & Co. Mit der notwendigen Vorsicht kann man printf & Co. sicher nutzen, aber dazu muß man um all die Probleme wissen. Einfach Ärmel hochkrempeln und drauflos coden führt nicht zu sicherem Code.

dffffffffffffffff schrieb:

Vielleicht solltest du hier genauer erläutern warum die Leute den Fehler bei sich selber suchen sollen und warum sie es einsehen sollen.

Dein Statement für printf&Co. ist schon einmal eine ziemlich deutliche Ansage dafür, daß Du die Probleme mit diesen Funktionen nicht wirklich verstanden hast. In C gibt es Vieles, daß auf den ersten Blick einfacher zu nutzen ist als C++-Konstrukte. Schaut man mal genauer hin stellt man ganz schnell fest, daß es massenweise Probleme mit diesen anscheinend so einfachen C-Funktionen gibt. Nur diese werden von den meisten C Programmieren nicht erkannt! Resultate dieser Unwissenheit ist dann sowas Linux Exploit.

dffffffffffffffff schrieb:

Es ist doch so: Leute versuchen sich in C++, tappen in jedes vorhandene Fettnäpfchen (von denen C++ genug bereitstellt), kommen kaum voran. Zufällig/aus Frust versuchen sie eine modernere Sprache und *ding*, schau an schau an, auf einmal machen die Fortschritte und das Ergebnis kann sich bereits nach kurzer Zeit sehen lassen. Vielleicht solltest du nun diesen Leuten erklären warum sie den Fehler bei sich selbst suchen sollen, wenn es denn auch einfacher geht.

Als erstes wäre die falsche Wahl der ersten Programmiersprache. C++ ohne Anleitung durch dritte ist keine gute Wahl als Anfängersprache. Zweitens wäre da die Hartnäckigkeit von vielen Anfängern zu nennen unbedingt auf moderne C++-Anleitungen zu verzichten und im C-Sumpf herumwühlen zu müssen. Es hat schon seine Gründe, warum man zu strickter Nutzung der C++-Standard Library rät, und man kann einem Anfänger nicht erklären warum er das nicht tun soll. Denn am Anfang fehlt ihm das notwendige Wissen, die Begründung zu verstehen.

dffffffffffffffff schrieb:

Denn diese Leute haben gemerkt, dass segfaults nicht sein müssen.

Aus diesem Grund sollte man auch konsequent modernes C++ benutzen, und nicht sich in die tiefen des C Sumpfs begeben. Segfaults sind in C++ ziemlich selten, wenn man nicht meint immer wieder das Rad neu erfinden zu müssen.

P.S. Segfaults werden z.B. in Java bei solch unbedarften Personen durch Nullpointer Exceptions abgelöst. Speicherverwaltung will gelernt sein, und ein GC entbindet einem nicht davon sich über den Lebenszyklus von Objekten Gedanken zu machen.

volkard

+fricky schrieb:

volkard schrieb:

Du hast meine compilezeitberechneten Primzahlen in C mit rekursiven includes anscheinend nicht geshen.

ich glaub nicht. hast du 'nen primzahlentest wie miller-rabin mit template metaprogramming programmiert, oder wie?

nein, nicht miller-rabin und auch nicht in c++. dieser unfug geschah in c. und war natürlich viel komplizierter als das gegenstück in c++.

~john schrieb:

P.S. Segfaults werden z.B. in Java bei solch unbedarften Personen durch Nullpointer Exceptions abgelöst.

Wie machst du aus 'ner Nullpointer Exceptions einen segfault? zeig doch mal.

volkard schrieb:

dieser unfug geschah in c. und war natürlich viel komplizierter als das gegenstück in c++.

ach du schreck, das haste doch bestimmt mit __LINE__ gemacht, oder?