Verleitet C++ zum komplizierteren denken?

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

[+fricky]

volkard schrieb:

http://www.ioccc.org/

gilt nicht, die machen es da mit absicht unleserlich. normalerweise programmiert man in C ziemlich straight (sagte ja schon der thread-starter). man muss sich sogar richtig anstrengen, um unnötig verzwicktes zeug in C zu coden. denk doch nur mal an deinen primzahlengenerator von gestern.

[volkard]

+fricky schrieb:

volkard schrieb:

http://www.ioccc.org/

gilt nicht, die machen es da mit absicht unleserlich.

Die Existenz und Größe dieses Wettbewerbs und die Qualität der Siegerbeiträge zeigt doch, daß es den C-Proggern außerordentlichen Spaß macht.

[audacia]

volkard schrieb:

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

Das gibt es für C++ auch. Ist nur etwas praxisorientierter und nennt sich Boost.
</troll>

[volkard]

audacia schrieb:

volkard schrieb:

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

<troll>
Das gibt es für C++ auch. Ist nur etwas praxisorientierter und nennt sich Boost.
</troll>

rofl.