Verleitet C++ zum komplizierteren denken?

[HexProgrammierer]

Fusel.Factor schrieb:

Hallo lieber Forum,

bis vor kurzem habe ich nur für Desktop-Pcs entwickelt, aber jetzt habe ich hobbymäßig angefangen für Mikrocontroller zu programmieren. Dafür habe ich mir einen AVR Controller für paar Euro gekauft und mit C kann ich den auch wunderbar programmieren. Nun habe ich gemerkt, dass ich in C irgendwie alles viel simpler bzw. direkter programmiere. Bei allen meinen früheren Projekten habe ich immer sehr lange an dem Klassendesign gessen und manchmal kam es mir so vor als wollte ich unbedingt bestimmte Features von C++ benutzen nur weil es sie gibt und sie im späteren Projektverlauf sinnvol sein könnten. Geht es nur mir so oder hatten auch welche von euch dieses "Problem". Ich befürchte ich bin einfach nicht in der Lage den Spruch "Sense and simplicity" umzusetzen.

Da hast du sehr berechtigte Dinge geschrieben, die schon sehr vielen vor dir ebenfalls aufgefallen sind.

Ich versuche das Mal möglichst objektiv zu erklären:

Mit C++ ist das nämlich so eine Sache.

Das Hauptproblem ist sicherlich folgendes:

C++ ist ein Haufen Müll!

Der größte Kothaufen den die Welt gesehen hat...

bis dann Perl kam...

welches wiederum von Java als größter Kothaufen abgelöst wurde.

Also um es jetzt etwas subjektiver zu sagen:

C++ taugt nichtmal auf dem PC. Und erst recht nicht für Mikrocontroller.

Für AVRs gibt es zwei Möglichkeiten:

Assembler oder C!

Echte Programmierer nehmen natürlich Hex.

Aber ich empfehle dir als Einstieg C. Der Vorteil von Assembler ist natürlich, dass du den Kontroller besser kennen lernst, da direkter. Nachteil: Aufwendiger.

Dürfte ich anfragen was du so als Einsteigerset zur AVR-Programmierung nutzt?

Das STK500? Oder das Pollin-Board plus AVR-Programmer?

Oder machst du alles von grundauf selbst?

Fängst mit ATMega8 an oder?

Und falls du es nicht sowieso schon hast: Vergiss nicht die ganzen Kleinteile und extras, wie Taster, Kondensator, ICs, Trans, LEDs, würde auch gleich zu Anfang bereits ein einfaches Dot-Matrix LCD empfehlen.

Also nochmal kurz: Vergiss den Mist wie C++ und Bascom.
C oder Assembler ist angesagt!

C++, Java, Schäuble, Merkel, Windoof Vistarsch und Bill Gates könnte man im Grunde in einen Sack werfen, zubinden und mit nem Knüppel druf: Es würde immer den richtigen treffen.

[knivil]

player4245 schrieb:

knivil schrieb:

Nein! Vielleicht ist dein mangelndes Verstaendnis auf die geringe Erfahrung in C++/Java/... zurueckzufuehren.

natürlich ist es so. Die Klasse wird so gemacht, dass ein Objekt der Klasse einen wichtigen bestandteil des programms abdeckt, sodass man längere codebestandteile sinnvoll auslagern kann.

Einen wichtigen Bestandteil des Programms ungleich Interface fuer ein Programm. Objekte sind dazu da, Daten und dessen Funktionen zusammen zuhalten und Invarianten des Objekts zu garantieren. Kurz: Klassen/Objekte sind mehr als nur Interfaces. Interfaces kann ich auch wunderbar in C schreiben.

[volkard]

knivil schrieb:

Einen wichtigen Bestandteil des Programms ungleich Interface fuer ein Programm. Objekte sind dazu da, Daten und dessen Funktionen zusammen zuhalten und Invarianten des Objekts zu garantieren. Kurz: Klassen/Objekte sind mehr als nur Interfaces. Interfaces kann ich auch wunderbar in C schreiben.

Klassen/Objekte auch.

[byto]

knivil schrieb:

Objekte sind dazu da, [...] Invarianten des Objekts zu garantieren.

Was meinst du damit genau?

[volkard]

byto schrieb:

knivil schrieb:

Objekte sind dazu da, [...] Invarianten des Objekts zu garantieren.

Was meinst du damit genau?

http://de.wikipedia.org/wiki/Invariante_(Informatik)
Es gibt Personen, die auch Invarianten von Objekten verfolgen, zum Beispiel muß innerhalb des vectors immer gelten, daß empty()==(begin()==end()) oder in einem Ringknoten immer left->right==right->left && left->right==this. nicht immer, nur vor am beginn und ende jeder nichtprivaten methode.
Es gibt Personen, die das zum Zweck der Klasse erheben.
Also ich bin recht sicher, daß das damit gemeint ist. Aber wozu? Ein Ringknoten ist doch nicht dazu da, die Ringbedingung zu garantieren.

[+fricky]

Nexus schrieb:

Tatsache ist, dass man in C++ praktisch genauso Low-Level programmieren kann, wenn man es benötigt.

das ist mir klar, aber trotzdem wehren sich c++ user mit händen und füßen gegen lowlevel-programmierung. sie peilen lieber eine abstrakte lösung an, die beliebig kompliziert werden kann. ich schätze viele c++ programmierer (natürlich nicht alle) handeln so. die frage ist nur 'warum'?

Nexus schrieb:

Und welcher Teil der Typsicherheit passt dir nicht?

z.b. sowas:

class C
{
  public: C (int i){};
};

void func (const C &o){}

int main()
{
 func(3);  // huch? ein integer? soll doch 'const C&' sein???
}

^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?

Nexus schrieb:

+fricky schrieb:

unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.

Nicht mal Template-Metaprogrammierung ist so gang und gäbe, wie du vielleicht annimmst. Es kann zwar manchmal nützlich und interessant sein, aber viele C++-Programmierer kennen sich damit gar nicht gross aus. Mit Templates schon, aber nicht mit Metaprogrammierung. Und selbst da passiert es nicht so schnell, dass ein Compiler abstürzt.

ist mir bei irgendwelchen experimenten mit C++ schon mehr als einmal passiert, obwohl ich wirklich sehr selten einen C++ compiler anwerfe.

[knivil]

Mit Invarianz meine ich eine Eigenschaft, die unter Verwendung der Methoden garantiert wird (bzw. nie verletzt wird). Beispiel: Eine Laenge kann nie negativ werden, Ein Datum kann nie eine Monatsangabe kleiner 1 oder groesser 12 enthalten. Methoden wie setLaenge oder setDatum garantieren das.

[Nexus]

+fricky schrieb:

das ist mir klar, aber trotzdem wehren sich c++ user mit händen und füßen gegen lowlevel-programmierung. sie peilen lieber eine abstrakte lösung an, die beliebig kompliziert werden kann. ich schätze viele c++ programmierer (natürlich nicht alle) handeln so. die frage ist nur 'warum'?

Es gibt wahrscheinlich auch einige, die damit schlechte Erfahrung gemacht haben und vorerst lieber mit sichereren Methoden arbeiten, zumal man mit denen recht weit kommt. Gerade als Anfänger können solche Erfahrungen recht prägend sein. Dass die Programmierer sich allerdings mit Händen und Füssen wehren, scheint mir jedoch übertrieben, sowas würde ich nicht verallgemeinern. Aber naja...

+fricky schrieb:

^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?

Genau für diesen Fall gibt es explizite Konstruktoren. Es kann aber durchaus erwünscht sein, dass eine Konvertierung implizit geschieht, zum Beispiel wenn ein std::string erwartet wird - dann soll auch ein char* übergeben werden können. Mit dem Schlüsselwort explicit kann man dieses Verhalten unterbinden. Also kein Problem.

[volkard]

Neue These:
Die neueste Entwicklung im
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1746176.html#1746176
sagt mir, daß es daran liegt, daß die Leute die schlechter lesbare Variante einfach so als die bessere ansehen. Nichts mit Imponiergehabe oder Jobsicherung, kein Getrolle, nichtmal Spieltrieb. Einfach nur eine unterbewußte Werteinvertierung, der Ursprung ich mir aber noch nicht erklären kann.

[volkard]

+fricky schrieb:

^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?

Ist ja auch Kacke programmiert. Diese Automatikkonvertierung schreibt man natürlich nur rein, wenn sie zu keinen Problemen führt, wie Complex(double d):re(d),im(0){}
Kannst nicht mit schlechtem C++-Code nachweisen, daß C++ schlecht ist.

[+fricky]

volkard schrieb:

Neue These:
Die neueste Entwicklung im
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1746176.html#1746176
sagt mir, daß es daran liegt, daß die Leute die schlechter lesbare Variante einfach so als die bessere ansehen. ...Einfach nur eine unterbewußte Werteinvertierung, der Ursprung ich mir aber noch nicht erklären kann.

das muss aber 'ne ausnahme sein. für gewöhnlich bevorzugt der c++ coder gut lesbare, generische konstrukte, die aber innen drin komplex und akademisch sein müssen (op-überladung lässt grüssen). und die im praktischen einsatz oft seltsames verhalten an den tag legen (das zwar ungewollt, lässt sich aber nicht umgehen).

volkard schrieb:

+fricky schrieb:

^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?

Ist ja auch Kacke programmiert....
Kannst nicht mit schlechtem C++-Code nachweisen, daß C++ schlecht ist.

irgendwo muss ich ja ansetzen. das ist wie mit dem 'volatile int*', der zum 'bool' wird. solche heimlichen konvertierungen sind mit typsicherheit unvereinbar. dagegen ist sogar C, das musterbeispiel für typunsicherheit, noch typsicherer.

btw, ein 'for_each' ist doch nix anderes als eine andere schreibweise für eine for-schleife. wieso macht Badestarnds code 4 verschachtelte for-schleifen daraus? nur damit mehr komplexität reinkommt, was zu jeder hochwertigen c++ konstruktion dazugehört?

[Nexus]

+fricky schrieb:

irgendwo muss ich ja ansetzen.

Ja. Nur schade, dass du dabei immer schlechte Beispiele wählst.

+fricky schrieb:

das ist wie mit dem 'volatile int*', der zum 'bool' wird. solche heimlichen konvertierungen sind mit typsicherheit unvereinbar. dagegen ist sogar C, das musterbeispiel für typunsicherheit, noch typsicherer.

Ach komm, so langsam wird es langweilig. Fallen dir echt keine brauchbaren Beispiele ein?

Wie oft hast du schon auf std::ostream::operator<< rumgehackt? Und wie oft wurde dir dabei schon gesagt, dass das 1. kein Problem der Sprache, sondern der konkreten Implementierung, und 2. in der Praxis dermassen irrelevant ist, dass diese Konvertierung nicht wirklich ein Problem darstellt?

[+fricky]

Nexus schrieb:

...in der Praxis dermassen irrelevant ist, dass diese Konvertierung nicht wirklich ein Problem darstellt?

meinst nicht?. wenn nicht, dann bestimmt, weil der c++ coder in der praxis ohnehin mit so vielen problemen konfrontiert wird, dass diese heimtückischen, impliziten konvertierungen ihm so gut wie garnicht auffallen. und zwar so wenig, dass er sogar meint, c++ wäre eine typsichere sprache.

Nexus schrieb:

+fricky schrieb:

irgendwo muss ich ja ansetzen.

Ja. Nur schade, dass du dabei immer schlechte Beispiele wählst.

die reichen doch, das sind einfache dinge, die mir irgendwann mal aufgefallen sind. ich muss doch nicht gleich aus'm c++ fqa oder davon: http://www.fefe.de/c++/c%2B%2B-talk.pdf abschreiben

[Kenner der Programmierer]

Ad aCTa schrieb:

> Es bringt ihnen selbst etwas, weil sie sich dabei fordern.

Omg, und die sollen sich bei der Softwareherstellung fördern? Das gehört doch in den C++ Kindergarten und in keine Release-Software!!!

> Du kannst also nicht nachvollziehen, dass es tatsächlich Programmierer gibt, die Freude am Experimentieren und Kennenlernen neuer Möglichkeiten haben?

Im Projekt wird herumexperimentiert, es muss so sein. Doch meistens sind die einfachste Möglichkeiten am Ende die, die man im Code finden sollte. "Freude am Experimentieren" und Spielereien sind m.E. in der Software-Herstellung völlig fehl am Platze, in der Software heißt es testen testen testen, was sich bewährt und was performant ist und NICHT, ob C++ sowas kann.

a) Lern erst einmal zitieren, es war mir nur schwer möglich deine Antwort zu finden
b) Du musst zwischen Realität und Ideal unterscheiden. Was du als Kunde willst und was der Programmierer tut, das sind zweierlei Dinge. Es gibt natürlich auch die Gruppe von Programmierern die nie experimentieren, aber beide Gruppen haben etwas gemeinsam: ihre Werke tauchen regelmäßig auf thedailywtf.com auf

[Nexus]

+fricky schrieb:

die reichen doch, das sind einfache dinge, die mir irgendwann mal aufgefallen sind. ich muss doch nicht gleich aus'm c++ fqa oder davon: http://www.fefe.de/c++/c%2B%2B-talk.pdf abschreiben

Oh mein Gott, dieses PDF ist absolut lächerlich. Deine Argumentation wundert mich nicht mehr, wenn du deine Informationen von solchen Quellen holst.

Wenn ich sowas lese:

• Can’t throw exceptions in destructors, shouldn’t in constructors
• Initializers done in order of declaration of fields in class, not written order
• auto_ptr is useless
• Iterators don’t know anything about the container, can’t detect errors
• For a vector, at() does bounds checking, but operator[] doesn’t

1. Ist falsch. Exceptions sind unter anderem praktisch, weil man Konstruktionen abbrechen kann.
2. Hat er schon mal an den Overhead gedacht, den es mit sich bringen würde, für jeden Konstruktor eine eigene Initialisierungsreihenfolge festzulegen?
3. Ist falsch und unbegründet.
4. Ist falsch. Siehe zum Beispiel MSVC++s Checked Iterators.
5. Meine Güte, überlegt sich der Autor auch was? Warum gibt es wohl zwei Funktionen dafür?

Almost nobody actually understands the error messages.
You get an error message? You start fudging the code until it compiles.

Code leaks resources when someone throws an exception
– Have to provide assignment operator, but fail if someone does a=a;

Wenn man nicht fähig ist zu programmieren, sollte man sich nicht über die Programmiersprache aufregen.

Throwing exceptions from con/destructors
• Does not even clean up local variables!

Vollkommen daneben. Dass er von RAII gehört hat, erwarte ich gar nicht erst.

Diese Dinge zeigen ja wohl deutlich genug, dass der Autor rein gar keine Ahnung hat. Ziemlich erbärmlich, seine "Kritik".

[+fricky]

Nexus schrieb:

Deine Argumentation wundert mich nicht mehr, wenn du deine Informationen von solchen Quellen holst.

nö, ich hab' keine quellen. meine lästereien basieren auf eigenen erfahrungen und alles andere hab' ich so von anderen in meiner umgebung mitbekommen (deswegen sind sich auch nicht gerade aktuell, weil hier kaum noch jemand c++ benutzt).

Nexus schrieb:

Diese Dinge zeigen ja wohl deutlich genug, dass der Autor rein gar keine Ahnung hat. Ziemlich erbärmlich, seine "Kritik".

gar keine ahnung kannste nicht sagen. er gehört nicht zu den absoluten cracks, die für jede c++ fallgrube auch gleich den passenden umweg parat haben (so wie du vielleicht). aber jeder c++ anwender kommt irgendwann mal an den punkt, an dem er er z.b. ein delete[] anstelle eines delete hätte verwenden müssen oder der auto_ptr rumzickt. und aus dessen perspektive ist das pdf geschrieben, nicht aus expertensicht.

[volkard]

Ist doch schon bekannt, daß Anfänger damit Probleme haben. Aber was solls? Anfänger haben in C dauernd Zugiffe auf Nullzeiger und es ist in C für Anfänger unmöglich, ein Fehlermanagement hinzukriegen. Dauernd vergißt man free, weil es keine Destruktoren gibt und wird zum veralteten Single-Entry-Single-Exit getrieben. Solche "Fehler" von C kann man wohl viele Seiten lang aufschreiben und dann noch ein paar erfundene Fehler rein...
Trotzdem ist es uns zu doof, in jedem Thread über die Unzulänglichkeiten von C abzulästern.

[+fricky]

volkard schrieb:

Trotzdem ist es uns zu doof, in jedem Thread über die Unzulänglichkeiten von C abzulästern.

hast ja recht. lasst und besser wieder auf die frage konzentrieren, warum manche sprachen zu kompliziertheiten anstiften und andere nicht. gibts eigentlich noch mehr programmiersprachen, bei denen die user zur übertreibung neigen, anstatt die einfachste lösung anzustreben?
ach ja, vielleicht hängts mit der anzahl der möglichkeiten und der menschlichen psyche zusammen. viele sind ja so verdrahtet, dass sie meinen etwas komplexes, teures, glänzendes, wertvolles, gut riechendes usw. sein irgendwie 'besser' als was schlichtes, farbloses, schon in die tage gekommenes...

[volkard]

+fricky schrieb:

hast ja recht. lasst und besser wieder auf die frage konzentrieren, warum manche sprachen zu kompliziertheiten anstiften und andere nicht. gibts eigentlich noch mehr programmiersprachen, bei denen die user zur übertreibung neigen, anstatt die einfachste lösung anzustreben?

Klar. Allem voran C.
http://www.ioccc.org/

[knivil]

Wie waere es mit Perl: Executable line noise.