Verleitet C++ zum komplizierteren denken?

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.

byto

Oder sie wollen sich im Projekt unsterblich machen. Ist nüchtern betrachtet ne legitime Angelegenheit.

Ad aCTa

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.
-Einstein

Das 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.

Nexus

+fricky schrieb:

naja, aber dann frage ich mich warum bei einigen nur grütze rauskommt. [...] 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.

Aha, und dieser Fall lässt dich auf den durchschnittlichen C++-Programmierer schliessen? C++ ist nicht die einzige Sprache, in der man schlecht programmieren kann (aber da geht es besonders gut, ich weiss...).

Einige Features haben zudem ihren Preis, für gewisse Dinge ist C ganz klar geeigneter. Aber darum gehts nicht. Tatsache ist, dass man in C++ praktisch genauso Low-Level programmieren kann, wenn man es benötigt. Dass das meistens nicht der Fall ist, erklärt die hohe Abstraktionsebene.

+fricky schrieb:

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.

Wieso nicht gleich eingebaute Mechanismen verwenden, wenn einem das C++ von sich aus bietet? Und welcher Teil der Typsicherheit passt dir nicht?

+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.

Nexus

Ad aCTa schrieb:

Sie wollen höchstens angeben und prahlen...

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

Ad aCTa

> 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.

Nexus

Ad aCTa schrieb:

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.

Okay, dann hab ich dich wohl falsch verstanden. Ich meinte eher Fälle wie der verlinkte Thread hier oder andere Diskussionen, die es im C++-Forum ab und zu gibt. Oft geht es dabei gar nicht um den produktiven Einsatz.

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.

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.

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?