Ist es sinnvoll heute noch C++ anzufangen?

[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

[Bashar]

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

Du leidest an bisschen an Realitätsverlust. So gut, wie du dich mit irgendwelchen Kritiken über C++ auskennst (immerhin wesentlich besser als mit C++ selbst!), solltest du dich auch mal mit Kritiken über C beschäftigen. Was glaubst du eigentlich, was C tut, wenn du einen long zu einem float konvertierst? Oder zu einem char, oder einem bool?

@asc, würdest du bitte das Zitat korrigieren? Ich hab das nicht gesagt. Danke

[asc]

Bashar schrieb:

@asc, würdest du bitte das Zitat korrigieren? Ich hab das nicht gesagt. Danke

Sicher... Tut mir leid, keine Absicht

[+fricky]

Phoemuex schrieb:

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

...aber wie soll man diesen Code noch vernünftig weiter unterstützen, wenn man dann doch bool einführt?

das ist ja dasselbe wie 'if(p!=0)'. bei 'nem vergleich darf doch ein 'bool' entstehen (kann ja nur wahr oder falsch sein). wieso sollte sowas nicht unterstützt werden?

Phoemuex schrieb:

Zu dem Datenverlust:

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

ach, das meint ihr. naja, so'n 'floor für arme' musste schon absichtlich programmieren und 'ne warnung gibts obendrein. solche dinge (ob gewollt oder ungewollt) sind offensichtlicher, als ein operator<<, der meistens richtig funktioniert, aber wenn man pech hat, einem hinterhältigerweise 'nen pointer auf ein bit zusammenstaucht.

asc schrieb:

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

klar, C im highlevel-bereich ist schon länger tot. C++ wird in absehbarer zeit, was den highlevel-bereich angeht, wohl ebenfalls beigesetzt werden. im gegensatz zu C++ hat C aber den lowlevel-sektor fest in seiner hand. auf dem gebiet würde ich nicht so schnell mit einen dahinscheiden von C rechnen.

asc schrieb:

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

eben wegen seiner starken präsenz im embedded-bereich, taucht C in solchen statistiken auf den oberen plätzen auf.

Bashar schrieb:

Was glaubst du eigentlich, was C tut, wenn du einen long zu einem float konvertierst? Oder zu einem char, oder einem bool?

C tut das, was ich von ihm will. cout<< mit 'nem volatile int* tut etwas, das ich nicht will, obs mir nun das ergebnis von if(p!=0) oder einen cast nach bool anzeigt, ist doch nebensächlich, wenn's falsch ist.

[*john 0]

+fricky schrieb:

aber wie begegnet man mit RAII dem problem, wenn ein nicht-trivialer destruktor scheitert (was in der realität oft vorkommen kann, angenommen es gelingt nicht, eine TCP-verbindung zu schliessen, es kommt eine negative rückmeldung bei irgendeiner aktion, oder sowas)?

Exakt so wie in jeder anderen Sprache auch, man muß eine Entscheidung treffen wie man weitermacht. Ignorieren, Fehler loggen oder das Programm abbrechen => abort.

[Buqel]

Das sehe ich genauso wie +fricky.

Mal ganz davon abgesehen, dass die besten Tage für C++ definitiv vorbei sind, ist die Sprache einfach auch verdammt unübersichtlich. Fremden C Code kann man, wenn man ein geübtes Auge dafür hat, sehr schnell überfliegen. Das geht bei C++ Code halt absolut gar nicht. C++ hat zu viele mächtige und schlecht umgesetzte Features, die obendrein noch viel zu oft falsch eingesetzt werden, die das Lesen und Warten von Fremdcode einfach zum puren Horror werden lassen.

[*john 0]

Tippgeber schrieb:

Wer noch nie in einer Sprache programmiert hat in der das Plus für Stringkonkatenation steht, aber schon einmal etwas theoretische Informatik mitbekommen hat wird da sofort an das Oder aus einem regulären Ausdruck denken und nicht daran, dass hier eine Konkatenation gemeint ist.

Strings mit Stringkonkatenation ist eine Halbgruppe, so daß das Gruppenverknüpfungssysmbol "+" durchaus berechtigt ist.

[+fricky]

~john schrieb:

+fricky schrieb:

aber wie begegnet man mit RAII dem problem, wenn ein nicht-trivialer destruktor scheitert (was in der realität oft vorkommen kann, angenommen es gelingt nicht, eine TCP-verbindung zu schliessen, es kommt eine negative rückmeldung bei irgendeiner aktion, oder sowas)?

Exakt so wie in jeder anderen Sprache auch, man muß eine Entscheidung treffen wie man weitermacht. Ignorieren, Fehler loggen oder das Programm abbrechen => abort.

und was geht noch? destruktoren haben keinen rückgabewert, exceptions in destruktoren gelten als fehlerquelle. auf gewisse fehler kann man also garnicht angemessen reagieren.

~john schrieb:

Strings mit Stringkonkatenation ist eine Halbgruppe, so daß das Gruppenverknüpfungssysmbol "+" durchaus berechtigt ist.

nö, stringverkettung ist nicht assoziativ. wenn man die strings vertauscht, sieht das ergebnis anders aus.

[u_ser-l]

Invarianz gegen Vertauschung wäre Kommutativität.

Assoziativität heißt invariant gegen Klammerung:

a o (b o c) = (a o b) o c

[u_ser-l]

Konkatenation von Strings ist assoziativ, aber nicht kommutativ.

[*john 0]

+fricky schrieb:

das mach' ich nur, weil in threads wie diesem sofort völlig unsachlich auf anderen sprachen rumgehackt wird.

Du bist ein C-Fanboy und verträgst keinerlei Kritik an der Sprache und reagierst jedesmal total unsachlich darauf. So ziemlich jede Sprache hat Macken, daß Dir die schlimmsten C++ Macken (es gibt einige ganz häßliche Dinge) gar nicht bekannt sind, ist ein deutliches Zeichnen dafür, daß Du Dich nie richtig mit der Sprache auseinander gesetzt hast. Andernfalls würdest Du sie kennen.

+fricky schrieb:

bereits die erste(!) antwort ist das beste beispiel (~john: schlechter code des linux kernel, weil in C geschrieben).

Das ist objektiv wahr, der Linux Kernel enthält schlechten Code. Auch in C hätte man es besser machen können, nur ist das so, daß C für viele Konstrukte nur Konvetionen bereithält und das bei vielen Entwicklern, die über die ganze Welt verteilt sind, zu Problemen führen kann und im konkreten Fall zu Problemen geführt hat und auch weiterhin wird. Eine andere Sprache wäre sinnvoller gewesen, da sie es nicht so einfach macht an Interfaces vorbei zu programmieren.

Wenn man sich damit auseinandersetzt welche Alternativen es gibt, dann ist die Auswahl effektiv relativ gering. Unter der Maßgabe der freien Toolchain und der direkten Compilierbarkeit bleiben nicht viele Sprache als Alternative übrig.
gcc unterstützt direkt: Ada, C, C++, Fortran, Objective-C (und Java)
Objective-C unterstützt LowLevel Aufgaben kein Deut besser als C.
Fortran, muß man noch was dazu schreiben
C++ überfordert viele Personen
Ada wäre mein Favorit für einen Kernel
Java, das wird spaßig ohne GC und so
D ist einfach zu neu

[Bashar]

+fricky schrieb:

C tut das, was ich von ihm will. cout<< mit 'nem volatile int* tut etwas, das ich nicht will

Aber du willst das, was C dir zu fressen vorgibt. Tu doch nicht so, als ließen sich deine subjektiven Ansichten irgendwie objektiv begründen.

[Bashar]

~john schrieb:

Strings mit Stringkonkatenation ist eine Halbgruppe, so daß das Gruppenverknüpfungssysmbol "+" durchaus berechtigt ist.

Komische Begründung. Wenn es eine abelsche Gruppe wäre, wäre + gerechtfertigt.

[asc]

+fricky schrieb:

klar, C im highlevel-bereich ist schon länger tot. C++ wird in absehbarer zeit, was den highlevel-bereich angeht, wohl ebenfalls beigesetzt werden.

Das wird aber noch Jahre dauern (bestehende Software), zudem gibt es noch immer Firmen die aktiv auf C++ setzen und neue Projekte darin aufsetzen (Überwiegend habe ich so etwas im QT-Bereich bemerkt, des weiteren bezweifel ich das im Spielesektor C++ allzu schnell verschwindet).

+fricky schrieb:

im gegensatz zu C++ hat C aber den lowlevel-sektor fest in seiner hand.

Wobei es im Automotive und Embedded-Systems bereich durchaus Firmen gibt die C++ verwenden. Daher: Rückgang ja, aber warten wir erstmal etwas ab, die nächsten 10 Jahre wird man sicherlich noch von Zeit zu Zeit Stellenausschreibungen für C++ Entwickler finden. Totgeglaubte leben länger (Sah man ja auch an der WinAPI die erst heute etwas Konkurrenz bekommt [WPF setzt nicht mehr auf die WinAPI, sondern auf DirectX]).

+fricky schrieb:

eben wegen seiner starken präsenz im embedded-bereich, taucht C in solchen statistiken auf den oberen plätzen auf.

Wenn ich meinen Blick auf eine Nische begrenze kann ich jede Statistik in eine gewünschte Richtung bringen. Davon abgesehen: Was ist gegen einen starken 2ten Platz einzuwenden?

[+fricky]

u_ser-l schrieb:

Invarianz gegen Vertauschung wäre Kommutativität.
Assoziativität heißt invariant gegen Klammerung:

a o (b o c) = (a o b) o c

danke, hab's verwechselt.

~john schrieb:

...daß Dir die schlimmsten C++ Macken (es gibt einige ganz häßliche Dinge) gar nicht bekannt sind, ist ein deutliches Zeichnen dafür, daß Du Dich nie richtig mit der Sprache auseinander gesetzt hast. Andernfalls würdest Du sie kennen.

dann sollte ich wohl froh sein, mich nie intensiv mit C++ auseinandergesetzt zu haben. jedenfalls hat mich anfangs schon einiges genervt, so dass ich schnell umgestiegen bin.