Ist es sinnvoll heute noch C++ anzufangen?
-
JustAnotherNoob schrieb:
cout.write ("foo").write (42).write (3.14159).write (endl);
findest du das übersichtlich?
Nein. Übersichtlich finde ich das:
printf ("foo %d %f", 42, 3.14159);
-
Dravere schrieb:
+fricky schrieb:
nicht verbieten, sondern garnicht erst einbauen, ...
Und wo ist der Unterschied?
verbieten = jemandem etwas untersagen, möglicherweise unter androhung von strafe oder ähnlichen konsequenzen.
einbauen = etwas zu etwas anderem hinzufügen, so daß es bestandteil dessen wird.audacia schrieb:
Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz.
nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.
Dravere schrieb:
audacia schrieb:
Zusätzlich versteht auch jeder C-Programmierer, daß es da nicht um Bitshifting geht
Jetzt müssen wir schon eine Sprache wegen +fricky anpassen?
nur das abschaffen der vergewaltigten shifts, würde mir aber lange nicht reichen.
-
Also um mal auf das Ausgangsposting zurückzukommen, ich würde C++ heutzutage NICHT mehr einsetzen. Einen triftigen Grund gibt es für die Sprache nicht mehr, da hast du schon Recht. In den späten 80'ern und den 90'ern mag C++ sinnvoll gewesen sein, aber heutzutage gibt es einfach bessere Sprachen.
Das Verhängnis von C++ ist halt, dass es eine Sprache für alles sein wollte und so weder am einen noch am anderen Ende die Bedürfnisse vernünftig zufriedenstellen kann. Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.
-
quniox schrieb:
Also um mal auf das Ausgangsposting zurückzukommen, ich würde C++ heutzutage NICHT mehr einsetzen. Einen triftigen Grund gibt es für die Sprache nicht mehr, da hast du schon Recht. In den späten 80'ern und den 90'ern mag C++ sinnvoll gewesen sein, aber heutzutage gibt es einfach bessere Sprachen.
Das Verhängnis von C++ ist halt, dass es eine Sprache für alles sein wollte und so weder am einen noch am anderen Ende die Bedürfnisse vernünftig zufriedenstellen kann. Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.
^^diese posting bringt alles auf den punkt
leute, wir können den thread hiermit als beendet betrachten
-
Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.
Der Entwickler in der Praxis benutzt es.
-
+fricky schrieb:
audacia schrieb:
Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz.
nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.
Was passiert deiner Meinung nach denn in diesem Fall?
-
scheinbar ist es gerade der Kompromiß aus nicht bis in die letzte Konsequenz umgesetzten Prinzipien, die eine Sprache praxistauglich machen. Bei C++ die Mischung aus angedeuteter OO, mit low-level-features bei Bedarf sowie C-Kompatibilität. Reine OO unter Beibehaltung der C-Kompatibilität wäre wohl sowieso unmöglich. Objekte und Adreßarithmetik, Zeiger und GC, das paßt nicht.
Paradigmenreine Sprachen haben dagegen mit Akzeptanzproblemen zu kämpfen oder gelten als ewige "Sprache der Zukunft", das war schon immer so und wird scheinbar auch so bleiben.
"Die einen Sprachen werden gelobt, die anderen verwendet" - wer hat das gesagt? Ich weiß, wer etwas Ähnliches gesagt hat, hat sogar mit C++ zu tun.
-
nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.
Gib mal einen Verweis auf den Standard, denn wenn das was seltsames machen soll, dann ist der GCC nicht Standardkonform, denn das hier:
#include <iostream> using namespace std; int main() { volatile int i(2); cout << i; }gibt bei mir 2 aus.
-
sorry für die verwirrung, es muss natürlich ein pointer sein:
volatile int *p = (volatile int*)0x1234; printf ("%p\n", p); // ok cout << p << endl; // 1?
-
+fricky schrieb:
sorry für die verwirrung, es muss natürlich ein pointer sein:
volatile int *p = (volatile int*)0x1234; printf ("%p\n", p); // ok cout << p << endl; // 1?Schönes Beispiel, will man allerdings die referenzierte Adresse ausgeben so *muss* man diesen nach void* casten. Damit will ich nicht behaupten, dass du unrecht hast, sondern, dass hier ein anderer Fallstrick vorliegt (jeder würde ja intuitiv erwarten, dass man einen Zeiger wie alles andere auch ausgeben kann).
-
+fricky schrieb:
sorry für die verwirrung, es muss natürlich ein pointer sein:
volatile int *p = (volatile int*)0x1234; printf ("%p\n", p); // ok cout << p << endl; // 1?Wie sinnvoll ist es, den Wert eines Zeigers auszugeben? Ich sehe keinen praktischen Nutzen bzw. praktischen Nachteil darin. Da gibt es sicher andere interessante Konstrukte, um C++ zu kritisieren.
Hier wird der Zeiger zur Ausgabe implizit in einen bool gecastet. Nicht unbedingt sinnvoll oder intuitiv, aber nicht wirklich problematisch.
-
Tippgeber schrieb:
...will man allerdings die referenzierte Adresse ausgeben so *muss* man diesen nach void* casten.
aber seltsam: mit 'nem int*, ohne 'volatile' davor, gibts die erwartete (richtige) ausgabe auch ohne cast.
tntnet schrieb:
Wie sinnvoll ist es, den Wert eines Zeigers auszugeben? Ich sehe keinen praktischen Nutzen bzw. praktischen Nachteil darin.
wenn man c++-fanboys zeigt, welch komische faxen mit ihrer sprache möglich sind, wird oft die sinnhaftigkeit der gesamten aktion in frage gestellt. woran liegts? selbstverständlich ist es manchmal sinnvoll, den wert eines zeigers auszugeben.
tntnet schrieb:
Da gibt es sicher andere interessante Konstrukte, um C++ zu kritisieren.
ich weiss. manche füllen 90% ihres webauftritts damit.
tntnet schrieb:
Hier wird der Zeiger zur Ausgabe implizit in einen bool gecastet.
was ja wohl das verkehrteste überhaupt ist.
-
was ja wohl das verkehrteste überhaupt ist.
Richtig, aber das hat mit Operatorenüberladung grad mal gar nix zu tun, wie du behaupted hast, sondern ist ein Nachteil der starken Typisierung, die 1. auch in deinem geliebtem Java existert und 2. mehr Vor- als Nachteile bringt.
wenn man c++-fanboys zeigt, welch komische faxen mit ihrer sprache möglich sind, wird oft die sinnhaftigkeit der gesamten aktion in frage gestellt. woran liegts? selbstverständlich ist es manchmal sinnvoll, den wert eines zeigers auszugeben.
wenn man einem java-fanboy zeigt, welche Dinge mit Java alles nicht möglich ist, wird oft die Sinnhaftigkeit der ganzen Aktion in Frage gestellt, woran liegts? Selbstverständlich ist es manchmal sinnvoll Operatoren zu überladen.
-
Allgemeiner Quark ...
-
JustAnotherNoob schrieb:
Richtig, aber das hat mit Operatorenüberladung grad mal gar nix zu tun, wie du behaupted hast...
indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.
JustAnotherNoob schrieb:
sondern ist ein Nachteil der starken Typisierung, die 1. auch in deinem geliebtem Java existert und ...
in einer stark typisierten sprache wäre ein cast von 'volatine int*' nach bool überhaupt nicht möglich. aber kannst gern mal selbst ausprobieren, was du in Java alles in einen boolean casten kannst.
-
indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.
Das wäre bei einer anderen Funktion nicht anders, deswegen hats mit Operatorenüberladung nichts zu tun.
in einer stark typisierten sprache wäre ein cast von 'volatine int*' nach bool überhaupt nicht möglich. aber kannst gern mal selbst ausprobieren, was du in Java alles in einen boolean casten kannst.
Ja, sorry, mein Fehler. Es liegt jedenfalls an der stärkeren Typisierung als in C.
Wie auch immer, es ist jedenfalls eine Schwäche von C++, aber keine, die man besonders oft zu spüren bekommt. Dass C++ perfekt ist hat wohl niemand behauptet.
-
JustAnotherNoob schrieb:
indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.
Das wäre bei einer anderen Funktion nicht anders, deswegen hats mit Operatorenüberladung nichts zu tun.
natürlich hat es damit zu tun. bei 'ner funktion:
printThatFuckingPointerValue(void *p)siehste allein schon am namen, was sie machen soll. ein operator<< mit 1000 überladungen, der eigenmächtig (und fälschlicherweise) pointer in 'bools' castet, ist einfach nur mist.
zu op-überladungen schau auch mal hier: http://cafe.elharo.com/blogroll/operator-overloading-considered-harmful/JustAnotherNoob schrieb:
Dass C++ perfekt ist hat wohl niemand behauptet.
das würd wohl auch keiner wagen, so weit wie C++ von perfektion entfernt ist.
-
+fricky schrieb:
natürlich hat es damit zu tun. bei 'ner funktion:
printThatFuckingPointerValue(void *p)siehste allein schon am namen, was sie machen soll.Die würde aber nicht anwendbar sein für deinen volatile-Pointer. Außerdem müsstest du die Funktion print nennen und für genau dieselben Typen anwenden, für die du auch den operator<< anwendest. Du bist ja schließlich nur gegen Operatorüberladung, und nicht auch gegen Funktionsüberladung.
Und dann würdest du feststellen, dass print(myvolatilepointer) auch den bool-Overload greift. IOW, das Problem hat mit Operatorüberladung überhaupt nichts zu tun.
Es hat was mit der Semantik von volatile zu tun und wurde offenbar in der IOStreams-Library vergessen. Man bräuchte halt eine Überladung für const volatile void*, nicht nur const void*. 99% aller C++-Entwickler merken das aber nicht, weil man volatile nicht gerade jeden Tag braucht.ein operator<< mit 1000 überladungen, der eigenmächtig (und fälschlicherweise) pointer in 'bools' castet, ist einfach nur mist.
zu op-überladungen schau auch mal hier: http://cafe.elharo.com/blogroll/operator-overloading-considered-harmful/Das ist ein Effekt der Überladung an sich, nicht der Operatorüberladung. Und in Java kann dir sowas natürlich nicht passieren, weils da weder const noch volatile noch Pointer überhaupt gibt, die man ausgeben wollen könnte.
-
Operatorüberladung ist ein Spezialfall von Polymorphie, und Polymorphie ist ein Prinzip der OOP.
Das ist in C++ nur nicht so leicht zu erkennen, aber in der "reinen Lehre" der OO gibt es nur objects und messages, und ein Operatorsymbol ist nichts Anderes als eine message an ein object.
Da gleichlautende Nachrichten an Objekte verschiedener Klassen nicht nur erlaubt, sondern sogar erwünscht (Polymorphie) sind, ist an der Operatorüberladung doch grundsätzlich nichts auszusetzen, solange die Symbole vernünftig gewählt werden (und nicht etwa "+" benutzt wird, um Elemente aus einer Liste zu entfernen ...)
-
+fricky schrieb:
.... bla bla bla...
so weit wie C++ von perfektion entfernt ist.
Leg mal ne andere Platte auf! Scheint nen Sprung drin zu sein.
Wir wissen das so langsam, das du zwar C++ hasst obwohl du es nicht kennst, aber jede Woche hier abhängst, um deine Minderwertigkeitskomplexe zu kompensieren. So langsam wird es langweilig.C++ ist schlecht und keiner braucht es... kann dir nur zustimmen.