C notwendig für C++?

[Xin]

asc schrieb:

Jedes gute C++ Buch geht auf Zeiger ein, dazu muss man sich nicht mit C-Strings rumquälen. Ich finde diesen Weg auch gut, ein Anfänger lernt schrittweise besser, man sollte nicht alle Komplexität gleich an den Anfang stellen.

Damit "quäle" ich meine C-Schüler in der Hälfte der Zeit. Ich wüsste nichts, woran man besser lernen kann, mit Zeigern umzugehen, sämtliche sonstigen Konstrukte drumrumbauen kann und sich auch noch mit einem einfachen printf() zeigen zu lassen, ob das nun funktioniert hat.
Wer den C-String nicht beherschen kann, braucht in meinen Augen nicht mit OOP oder abstrakteren Konzepten anzufangen.

Die wichtigste Erkenntnis, die meine Schüler daraus mitnehmen ist: Zeiger sind nicht kompliziert, sondern primitiv. Und darauf kann man dann komplexere Ideen wie eigene Wrapper-Klassen oder shared_ptr aufbauen.
Jeder programmiert bei mir seine eigene String-Klasse... Substrings ausschneiden oder Strings einfügen... alles tolle algorithmische Übungen, um Programmieren zu lernen.

asc schrieb:

Nutzt ihr Geräte erst, nachdem ihr sie anfangs zerlegt habt? Man kann auch erst das "Nutzen" lernen, bevor man in die Details geht.

Ich mache auch Geräte-Tauchen. Die Geräte werden vor jedem Tauchgang unter Aufsicht des Partners zusammengebaut, getestet, dann zusätzlich vom Partner getestet und am Ende des Tauchgangs zerlegt und gereinigt. Das "Buddy-System" beim Tauchen nennt man in der Informatik "Pair-Programming". Habe ich schon mal gesehen, macht aber kaum einer.

Wenn unter Wasser etwas passiert, versteht man warum und wie man das Problem beseitigt. Und bei zwei ausgebildeten Tauchern, wissen beide, wer welche Aufgabe hat, um das Problem zu lösen. Dafür muss man die Details der eigenen Ausrüstung kennen und die des Tauch-Partners.

Es gibt eine Ausnahme: Schnuppertaucher. Da baue ich mein Zeug und das Gerät des Schnupperers zusammen und teste beide. Wenn da etwas passiert, muss ich reagieren. Passiert mir was, muss ich alleine klarkommen. Darum darf ich mit dem Schnupperer nicht tief tauchen und der Schnupperer ist immer in Griffreichweite.
Wenn ich etwas professionell lernen will, dann muss ich kapieren, was und warum ich etwas tue. Das nicht zu wissen ist beim Tauchen potentiell gesundheitsgefährdend. Es ist legal ohne Tauchlehrer und Tauchschein (genauer gesagt ohne Ahnung) mit einer irgendwie zusammengebauten Ausrüstung ins Wasser zu steigen und zu tauchen. Aber das dann wirklich sehr gefährlich, bis hin zu tödlich und dafür muss nichtmals die Ausrüstung versagen.
Und so ist es in der Programmierung nunmal auch.
Wer sein Programm nicht zerlegen und testen kann, kann nicht sicherstellen, dass es im Einsatz nicht versagt. Darum wissen diejenigen, denen ich C/C++ beibringe, was ein C-String ist.
Nun bleibt die Frage, was der Threadstarter werden will: Programmierer oder Schnupperprogrammierer, wo ein richtiger Programmierer immer in Reichweite sein muss?

Wenn er nur mal zum Spaß reinschaut, spricht nichts gegen std::string. Wenn er es ernst meint, zum Einstieg eine ganze Menge.

asc schrieb:

Xin schrieb:

Ohne die Grundlagen von C++, die nunmal C komplett ausmachen...

Dem widerspreche ich schon.

Und ich lasse mich nicht auf einen Flamewar ein, weil er weder Dir noch mir, noch dem Threadstarter etwas bringt und in diesem Forum schon tausendmal geführt wurde. Es interessiert einfach nicht, weil ich recht habe und Du auch. Man braucht nicht alles, um gutes C++ zu schreiben. Es schadet aber nicht, sich auch in C umzusehen - im Gegenteil.
Wenn wir beide Recht haben - wozu diskutieren?

[asc]

Xin schrieb:

Man braucht nicht alles, um gutes C++ zu schreiben. Es schadet aber nicht, sich auch in C umzusehen - im Gegenteil.
Wenn wir beide Recht haben - wozu diskutieren?

Weil eben das "Es schadet aber nicht, sich auch in C umzusehen - im Gegenteil" in allen Projekten in denen ich mitgearbeitet habe, und ehemalige C-Programmierer waren, nicht stimmte. Wobei ich auch keine Systemprogrammierung mache - dort mag es wirklich sinnvoll sein C gut zu beherrschen.

[Xin]

asc schrieb:

Xin schrieb:

Man braucht nicht alles, um gutes C++ zu schreiben. Es schadet aber nicht, sich auch in C umzusehen - im Gegenteil.
Wenn wir beide Recht haben - wozu diskutieren?

Weil eben das "Es schadet aber nicht, sich auch in C umzusehen - im Gegenteil" in allen Projekten in denen ich mitgearbeitet habe, und ehemalige C-Programmierer waren, nicht stimmte.

Lies nochmal mein erstes Posting: Wer heute C lernt, lernt heute C und nicht vor 20 Jahren. Ich habe vor ... 20 Jahren C programmiert und als ich meine Software auf C++ hievte, lies sich das zu mindestens 95% automatisiert über einen Makro-Editor bewerkstelligen, weil ich offenbar C++ ähnliches C programmiert habe. Ich habe mein erstes C++-Buch wie eine Offenbarung gelesen, weil C++ genau die Sprache war, in der ich meine Software organisierte - nur dass ich eben in C programmierte.

Wenn Deine Kollegen sich 20 Jahre nicht weiterentwickelt haben, dann ist das kein C-Problem, sondern ein Problem Deiner Kollegen, das Dir heute genauso gut im Java- oder C#-Umfeld genauso passieren kann. Meine Kollegen programmieren noch Fortran und manche switchen zwischen Fortran und C, andere zwischen Fortran und C#, während unser Team mit C++ arbeitet.
Veraltete C-Programmierung kann also auch die gute Nachricht sein.

Ich habe kein Problem C-Funktionen in C++ zu nutzen. Sie sind in C++ verfügbar, dokumentiert - auch wenn manche es als Frevel betrachten. Und genau darüber mag ich nicht diskutieren, ob das jetzt Frevel ist oder nicht. Wenn es das Problem sauber gelöst ist, dann darf man darüber diskutieren, ob es bessere Alternativen gibt, aber nicht, ob das jetzt C++ ist nicht. Auch das ist C++.
Wenn ein C++-Programmierer aber von Frevel spricht, weil er C++ nicht versteht, weil er die in C++ vorhandenen Funktionen ungern benutzt, dann ist das kein C-Problem. Dann hätte es vielleicht nicht geschadet, sich auch in dem Bereich ein wenig umzuschauen. Meiner Meinung nach.
Der Threadstarter kann tun und lassen, was er will. Ich werde mich mit niemandem fetzen, wer der TS macht Fortschritte, egal ob er mit einem modernen C- oder C++-Buch anfängt. Und ob er sich danach nicht mehr weiterentwickelt, spielt in 20 Jahren auch keine Rolle mehr. Wenn er dann noch C++11 programmiert, wo C++34 aktuell ist - da wird genauso drüber geschimpft, wie heute über die C-Entwickler von vor 20 Jahren.
So what?

[großbuchstaben]

asc schrieb:

Eine Schnittmenge von Sprachelementen sagt nicht, das man beide Sprachen lernen muss, oder das eine Sprache eine andere ist.

es ist nicht möglich, C++ zu lernen und C dabei ganz wegzulassen. Wer C++ lernt, lernt automatisch einen beträchtlichen Teil von C mit, ob sie will oder nicht.

Ich würde zustimmen, wenn jemand sagen würde, daß es besser sei, C++ zu lernen ohne vorher C gelernt (und praktiziert) zu haben.

[Auskenner]

Jockelx schrieb:

Wenn mit der Frage gemeint ist, ob man pures C beherrschen muss, um C++ zu können, dann von mir ein klares nein!

Wenn du wissen willst, wie die Objekte in C++ oder das sonstige High Level Zeugs unter der Haube realisiert ist, dann ist es schon sinnvoll, wenn man weiß, wie so etwas in C realisiert werden würde.
Am Ende lernst du dadurch zu verstehen, wo und wie du optimieren musst um den Code performant zu halten. Jemand der nur das Highlevel Zeugs nutzt und nicht versteht, wie dieses unter der Haube realisiert wurde, der kann nicht optimieren. D.h. er wählt unter umständen die Highlevel Features, die für diese Aufgabe nicht geeignet oder nicht die besten sind und verschwendet somit Rechenleistung.

Ich könnte zumindest kein fehlerfreies C-Programm ohne Kompiler-Check schreiben (schon allein, weil ich mit Sicherheit nicht daran denken würde, Variablen am Funktionsanfang zu deklarieren).

1. Dann würdest du in einer Prüfung in einem Informatikstudium durchfallen, da hast du nämlich nur Stift und Papier und musst das drauf haben.

2. Seit C99 ist es erlaubt, Variablen auch später zu deklarieren. Dennoch würde ich davon abraten, da es schlechter Programmierstil ist.
Bei der For Schleife mal ausgenommen, das wäre also okay:

for (int i = 0; i <= 10; i++){
  ...
}

[Auskenner]

Dobi schrieb:

C sind Grundlagen schrieb:

Wie will man eine Liste verstehen, wenn man nicht einmal weiß, wie man es in C mit Zeigern realisieren würde?

Wie will man Zeiger in C verstehen wenn man das sowas nie in Assembler geschrieben hat? Wie will man Assembler verstehen wenn man nie eine CPU designed hat? ... Wie will man Strom verstehen wenn man nie ...

Der Vergleich hinkt gewaltig.

Das HighLevel Zeugs von C++ ist so stark abstrahiert, dass der sichtbare Code Meilenweit vom Assemblercode entfernt ist, den der Compiler daraus machen würde.
Bei C bist du mit Zeigern näher an Assembler als bei C++ mit Objekten.

Man setzt halt auf irgendeiner Abstraktionsebene an. Es ist manchmal gut wenn man auch die tieferliegenden kennt, aber nicht immer nötig. Das ist ja grad das tolle an Abstraktion solange sie nicht leaky ist.

Meiner Meinung nach kann der, der sowieso nicht tiefer unter die Haube nachsehen will auch gleich bei Java oder C# bleiben.

Du mußt das Zeugs unter der Haube verstehen, um den Sprachumfang von C++ optimal einsetzten zu können.
Deswegen ist das wichtig.

[Auskenner]

asc schrieb:

Nutzt ihr Geräte erst, nachdem ihr sie anfangs zerlegt habt? Man kann auch erst das "Nutzen" lernen, bevor man in die Details geht.

Der Vergleich hinkt.

Mein Staubsauger funktioniert nämlich auch nicht performanter, wenn ich weiß, wie der unter der Haube arbeitet.
Bei C++ Code ist das aber anders.

Xin schrieb:

Ohne die Grundlagen von C++, die nunmal C komplett ausmachen...

Dem widerspreche ich schon. Die Grundlagen die man für die sinnvolle C++ Programmierung benötigt, machen C eben nicht komplett aus. Man benötigt nicht Alles was die Sprache C anbietet um gutes C++ zu schreiben.

performanter C++ Code != guter C++ Code

Du kannst in C++ den saubersten, d.h. übersichtlichsten und wartbarsten Code unter Verwendung aller HighLevel Features und API Funktionen der STL schreiben, aber das ist dann nicht unbedingt performant.

Deswegen bleibe ich bei der Aussage, wem es nur um übersichtlichen wartbaren Code geht, der ist höchstwahrscheinlich sogar mit C# oder Java besser bedient.

[Jockelx]

Auskenner schrieb:

Jockelx schrieb:

Wenn mit der Frage gemeint ist, ob man pures C beherrschen muss, um C++ zu können, dann von mir ein klares nein!

Wenn du wissen willst, wie die Objekte in C++ oder das sonstige High Level Zeugs unter der Haube realisiert ist, dann ist es schon sinnvoll, wenn man weiß, wie so etwas in C realisiert werden würde.

Ja, die Diskussion ist irgendwie doof, weil die Frage auch nicht ganz klar ist.
Ich finde auch, dass man C-Anteil können sollte.
Mit 'purem C' können meinte ich so Sachen, wie das mit der Variablendeklaration.
Wusste ich nicht, dass das in C doch auch später geht, aber dieses fehlende Wissen interessiert mich als C++ler auch kein Stück und läßt meine C++-Programme auch kein Stück schlechter werden.

[asc]

Auskenner schrieb:

Xin schrieb:

Ohne die Grundlagen von C++, die nunmal C komplett ausmachen...

Dem widerspreche ich schon. Die Grundlagen die man für die sinnvolle C++ Programmierung benötigt, machen C eben nicht komplett aus. Man benötigt nicht Alles was die Sprache C anbietet um gutes C++ zu schreiben.

performanter C++ Code != guter C++ Code

1. Man muss für C++ keine speziellen C-Kenntnisse besitzen um Performanten Code zu schreiben. Man kann in C++ auch ohne rein in C übliche Konstrukte durchaus schnellen Code schreiben - mag nicht ganz an C heranreichen (wobei dies Fallabhängig durchaus möglich ist), aber "C" seperat muss man dafür nicht lernen.

Ihr tut so als würden interna in C++ Büchern etc. gänzlich ausgespart. Und das ist falsch. Und ebenso ist C++ nicht per se langsamer als C, sofern man die Fallstricke berücksichtigt (und auch die werden nicht selten in Büchern angesprochen).

2. Gut und Wartbar steht zwar in teilen der Performance entgegen, aber beileibe nicht immer. Zum anderen meint ihr scheinbar das C-Kenntnisse einen automatisch zu performanteren Code führen. Auch das ist aus Praxiserfahrungen nonsense.

Spätestens wenn man mit "5 Sterne"-Programmierern gearbeitet hat, weiß man, wovon ich spreche.

Zum anderen:
Performance ist sicherlich nicht unwichtig, ein wesentlich wichtigeres Kriterium für eine Software ist aber in der Regel das diese sauber läuft. Man sollte guten und wartbaren Code schreiben, und anschließend prüfen ob und wo zu Optimieren ist. Das heißt nicht das man vorträglich bewusst inperformanten Code schreiben soll, aber das man die Aspekte der Wartbarkeit in Vordergrund stellt. Dies gilt ins besondere, wenn die Software auch lange eingesetzt und weiter entwickelt werden soll (was in meinem Fall zumeist zutrifft, ich bin üblicherweise in der langjährigen Produkt(weiter)entwicklung, nicht der schnelllebigen Projektentwicklung tätig.

[asc]

Jockelx schrieb:

Ich finde auch, dass man C-Anteil können sollte.

Was aber auch in der notwendigen Schnittmenge in der Regel in jeden C++ Buch enthalten ist. Das ist der Grund warum ich ein seperates erlernen von C auch völlig unsinnig ansehe.

[TyRoXx]

Auskenner schrieb:

performanter C++ Code != guter C++ Code

Du kannst in C++ den saubersten, d.h. übersichtlichsten und wartbarsten Code unter Verwendung aller HighLevel Features und API Funktionen der STL schreiben, aber das ist dann nicht unbedingt performant.

Nein? Warum denn nicht? Einfach nur so, weil es kein C ist? Aha, interessant.

[ödlfjasödf]

DerNewb schrieb:

Nun hab ich irgendwie das blöde Gefühl, dass ich C erstmal lernen sollte, weil ich in einem Begleitheft zu einem Kurs gelesen habe, dass die Kenntnisse über C vorausgesetzt waren für die Kurse. Nun ... was ist denn jetzt?

Man kann nicht C++ lernen, ohne auch ein Stückweit C zu lernen, da beide, das wurde ja schon oft in diesem Thread erwähnt, ein gemeinsame Schnittmenge besitzen.

Entscheidend ist aber, daß der Teil der gemeinsamen Schnittmenge in C++, der gemeinhin als C bezeichnet, formal als C++ definiert ist.

Und damit kann man auch Klassen oder Container selber bauen.

Man braucht also C nicht.

[Auskenner]

TyRoXx schrieb:

Auskenner schrieb:

performanter C++ Code != guter C++ Code

Du kannst in C++ den saubersten, d.h. übersichtlichsten und wartbarsten Code unter Verwendung aller HighLevel Features und API Funktionen der STL schreiben, aber das ist dann nicht unbedingt performant.

Nein? Warum denn nicht? Einfach nur so, weil es kein C ist? Aha, interessant.

Ich vergesse hier immer, dass nicht jeder in diesem Forum intelligent ist.

[Xin]

Auskenner schrieb:

Ich vergesse hier immer, dass nicht jeder in diesem Forum intelligent ist.

Grundsätzlich würde mich noch interessieren, wie sich DerNewb nun entschieden hat, aber da er sich an diesem Thread nicht mehr beteiligt war er offenbar intelligent genug.

[floomi]

TyRoXx schrieb:

Auskenner schrieb:

performanter C++ Code != guter C++ Code

Du kannst in C++ den saubersten, d.h. übersichtlichsten und wartbarsten Code unter Verwendung aller HighLevel Features und API Funktionen der STL schreiben, aber das ist dann nicht unbedingt performant.

Nein? Warum denn nicht? Einfach nur so, weil es kein C ist? Aha, interessant.

Weil Wartbarkeit/Lesbarkeit gute Performance nicht automatisch impliziert - und vice versa. Egal in welcher Sprache.

[TyRoXx]

asc schrieb:

Man kann in C++ auch ohne rein in C übliche Konstrukte durchaus schnellen Code schreiben - mag nicht ganz an C heranreichen (wobei dies Fallabhängig durchaus möglich ist)

Welche in C üblichen Konstrukte wären das denn?

asc schrieb:

Und ebenso ist C++ nicht per se langsamer als C, sofern man die Fallstricke berücksichtigt (und auch die werden nicht selten in Büchern angesprochen).

Und die wären?

Das Thema könnte auch heißen "Plattdeutsch notwendig für Hochdeutsch?".

Auskenner schrieb:

Das HighLevel Zeugs von C++ ist so stark abstrahiert, dass der sichtbare Code Meilenweit vom Assemblercode entfernt ist, den der Compiler daraus machen würde.

Was denn für "High Level Zeugs"?

Auskenner schrieb:

Bei C bist du mit Zeigern näher an Assembler als bei C++ mit Objekten.

Und nachts ist es kälter als draußen.

Auskenner schrieb:

Du mußt das Zeugs unter der Haube verstehen, um den Sprachumfang von C++ optimal einsetzten zu können.
Deswegen ist das wichtig.

Das Zeugs unter der Haube von C++ ist jedenfalls nicht C.

[fallschritt]

TyRoXx schrieb:

asc schrieb:

Man kann in C++ auch ohne rein in C übliche Konstrukte durchaus schnellen Code schreiben - mag nicht ganz an C heranreichen (wobei dies Fallabhängig durchaus möglich ist)

Welche in C üblichen Konstrukte wären das denn?

nothrow, reinterpret_cast, for-Loops, if/else, realloc, memcpy, keine Abstraktionen, also Zeiger, etc.

Das Problem mit den Abstraktionen ist, dass man es nicht fine-tunen kann. Reihenfolge von zwei Destruktoraufrufen umkehren? SSO von std::string abschalten? Nope. Also alle Abstraktionen entfernen und alles eine Stufe low-leveliger schreiben. Aka C.

TyRoXx schrieb:

asc schrieb:

Und ebenso ist C++ nicht per se langsamer als C, sofern man die Fallstricke berücksichtigt (und auch die werden nicht selten in Büchern angesprochen).

Und die wären?

Call by reference vs call by value. Unnötige Kopien vs Aliasing-Probleme. Nur mal um ein Fallstrick zu nennen, C++ ist voll davon.

TyRoXx schrieb:

Auskenner schrieb:

Das HighLevel Zeugs von C++ ist so stark abstrahiert, dass der sichtbare Code Meilenweit vom Assemblercode entfernt ist, den der Compiler daraus machen würde.

Was denn für "High Level Zeugs"?

virtual, Exceptions, Abstraktion in Bibliotheken (z.Bsp. std::string: Ist für den allgemeinen Fall optimiert, d.h. er ist in keinem Einsatzszenario ideal).

TyRoXx schrieb:

Auskenner schrieb:

Du mußt das Zeugs unter der Haube verstehen, um den Sprachumfang von C++ optimal einsetzten zu können.
Deswegen ist das wichtig.

Das Zeugs unter der Haube von C++ ist jedenfalls nicht C.

Der erste Schritt, C++ zu verstehen, ist, die einzelnen Sprachfeatures in C zu implementieren.

[TyRoXx]

fallschritt schrieb:

TyRoXx schrieb:

asc schrieb:

Man kann in C++ auch ohne rein in C übliche Konstrukte durchaus schnellen Code schreiben - mag nicht ganz an C heranreichen (wobei dies Fallabhängig durchaus möglich ist)

Welche in C üblichen Konstrukte wären das denn?

nothrow, reinterpret_cast, for-Loops, if/else, realloc, memcpy, keine Abstraktionen, also Zeiger, etc.

noexcept gibt es in C++. Man kann also durchaus gezielt Exceptions deaktiveren.
reinterpret_cast ist kein C-Feature.
for , if , else benutzt man in C++ auch.
std::vector darf realloc gerne für PODs benutzen.
memcpy benutzt man in C++ auch. Heißt aber std::copy .
Abstraktionen nimmt man in C fast genau so wie in C++ vor. Es steht bloß weniger Syntactic Sugar zur Verfügung. Hast du jemals gutes C gesehen?
Zeiger benutzt man in C++ auch ständig in verschiedenen Varianten.

fallschritt schrieb:

Das Problem mit den Abstraktionen ist, dass man es nicht fine-tunen kann.
Reihenfolge von zwei Destruktoraufrufen umkehren?

Kann man mit optional machen oder durch swap mit einem Temporary.

fallschritt schrieb:

SSO von std::string abschalten? Nope.

std::vector ? Wenn du es unbedingt brauchst, kannst du auch deinen eigenen String schreiben, der dieselbe Schnittstelle wie std::string implementiert. Kein Problem und völlig normal in C++. Außerdem hat C gar keinen String-Typ, also was hat das mit C zu tun?

fallschritt schrieb:

Also alle Abstraktionen entfernen und alles eine Stufe low-leveliger schreiben. Aka C.

Das nennt man "schlechtes C". In dieser sehr beliebten Programmiersprache ist zum Beispiel OpenSSL geschrieben. Hat super funktioniert.

fallschritt schrieb:

Call by reference vs call by value.

Gibt es in C auch. In C++ ist das überhaupt kein Problem durch die Referenzen.

fallschritt schrieb:

Unnötige Kopien vs Aliasing-Probleme. Nur mal um ein Fallstrick zu nennen, C++ ist voll davon.

Anscheinend so voll, dass du nur insgesamt zwei aufzählen kannst.

fallschritt schrieb:

TyRoXx schrieb:

Auskenner schrieb:

Das HighLevel Zeugs von C++ ist so stark abstrahiert, dass der sichtbare Code Meilenweit vom Assemblercode entfernt ist, den der Compiler daraus machen würde.

Was denn für "High Level Zeugs"?

virtual, Exceptions, Abstraktion in Bibliotheken (z.Bsp. std::string: Ist für den allgemeinen Fall optimiert, d.h. er ist in keinem Einsatzszenario ideal).

virtual baut man in C ständig so nach, dass exakt der gleiche Code generiert wird. Siehe gutes C.
Exceptions baut man in C ständig mit if nach.
Ich wusste auch noch gar nicht, dass der String aus der C-Standardbibliothek für jedes Szenario optimiert ist. Kann auch daran liegen, dass der nicht existiert.

fallschritt schrieb:

Der erste Schritt, C++ zu verstehen, ist, die einzelnen Sprachfeatures in C zu implementieren.

Was genau hat man davon das Nachbauen in C zu machen, wenn man eigentlich C++ lernen möchte? Nach der Logik müsste man C++ eigentlich in BCPL nachbauen. Oder habe ich verpasst, dass aktuelle Prozessoren jetzt direkt C ausführen?

[Ethon]

std::vector darf realloc gerne für PODs benutzen.

Nö. std::vector muss seinen allocator verwenden und der hat in seinem Interface kein realloc.

[TyRoXx]

Ethon schrieb:

std::vector darf realloc gerne für PODs benutzen.

Nö. std::vector muss seinen allocator verwenden und der hat in seinem Interface kein realloc.

Es ist bestimmt standardkonform den vector für nicht-spezialisierte std::allocator<POD> zu spezialisieren und den Allocator dann zu ignorieren. Oder nicht?