Ist es sinnvoll heute noch C++ anzufangen?

[Tippgeber]

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

[tntnet]

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

[+fricky]

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.

[JustAnotherNoob]

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.

[knivil]

Allgemeiner Quark ...

[+fricky]

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.

[JustAnotherNoob]

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.

[+fricky]

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.

[Bashar]

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

[u_ser-l]

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

[Artchi]

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

[asc]

Artchi schrieb:

C++ ist schlecht und keiner braucht es...

...und niemand verdient damit sein Lebensunterhalt, und es gibt auch keine Firmen wo eine Abkehr von C++ nicht direkt ansteht.

Wenn ich selbst nicht die Firma irgendwann wechsel, werde ich wohl noch in 10 Jahren mit C++ mein Brot verdienen (egal wie +fricky die Sprache hasst).

cu André

[+fricky]

Bashar schrieb:

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

so gesehen hast du schon recht, aber es wäre ganz nett, wenn der compiler mit 'nem fehler abbrechen würde, falls keine passende überladung definiert wurde. stattdessen wird's zu bool (ein datentyp, wie er weiter entfernt von einem volatile int* nicht sein kann). das ist total doof.

asc schrieb:

Wenn ich selbst nicht die Firma irgendwann wechsel, werde ich wohl noch in 10 Jahren mit C++ mein Brot verdienen

kann sein, aber die wahrscheinlichkeit ist ziemlich gering.

Artchi schrieb:

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.

das mach' ich nur, weil in threads wie diesem sofort völlig unsachlich auf anderen sprachen rumgehackt wird. bereits die erste(!) antwort ist das beste beispiel (~john: schlechter code des linux kernel, weil in C geschrieben). sowas kann man doch nicht unkommentiert stehen lassen.

[asc]

+fricky schrieb:

asc schrieb:

Wenn ich selbst nicht die Firma irgendwann wechsel, werde ich wohl noch in 10 Jahren mit C++ mein Brot verdienen

kann sein, aber die wahrscheinlichkeit ist ziemlich gering.

Nein, sie ist sogar extrem hoch. Alleine schon weil der Chef es so sieht, wir eine (für die Firmengröße) breite Installationsbasis haben, und für eine Migration auf ein anderes System (C# wäre aus meiner Sicht von der Anwendung und Zielrichtung her eine Alternative) nicht genügend Anreiz existiert.

Wenn du so betriebsblind bist um einen Anwendungsfall zu sehen, heißt dies noch lange nicht, das es Firmen ebenso sehen. Zumal es auch einfach genügend Software auf C++ Basis gibt die weiterentwickelt wird, und auch in einigen Bereichen C++ nur langsam verdrängt wird (z.B. Spieleentwicklung). Dies gilt auch für viele andere Sprachen, in dem einfach bereits genügend Software existiert.

+fricky schrieb:

...bereits die erste(!) antwort ist das beste beispiel (~john: schlechter code des linux kernel, weil in C geschrieben). sowas kann man doch nicht unkommentiert stehen lassen...

Ach, und du musst dich gleich auf das Niveau herunterziehen und weitermachen? Davon abgesehen das zwei Seiten einer Medaille gibt. Die einen finden C++ syntaktisch schlechter als C, die anderen C schlechter als C++. Ich würde (zumindest in meinen Anwendungsbereich) kein neues Projekt mit einer von beiden Sprachen beginnen (und wenn dann noch eher C++ wegen den höheren Abstraktionsgrad).

Und selbst auf Embedded Systemen gibt es durchaus (größere) Firmen die unter anderem C++ einsetzen, auch wenn dies eher eine C-Domäne ist.

Ich sehe es zwar auch so, das die Verbreitung von C++ zurück geht (dies gilt aber auch für C), dennoch wird es nicht einfach so sterben.

cu André

[Bashar]

+fricky schrieb:

es wäre ganz nett, wenn der compiler mit 'nem fehler abbrechen würde, falls keine passende überladung definiert wurde. stattdessen wird's zu bool (ein datentyp, wie er weiter entfernt von einem volatile int* nicht sein kann). das ist total doof.

Die allgegenwärtigen impliziten Typumwandlungen sind ein Erbe von C, das C++ bis zum Ende mit sich herumschleppen wird. Vielleicht wäre es besser ohne.

[asc]

Bashar schrieb:

Die allgegenwärtigen impliziten Typumwandlungen sind ein Erbe von C, das C++ bis zum Ende mit sich herumschleppen wird. Vielleicht wäre es besser ohne.

Es wäre wirklich nicht dumm diese Projektweit als Warnung/Fehler melden zu können (Sprich: zumindest eine optionale Prüfung). Erst vor ein paar Tagen ein Fehler durch Zufall gefunden, der unbemerkt über Jahre hinweg zu Rundungsfehlern (zum Glück weder in einem finanziellen, noch lebenswichtigen Bereich) geführt hat. Merkwürdig nur das ihn selbst die Kunden nicht bemerkt haben...

[+fricky]

asc schrieb:

+fricky schrieb:

asc schrieb:

Wenn ich selbst nicht die Firma irgendwann wechsel, werde ich wohl noch in 10 Jahren mit C++ mein Brot verdienen

kann sein, aber die wahrscheinlichkeit ist ziemlich gering.

Nein, sie ist sogar extrem hoch. Alleine schon weil der Chef es so sieht, wir eine (für die Firmengröße) breite Installationsbasis haben, und für eine Migration auf ein anderes System (C# wäre aus meiner Sicht von der Anwendung und Zielrichtung her eine Alternative) nicht genügend Anreiz existiert.

ich weiss nicht, was ihr für software macht, aber für micht hört's sich so an, als hängt ihr ziemlich an microsofts nabelschnur. darauf, dass m$ in 10 jahren noch C++ unterstützt, würde ich nicht wetten. 10 jahre sind, in der it-welt, eine sehr lange zeit.

asc schrieb:

Ich sehe es zwar auch so, das die Verbreitung von C++ zurück geht (dies gilt aber auch für C)...

ich sehe keine anzeichen für einen rückgang von C. C hat sich im lowlevel-bereich sehr stark etabliert. vielleicht ist C nicht das optimum, vielleicht wäre z.b. ADA eine geeignetere sprache. aber bevor irgendeine andere sprache C von seinem thron stossen kann, müssen noch 'ne menge bits den bus runterfliessen.

Bashar schrieb:

+fricky schrieb:

es wäre ganz nett, wenn der compiler mit 'nem fehler abbrechen würde, falls keine passende überladung definiert wurde. stattdessen wird's zu bool (ein datentyp, wie er weiter entfernt von einem volatile int* nicht sein kann). das ist total doof.

Die allgegenwärtigen impliziten Typumwandlungen sind ein Erbe von C, das C++ bis zum Ende mit sich herumschleppen wird. Vielleicht wäre es besser ohne.

aber die automatischen typumwandlungen, die C macht, führen nicht zu datenverlust. einen pointer zu 'nem bool zu machen ist völlig hirnverbrannt. das kann sich C++ unmöglich von C abgeschaut haben.

[Phoemuex]

+fricky schrieb:

aber die automatischen typumwandlungen, die C macht, führen nicht zu datenverlust. einen pointer zu 'nem bool zu machen ist völlig hirnverbrannt. das kann sich C++ unmöglich von C abgeschaut haben.

Folgendes ist doch legaler C-Code, oder?

int main(void)
{
   int a = 0;
   int *p = &a;
   if(p)
   {
      //blub
   }
}

Gut, es gibt in C kein bool im eigentlichen Sinne, aber wie soll man diesen Code noch vernünftig weiter unterstützen, wenn man dann doch bool einführt?

Zu dem Datenverlust:

double a = 5.1234567;
int b = a; //Nein, hier findet kein Datenverlust statt...

[asc]

+fricky schrieb:

ich weiss nicht, was ihr für software macht, aber für micht hört's sich so an, als hängt ihr ziemlich an microsofts nabelschnur...

Eher an der von Codegear, aber davon abgesehen: Auch wenn ich glaube das die MS-Monokultur mit der Zeit immer weniger wird, glaube ich nicht das es innerhalb von 10 Jahren zu einem Umbruch kommt. Dazu gibt es einfach für viele keine Umfassenden Alternativen (Für einige ja, aber beileibe nicht für alle).

Und solange 0815-Anwender bereits unter Windows Probleme haben, wie soll es dann erst mit ein paar anderen Betriebssystemen sein, wo sie bei einem Problem erst teilweise kryptische Manuals durchsuchen müssen. MacOS mag für diese Klientel vielleicht passend sein, aber bereits bei den Spielern wird es heikel.

Meine Prognose ist eher: Sofern nicht etwas bahnbrechendes passiert wird Windows auf Clientrechnern maximal 2% Markanteil pro Jahr (und dies ist wenn ich mir die vergangenen 5 Jahre anschaue schon sehr hoch gegriffen) verlieren. Nehmen wir diese eher Gegen MS gerichtete Prognose würden der Marktanteil in 20 Jahren noch immer ca. 50% in dem Segment betragen.

+fricky schrieb:

...10 jahre sind, in der it-welt, eine sehr lange zeit.

Stimmt, dennoch sollte man nicht am Markt vorbei entwicheln, und der ist jedenfalls in absehbarer Zeit nicht unser Problem. Zumal ich glaube das unser Programm von der Größe her durchaus bei paralleler Pflege bequem in maximal 3 Jahren komplett auf eine andere Plattform migriert werden kann.

+fricky schrieb:

asc schrieb:

Ich sehe es zwar auch so, das die Verbreitung von C++ zurück geht (dies gilt aber auch für C)...

ich sehe keine anzeichen für einen rückgang von C. C hat sich im lowlevel-bereich sehr stark etabliert.

Aber selbst dieser Markt ist im Wandel und Außerhalb vom Lowlevel-Bereich sind die Stellen nach meiner Erfahrung für C und C++ im Rückgang (wenn ich von meiner Bewerbungszeit zurückschließe). Ich würde mich jedenfalls nicht an C festbeißen, ebenso wenig wie auf C++. Aber auch hier gilt: Veränderungen erfolgen nicht von heute auf morgen, und langfristige Projekte schwenken auch nur selten um. Ich rechne sowohl in C wie auch in C++ damit das auch noch in 20 Jahren die Sprachen eine gewisse Verbreitung haben (Vielleicht in Nischen, aber ich tippe noch auf Plätze in den Top20 der Programmiersprachen).

+fricky schrieb:

aber bevor irgendeine andere sprache C von seinem thron stossen kann, müssen noch 'ne menge bits den bus runterfliessen.

TIOBE Programming Community Index for July 2009

Auf dem Thron befindet sich C jedenfalls schon seit geraumer Zeit auf vielen Statistiken nicht mehr (und die von TIOBE halte ich für nicht die schlechteste), auf einen Podiumsplatz aber durchaus. Interessanterweise liegt C++ wieder auf Platz 3 (Auch wenn sich das wohl in einigen Monaten wieder zu Platz 4 entwickelt). Und 10,4% bei C++ finde ich nicht wenig, wenn der erste Platz [Java] auf 20,4% liegt.

+fricky schrieb:

aber die automatischen typumwandlungen, die C macht, führen nicht zu datenverlust. einen pointer zu 'nem bool zu machen ist völlig hirnverbrannt. das kann sich C++ unmöglich von C abgeschaut haben.

Ach? "if(!pointer)" ist also in C nicht möglich?

cu André

[Gast]

Hallo

asc schrieb:

Ach? "if(!pointer)" ist also in C nicht möglich?

cu André

Ich dachte immer, dass hier der pointer implizit in ein int gecastet wird?

chrische