Erst C oder gleich C++ ???

[asc]

dfgdfgdfg schrieb:

asc schrieb:

C++ : [...] Bietet zusätzlich die Möglichkeiten der generischen Programmierung (bei gleichzeitiger Typsicherheit) und der direkten Unterstützung von OO-Konzepten.

cu André

Wow! Applaus! Soll jetzt jeder Luftsprünge machen?
Das was du da tolles für C++ vorstellst, ist das selbstverstöndlichste auf der welt.

Interessanterweise ist die generische Programmierung in den "Mainstream"-Sprachen erst mit C++ wirklich eingekehrt. Als selbstverständlich würde ich das also nicht nennen (Generics & Co in Sprachen wie Java/C# kamen erst danach)

dfgdfgdfg schrieb:

C++ ruht sich auf Lohrbeeren aus, die schon seit ~30 jahren als etwas selbstverstäünliches in highlevelsprachen sind.

So? Ich wusste noch gar nicht das Templates in C++ 30 Jahre alt sind (Den darauf beziehe ich mich u.a.). Dir ist hoffentlich bewusst das die Sprache C++ im Wandel ist, C++98, TR1 (C++03), C++09 seien hier nur genannt.

[Tachyon]

~fricky schrieb:

...sabbel...

Ist klar, weil einem so wenig unsichere Konstrukte in C++ einfallen, muss eben delete herhalten.
Mir fallen da jede Menge Dinge in C ein, die unsicher sind. Das fängt schon beim printf/scanf an, geht über das gesamte Bastelei mit Strings und Arrays bis hin zu so tollen Sachen wie die wenigen Standardalgorithmen die absolut 0 Typsicherheit bieten.
Man muss eben wissen, was man tut. Das gilt, wer hätte das gedacht, auch für C++, Ada und alle möglichen anderen Sprachen.
In C braucht es Disziplin um was Ordentliches zu Stande zu bringen. In C++ muss man sich von alten Strukturen lösen und auf C++-Konstrukte umsatteln. Das fällt Anachronisten (und C++ ist heute nicht mehr das, was es war als es besagte Anachronisten offensichtlich ausprobiert haben) oft schwer, und deshalb kommt oft Schrott dabei raus.
Ich weiß nicht wie andere Leute C++ programmieren (bei fricky habe ich allerdings so eine grobe Vorstellung), aber bei mir deckt der Compiler bereits die meisten Fehler auf. Die Fehler die noch da sind, sind meist eher Logikfehler. Und die hätte man in jeder Sprache.

Um auf die Frage des TOs zurückzukommen:
Wenn es um die Wahl zwischen C und C++ geht und sonst keine Sprachen in Frage kommen, würde ich mit C++ beginnen, und mir auch ein richtiges C++-Buch dazu kaufen (und keines das mit C in Klassen, C++ mit Visual Studio oder sonstigem Quark beginnt). Dann ist C++ auch einfacher als C.

[Shade Of Mine]

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?
bei anfängern vielleicht, aber ich hab das eigentlich noch nie in einem produktiv code gesehen.

[asc]

~fricky schrieb:

trotzdem wird C++ in solchen bereichen eher selten verwendet, sondern stattdessen C. warum? aus unwissenheit, traditionsbewusstsein oder aus gutem grund?

Keine Ahnung. Ich weiß zwar das C z.B. im Embedded-Bereich häufig ist, aber die eizigen Bekannten in dieser Branche die ich kenne arbeiten Tatsächlich mit C++.

Ich würde sagen es verhält sich hier wie mit jeder anderen Sprache: Es hält sich zum Teil aus Tradition. Die wenigsten Firmen wechseln sofort - oder wenn das Wissen fehlt auch garnicht.

Das ist so wie mit den C++ Feature ab dem C++ Standard: Ich kenne viele Firmen die bis heute nicht die STL einsetzen, und zwar nicht wegen Overhead etc (das ist im Embedded-Bereich ein Thema, die meisten Firmen mit denen ich Kontakt habe sind in anderen Branchen tätig), sondern aus reiner Unwissenheit und Sturheit der Alten.

Mich stört nicht das man nicht jeden Trend mitmacht, mich stört auch nicht das C existiert, obwohl ich persönlich dann schon C++ vorziehe - da soll jede Firma selbst entscheiden. Was mich in der Praxis aber wirklich stört ist, das die Älteren häufig sich gegen jegliche Neuerung querstellen, und damit auch jeden Fortschritt behindern. Nicht jede Neuerung ist gut, aber wenn es dazu führt das z.B. Firmen noch Entwicklungsumgebungen einsetzen deren Support schon Anno Dazumal eingestellt wurden ist, die alles Wissen das Neue mitbringen bereits im Keim ersticken (Nein, du machst das wie ich) - dann sollen sie sich nicht wundern wenn irgendwann ihr ach so tolles (und kaum wartbares) Stück Software nicht mehr auf neuen Betriebssystemen läuft, und die Kunden abspringen.

cu André

[asc]

Shade Of Mine schrieb:

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?
bei anfängern vielleicht, aber ich hab das eigentlich noch nie in einem produktiv code gesehen.

Mhh, also ich sehe häufig gar kein delete im Produktivcode mehr (Eher ein boost::scoped_ptr und ähnliches ;p). Okay, in der Regel nachdem ich an dem Code gearbeitet habe...

cu André

[~fricky]

Tachyon schrieb:

Ist klar, weil einem so wenig unsichere Konstrukte in C++ einfallen, muss eben delete herhalten.

wenn dir das thema nicht gefällt, können wir uns auch gern darüber unterhalten, warum man von stl-klassen zwar ableiten kann, aber es nicht sollte. oder wie man einer funktion ansieht, ob konstruktor-tauglich ist (weil sie exceptions wirft oder nicht). vielleicht wäre die frage, warum cout << x^1 + 1; nicht funzt, printf ("%d\n", x^1 + 1); aber schon, angenehmer für dich?

Shade Of Mine schrieb:

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?

er wird wahrscheinlich ähnlich häufig vorkommen, wie das vergessen von delete. ich glaube, noch nicht mal der compiler erkennt den fehler.

[Tachyon]

~fricky schrieb:

...

Ist klar, Du greifst Dir den Teil der offensichtlich pire Ironie war, und gehst auf die ernst gemeinten Aussagen nicht ein.

[u_ser-l]

namespace invader schrieb:

Irgendwie gibt es für alles besser geeignete Sprachen als C++

ich wäre spontan geneigt, zuzustimmen , allerdings bin ich der Meinung, daß für
resourcenkritische Projekte von nicht ganz trivialer Größenordnung, sagen wir mal, ab 10000-20000 Zeilen, C++ eine gute Wahl ist, vor allem, wenn wichtig ist, daß sich die Sprache nicht so schnell ändert, damit der Code auch noch in 10 Jahren ohne allzu viele Änderungen compiliert.

[~~fricky]

~fricky schrieb:

Tachyon schrieb:

Ist klar, weil einem so wenig unsichere Konstrukte in C++ einfallen, muss eben delete herhalten.

wenn dir das thema nicht gefällt, können wir uns auch gern darüber unterhalten, warum man von stl-klassen zwar ableiten kann, aber es nicht sollte. oder wie man einer funktion ansieht, ob konstruktor-tauglich ist (weil sie exceptions wirft oder nicht). vielleicht wäre die frage, warum cout << x^1 + 1; nicht funzt, printf ("%d\n", x^1 + 1); aber schon, angenehmer für dich?

Shade Of Mine schrieb:

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?

er wird wahrscheinlich ähnlich häufig vorkommen, wie das vergessen von delete. ich glaube, noch nicht mal der compiler erkennt den fehler.

Eigentlich gar nie, denn new normal muss man kein delete zum new dazu schreiben, da das ungefähr so aussieht:

if (blablubb) {
    boost::scoped_ptr< my_class >( new my_class );
}

Wohl gemerkt: eine Klasse sollte genau eine (wohl-)definierte Aufgabe übernehmen.
Sollte man innerhalb einer Klasse einmal unartig sein und einen nakten Zeiger auf ein Heap-Objekt verwalten, so ist es wirklich kein Akt ein delete in den Destruktor zu schreiben.
Es ist ungfähr so schwierig wie das Schuhe binden nach dem Schuhe anziehen.

[scherzkeks, ein]

~~fricky schrieb:

~fricky schrieb:

Tachyon schrieb:

Ist klar, weil einem so wenig unsichere Konstrukte in C++ einfallen, muss eben delete herhalten.

wenn dir das thema nicht gefällt, können wir uns auch gern darüber unterhalten, warum man von stl-klassen zwar ableiten kann, aber es nicht sollte. oder wie man einer funktion ansieht, ob konstruktor-tauglich ist (weil sie exceptions wirft oder nicht). vielleicht wäre die frage, warum cout << x^1 + 1; nicht funzt, printf ("%d\n", x^1 + 1); aber schon, angenehmer für dich?

Shade Of Mine schrieb:

~fricky schrieb:

dafür hätte man aber eine üble fehlerquelle ausgeschaltet, nämlich das vertauschen von delete[] mit delete.

ist das wirklich ein fehler der oft vorkommt?

er wird wahrscheinlich ähnlich häufig vorkommen, wie das vergessen von delete. ich glaube, noch nicht mal der compiler erkennt den fehler.

Eigentlich gar nie, denn new normal muss man kein delete zum new dazu schreiben, da das ungefähr so aussieht:

if (blablubb) {
    boost::scoped_ptr< my_class >( new my_class );
}

Wohl gemerkt: eine Klasse sollte genau eine (wohl-)definierte Aufgabe übernehmen.
Sollte man innerhalb einer Klasse einmal unartig sein und einen nakten Zeiger auf ein Heap-Objekt verwalten, so ist es wirklich kein Akt ein delete in den Destruktor zu schreiben.
Es ist ungfähr so schwierig wie das Schuhe binden nach dem Schuhe anziehen.

Hehe, ich schätze mal ~fricky läuft öfter mal mit roten Knien herum

[namespace invader]

~~fricky schrieb:

Sollte man innerhalb einer Klasse einmal unartig sein und einen nakten Zeiger auf ein Heap-Objekt verwalten, so ist es wirklich kein Akt ein delete in den Destruktor zu schreiben.
Es ist ungfähr so schwierig wie das Schuhe binden nach dem Schuhe anziehen.

Aber nicht den Kopierkonstruktor und den Zuweisungsoperator vergessen.

[audacia]

Shade Of Mine schrieb:

Ich kenne nur die closures in c++ und die haben eigentlich kein ref counting dabei...

Dafür aber manuelles Speichermanagement. Natürlich kann man sich das mit Smart-Pointern o.ä. vereinfachen - aber das ist auch wieder eine GC-Variante.

Oder falls du __closure in C++Builder meinst: das ist eine retrospektiv als unglücklich einzuschätzende Wortwahl, hat aber mit den anonymen Methoden von Delphi 2009, besser bekannt als Closures, nicht das Geringste zu tun.

Shade Of Mine schrieb:

Sicher, aber ich dachte dir geht es um default cctors...

Was auch immer. Das komplette "Jedes struct ist jetzt eine Klasse" inklusive aller Implikationen, eine davon z.B. Default-, Kopierkonstruktor und Zuweisungsoperator für alle Klassen, ist ein gewaltiger Designfehler - IMHO.

Shade Of Mine schrieb:

der artikel ist doof

Du bist unqualifiziert.

Shade Of Mine schrieb:

sag einfach was du daraus meinst. mag nicht den ganzen artikel zerpflücken müssen.

Brauchst du gar nicht. Er ist eigentlich, von der Einleitung abgesehen, recht fixiert auf das Thema, das ich ansprach. Wieso soll ich das jetzt nochmal erklären?

Shade Of Mine schrieb:

das ist eine zusatz information die delete nicht braucht -> du sparst performance

Abstrus.

Der tatsächliche Grund dürfte sein, daß new[] erst nach new eingeführt wurde und man vermutlich irgendein ABI nicht kaputtmachen wollte.

[namespace invader]

Tachyon schrieb:

Mir fallen da jede Menge Dinge in C ein, die unsicher sind. Das fängt schon beim printf/scanf an, geht über das gesamte Bastelei mit Strings und Arrays bis hin zu so tollen Sachen wie die wenigen Standardalgorithmen die absolut 0 Typsicherheit bieten.

Was haben diese Dinge dann in einer angeblichen High-Level-Sprache wie C++ zu suchen?

Man muss eben wissen, was man tut. Das gilt, wer hätte das gedacht, auch für C++, Ada und alle möglichen anderen Sprachen.

Eine vernünftige Sprache konzentriert sich auf bestimmte Konzepte und abstrahiert von den Details darunter. Wenn ich in C programmiere, brauche ich mich z.B. nicht darum zu kümmern, welche Register jetzt wohinaddiert werden.

In C braucht es Disziplin um was Ordentliches zu Stande zu bringen. In C++ muss man sich von alten Strukturen lösen und auf C++-Konstrukte umsatteln.

Man kann sich beim Umstieg von C auf C++ eben nicht von irgendwas lösen, denn die Low-Level-Probleme sind immernoch da. Man bekommt nur noch mehr Probleme dazu.

Dann ist C++ auch einfacher als C.

lol

[~fricky]

Tachyon schrieb:

~fricky schrieb:

...

Ist klar, Du greifst Dir den Teil der offensichtlich pure Ironie war, und gehst auf die ernst gemeinten Aussagen nicht ein.

ach so, du bist also selbst der meinung, dass c++ viele wacklige konstrukte hat. gut, dann hab' ich nichts gesagt.

[asc]

namespace invader schrieb:

Tachyon schrieb:

Mir fallen da jede Menge Dinge in C ein, die unsicher sind. Das fängt schon beim printf/scanf an, geht über das gesamte Bastelei mit Strings und Arrays bis hin zu so tollen Sachen wie die wenigen Standardalgorithmen die absolut 0 Typsicherheit bieten.

Was haben diese Dinge dann in einer angeblichen High-Level-Sprache wie C++ zu suchen?

Zu der Zeit wo C++ entwickelt wurden ist, war es ein Argument das die C-Bibliotheken auch unter C++ laufen. Aber: Nur weil etwas noch möglich ist, heißt das nicht, das man dies auch verwenden sollte (bzw. man sollte seinen Kopf vorher einschalten). Wobei dies für alle mir Bekannten Sprachen gilt: Man kann vieles falsch verwenden, ob nun in C++, Java, C# oder anderen Sprachen.

Es gibt genauso gründe für die Sprache C++ wie für fast alle anderen Sprachen, ansonsten schaut euch mal bitte Projekte an: Wenn C++ ach soooo schlecht ist, sagt mir mal warum es sich wie C noch immer hält?

C++ hat (wenn man nicht auf die C-Relikte zugreift) mehr Sicherheit als C - und viele (nicht alle) Probleme von C sind behoben (manches dadurch erkauft man durch eine größere Runtimeumgebung, anderes durch eine höhere Komplexität [Templateklassen] - wobei hier zwischen Verwenden und selbst programmieren noch gewaltige Unterschiede liegen).

Wie wäre es aber mal wieder zum Thema zurück zu kehren: Die Frage ist nicht ob C bzw. C++ schlecht ist (verwendet es nicht, wenn ihr es nicht wollt), sondern ob man erst C oder gleich C++ lernen soll. Und hierbei ist meine Meinung: Wenn jemand C++ lernen will, ist es unsinnig auch noch C vorher zu lernen, wenn er letzteres Tatsächlich braucht, kann er dies später immer noch aneignen.

cu André

[u_ser-l]

Man kann nicht C++ ohne C lernen, es sei denn, man will nur eine Teilsprache von C++ lernen.

Wer C++ lernt, lernt automatisch C mit. Schließlich ist erstere eine Spracherweiterung von letzterer.

[~fricky]

~~fricky schrieb:

Eigentlich gar nie, denn new normal muss man kein delete zum new dazu schreiben, da das ungefähr so aussieht:

if (blablubb) {
    boost::scoped_ptr< my_class >( new my_class );
}

^^ warum so eine abgefahrene zeile hinschreiben mit zwei mal 'my_class' darin? kannste nicht 'new' überladen, so dass es sich wie ein 'scoped-new' verhält?

asc schrieb:

Wenn C++ ach soooo schlecht ist, sagt mir mal warum es sich wie C noch immer hält?

es gibt viel suboptimales und veraltetes zeug, das sich hält und hält. es reicht meistens aus, dass es gerade so eben funktioniert.

[asc]

u_ser-l schrieb:

Man kann nicht C++ ohne C lernen, es sei denn, man will nur eine Teilsprache von C++ lernen.

Wer C++ lernt, lernt automatisch C mit. Schließlich ist erstere eine Spracherweiterung von letzterer.

Ich habe nie C gelernt, bin nur durch einige Chaosprojekte auf C gestossen. Die Aussage das man C++ nicht ohne C lernen kann muss also falsch sein. Die einzigen Bestandteile die ich von C nutze ist der Header cmath (for, while etc. sind auch C++, und nicht nur C).

Und C++ ist nicht eine Spracherweiterung von letzterer, sondern eine eigenständige Sprache die ihre Wurzeln zwar in C hat, aber nicht C ist. Zudem sind die Sprachparadigmen unterschiedlich. Selbst wenn ich unter C++ prozedural programmiere, programmiere ich dennoch anders als ich es unter C tuen würde (Alleine schon wegen Verwendung anderer Schlüsselwörter und Bibliotheksfunktionen die teilweise auf anderen Ansetzen basieren).

cu André

[asc]

~fricky schrieb:

^^ warum so eine abgefahrene zeile hinschreiben mit zwei mal 'my_class' darin? kannste nicht 'new' überladen, so dass es sich wie ein 'scoped-new' verhält?

Weil das Prinzip von C++ weiterhin bleibt, das man es sich aussuchen kann. Zudem wäre es Schwachsinn ein new so zu überladen das es sich wie ein "scoped-new" verhält, wenn man es an anderer Stelle auch mit einem shared_ptr etc. einsetzen will.

Flexibilität kostet manchmal etwas, die Mehrkosten in dem Fall sind aber wirklich nur für Schreibfaule relevant.

~fricky schrieb:

es gibt viel suboptimales und veraltetes zeug, das sich hält und hält. es reicht meistens aus, dass es gerade so eben funktioniert.

<ironie>Stimmt, genau darum werden auch neue Projekte noch in C++ (und auch C) begonnen.</ironie>

[~fricky]

asc schrieb:

[
Ich habe nie C gelernt, bin nur durch einige Chaosprojekte auf C gestossen.

soso, C code ist also per default chaotische, ne? dabei hab' ich gestern erst irgendwo gelesen, dass sich der C++ user nicht für die C-wurzeln seiner lieblingssprache schämen sollte.