Verleitet C++ zum komplizierteren denken?
-
oooooooooooooooooooo schrieb:
Array<int>()-1-2-3-4-5Ist 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.
-
+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
newunddeleteerklä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 wiestd::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.
-
+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.
-
+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?
-
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.
-
+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?
-
+fricky schrieb:
ach du schreck, das haste doch bestimmt mit __LINE__ gemacht, oder?
#define und files, die sich selber inkludieren.
-
Naja, die Stdlib von C++ würde ich trotzdem noch mit Vorsicht genießen, gerade bei Anfängern.
Der Anfänger kann nicht verstehen, wieso er lieber vector statt eigenen Klassen verwenden soll? Dann sollte er erst verstehen, wieso. Es hat mir mehr gebracht, eine eigene doppel verkettete Liste zu bauen und dann zu erfahren, dass es die STL gibt als umgekehrt. Als C++-Programmierer sollte man mit allen Wassern gewaschen sein, und es ist doch besser, etwas im C-Sumpf zu beginnen, Probleme von C zu zeigen und dann im Laufe der Lernphase Lösungsvorschläge von Seiten C++ zu servieren á la STL.
-
volkard schrieb:
+fricky schrieb:
ach du schreck, das haste doch bestimmt mit __LINE__ gemacht, oder?
#define und files, die sich selber inkludieren.
dann bist du vielleicht identisch mit diesem typ hier: http://www.ioccc.org/2004/vik2.hint
-
+fricky schrieb:
dann bist du vielleicht identisch mit diesem typ hier: http://www.ioccc.org/2004/vik2.hint
Abgefahrene Messungen:
(*) Before cpp crashed.
-
~john schrieb:
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.
wenn du ein bisschen paranoid bist (oder auch nicht), dann lässte 'nen statischen code-checker wie lint bzw. splint drüberlaufen. der findet mehr potentielle fehler als jeder c++-compiler mit seiner angeblich so tollen typsicherheit.
abc.w schrieb:
Abgefahrene Messungen:
(*) Before cpp crashed.
unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.
-
+fricky schrieb:
unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.
Falsch.
-
Wie soll denn C++ rechnen, während der Compiler die Templates auflöst? Runtime != Compiletime!
-
Der Grund warum Programmierer gerne eine komplexe Lösung bevorzugen ist ganz simpel: sie wollen sich selbst bei der Aufgabe fordern.
Für viele ist das Programmieren mehr als nur eine Tätigkeit um seine Brötchen zu verdienen und daher ist der Drang da sich immer wieder an neue Grenzen zu bringen.
-
Oder sie wollen sich im Projekt unsterblich machen. Ist nüchtern betrachtet ne legitime Angelegenheit.
-
Sie wollen höchstens angeben und prahlen...
Was bringts, wenn sie komplizierte closed-source-apps bauen?
Wem bringts was, wenn sie unnütz-komplizierte open-source-apps bauen?Alles sollte so einfach wie möglich gemacht sein, aber nicht einfacher.
-EinsteinDas Zitat ist auf C++ geradezu zugeschnitten.
-
Ad aCTa schrieb:
Sie wollen höchstens angeben und prahlen...
Was bringts, wenn sie komplizierte closed-source-apps bauen?
Wem bringts was, wenn sie unnütz-komplizierte open-source-apps bauen?Es bringt ihnen selbst etwas, weil sie sich dabei fordern.