Bei C++ Grundlagenkenntnisse in C überflüssig?
-
dot schrieb:
Ich weiß nicht, aber ich find eigentlich überhaupt nicht, dass die die Konzepte und Denkweisen derer man sich beim Coden in C so bedient, in irgendeiner Form stark von denen, die man in C++ anwenden würde, unterscheiden. C++ bietet eben noch ein paar Paradigmen mehr, aber rein grundsätzlich find ich, dass man C, was das angeht, auf jeden Fall als Untermenge von C++ betrachten kann. Zumindest meinen bescheidenen Erfahrungen mit C nach...
Der Unterschied ist, dass sowas hier in der Regeln in C++ schön weggekapselt
wird.Ein Beispiel ist eine dreidimensionale Matrix aus void-Pointern, die zusammengebaut, kreuzverlötet und mit Funktionspointern verschiedenster Typen belegt wird.
Wenn man diesen Low-Level-Kram nicht gewöhnt ist, tut man sich halt deutlich
schwerer. Da braucht man dann schon nen Drei-Sterne-Programmierer für.Ich würd sagen, in puncto Wartbarkeit schlägt da idiomatisches C++ C eh um Längen. Mir geht es da wie pumuckl und das ist gar nicht so schlecht. Hält mich davon ab, so Monster überhaupt zu bauen.
-
dot schrieb:
Ich weiß nicht, aber ich find eigentlich überhaupt nicht, dass die die Konzepte und Denkweisen derer man sich beim Coden in C so bedient, in irgendeiner Form stark von denen, die man in C++ anwenden würde, unterscheiden. C++ bietet eben noch ein paar Paradigmen mehr, aber rein grundsätzlich find ich, dass man C, was das angeht, auf jeden Fall als Untermenge von C++ betrachten kann. Zumindest meinen bescheidenen Erfahrungen mit C nach...
Das Ding dabei ist, dass einige der C-Paradigmen in 98% der Fälle durch andere C++-Paradigmen ersetzt werden. Erst wenn man auf einen Fall für die restlichen 2% stößt, muss man sich mit dem C-Paradigma auseinandersetzen, das dann eben sehr ungewohnt daher kommt und die Frage hier im Forum triggert. Als Beispiel nenn ich mal Ellipse und die va_args Makro-Familie. In C wird man vielleicht hin und wieder damit konfrontriert, dass man eine variadische Funktion bastelt, in C++ eben nicht, weil sie nur für PODs benutzbar sind. Stattdessen greift man in C++ lieber auf irgendeine Art des Operator-Chainings oder ähnliches zurück.
-
Viele schöne Anworten auf eine etwas provokativ gestellte Frage.
Hatte ich mir gedacht: eine höhere Komplexität einer Programmiersprache bringt für Anfänger leider auch keinen leichteren Einstieg in die Programmierung. Ist in C++ alles schön weggekapselt, was man in C einst notwendig lernen, verstehen, und anwenden musste.Vielleicht hatten die 'Alten Säcke der Programmierung aus der Steinzeit' doch manches einfacher? Der Einstieg war zugegeben hart. Wenn man ihn geschafft hatte, war man aber weitgehend sicher und wusste besser was man überhaupt tut. Gab es etwas neues wie C++ hat man sich das angesehen und übernommen.
-
berniebutt schrieb:
Vielleicht hatten die 'Alten Säcke der Programmierung aus der Steinzeit' doch manches einfacher? Der Einstieg war zugegeben hart. Wenn man ihn geschafft hatte, war man aber weitgehend sicher und wusste besser was man überhaupt tut.
Einfacher? Nicht wirklich. Wie du schreibst war der Einstieg hart, weil man sich mit Low-Level-Details herumschlagen musste. Klar wusste man danach besser was man auf dem Level tat. Dafür waren Probleme auf höherem Level häufig nur schwer bis garnicht abstrahierbar, man musste für sowas also entweder das Rad jedesmal neu erfinden oder sich ein sehr abstraktes, dafür aber nur schwer lesbares und kaum wartbares void-Pointer-Frickel-Rad bauen.
Man überlege sich, was beispielsweise Templates zu leisten vermögen. Eine kleine Änderung, und der Compiler kann völlig anderen Code generieren. Dass dafür die Low-Level Fähigkeiten nicht so ausgeprägt sind, weil die einem in den meisten Fällen vom Compiler und/oder den Bibliotheken ersetzt werden, ist der Preis, den man dafür zahlt.
[quote]Gab es etwas neues wie C++ hat man sich das angesehen und übernommen./quote] Wers nur "angesehn und übernommen" hat, statt es sich als eigenständige Sprache von Grund auf neu anzueignen, der schreibt auch entsprechenden Code - C mit Beiwerk, ohne sich der wirklichen Stärken von C++ voll bewusst zu sein.
Es gibt verschiedene Sprachen für verschiedene Abstraktionslevel. Verschiedene Probleme benötigen entsprechend verschiedene Level, deshalb haben alle Sprachen ihre Daseinsberechtigung. C++ ist eine Sprache mit hohem Abstraktionslevel, die nativ auf eine Sprache mit niedrigerem Abstraktionslevel zurückgreifen kann.
Das ist sowohl eine Stärke der Sprache, weils eben alles in Einem bietet, aber auch eine Schwäche, weils die Wahl der Sprachmittel erschwert und grade bei Umsteigern zu einer wilden und unnötigen Mischung zwischen Low-level und High-level Code führt: (Oder erfahrungsgemäß Low-Level und Medium-Low-Level)
-
berniebutt schrieb:
Ist in C++ alles schön weggekapselt, was man in C einst notwendig lernen, verstehen, und anwenden musste.
Lustigerweise war das bei mir genau anders herum. Ich habe erst C und dann C++ gelernt, weil C++ mir anfangs zu kompliziert erschien. Das fing schon damit an, dass mich
cout << "Hallo, Welt!";tierisch aufgeregt hat, weil ich nie verstanden habe, was dieses komische << soll, warum das nur bei cout und cin auftaucht und wie man das sonst noch anwenden kann. Ich hatte irgendwie immer das Gefühl, etwas verpasst zu haben. Da mich die Funktionsweise von Computern und der ganze Low-Level Kram dann eh noch interessiert haben, habe ich halt mit C begonnen. Bereut habe ich das eigentlich nie, obwohl ich zugegebenermaßen mittlerweile C++ bevorzuge, wenn ich die Wahl habe.
-
cooky451 schrieb:
weil C++ mir anfangs zu kompliziert erschien.
Ist es nur, wenn man gleich von Anfang an mit allen Features auf einmal konfrontiert wird und ohne Struktur und roten Faden allein gelassen wird. Der Sprachumfang macht eine strukturierte Schritt-für-Schritt-Einführung notwendig, die nur wenige Bücher bieten.
Wenn man dich vor ein Gerät mit 50 verschiedenen Knöpfen stellt und nur sagt "mach mal" bist du auch verloren. Wenn man es dir erklärt und zu Beginn erstmal mit zwei oder drei Schaltern anfängt, weil man den Rest für die ersten Schritte noch nicht braucht, dann kann man das schrittweise erweitern.weil ich nie verstanden habe, was dieses komische << soll, warum das nur bei cout und cin auftaucht und wie man das sonst noch anwenden kann. Ich hatte irgendwie immer das Gefühl, etwas verpasst zu haben.
Das was du vermutlich verpasst hast war dann wohl das erste oder zweite Kapitel, in dem die wichtigsten Grundzüge von Ein/Ausgabeströmen in C++ erklärt wurden
-
pumuckl schrieb:
Das was du vermutlich verpasst hast war dann wohl das erste oder zweite Kapitel, in dem die wichtigsten Grundzüge von Ein/Ausgabeströmen in C++ erklärt wurden
Ich weiß es nicht mehr ganz genau (mein einziges C/C++ Buch (Ja, C/C++
) ist nicht so toll), allerdings hätte man mir vermutlich ganz am Anfang Operatorüberladungen erklären müssen. Das ist aber wohl eine Eigenart von mir, ich hasse es einfach Dinge zu benutzen, die ich nicht zumindest im Ansatz durchblickt habe. Lustigerweise ist mir, soweit ich mich erinnern kann, die variable Parameterzahl von printf() erst so spät aufgefallen, dass ich dieses Mysterium nachschlagen konnte. Da hatte ich noch mal Glück, nachher hätte ich noch Pascal gelernt.
-
berniebutt schrieb:
Ein Bespiel wäre Pointer bei einem Character-String und ähnliches für C banales.
Deine Kenntnisse der C-Banalitäten haben interessanterweise dazu geführt, daß Du bei einem 200-Zeilen Programm 2 banale
Semikolons vergessen hattest. Der Source-Code war von Dir online gestellt verbunden mit dem Hinweis,daß das Programm nicht funktioniere (Algorithmus zum Berechnen von Schaltjahren war nach eigenen Angaben auch nicht richtig.) und konstruktive Kritik willkommen sei. Soviel mal zum Thema banale Fragen.berniebutt schrieb:
Braucht man C nicht mehr und warum fragen Einsteiger in C++ so oft 'wie soll ich dies oder jenes machen?' Es sollte mit der Denkweise von C++ doch alles viel einfacher zu lernen und anzuwenden sein!
Hm, da C++ und C gemeinsame Grundlagen haben, dürfte es unmöglich sein , C++ zu lernen, ohne auch C zu lernen.
Es gibt mit Sicherheit viele Sachen, wo C-Kenntnisse zu einem besseren Verständnis der Materie führen. So z.B. bei einem "vector", der ja, wenn ich das richtig verstanden habe, vom Kern her nichts anderes ist als eine verkettete Liste auf der Basis eines C-Arrays, die man mit C-Grundkenntnissen auch selber programmieren könnte.
Geht man diesen Gedankengang weiter, könnte man auf die Idee kommen, warum eigentlich nicht erstmal Assembler lernen, bevor man C lernt. Das Verständnis z.B. eines Arrays ist mit Sicherheit besser, wenn man das erstmal in Assembler programmiert hat. Nicht zu vergessen die detaillierte Funktionsweise der Hardware.
Was also soll der Maßstab sein, um mit C oder C++ zu beginnen?
-
redrew99 schrieb:
So z.B. bei einem "vector", der ja, wenn ich das richtig verstanden habe, vom Kern her nichts anderes ist als eine verkettete Liste auf der Basis eines C-Arrays, die man mit C-Grundkenntnissen auch selber programmieren kann.
Das Argument hat mich vollends überzeugt.
-
redrew99 schrieb:
So z.B. bei einem "vector", der ja, wenn ich das richtig verstanden habe, vom Kern her nichts anderes ist als eine verkettete Liste auf der Basis eines C-Arrays, die man mit C-Grundkenntnissen auch selber programmieren könnte.
vector ist ein Wrapper um einen dynamisch allozierten T[] und sonst nichts
-
Das stimmt natürlich, aber entscheidend in Bezug auf das Thema ist doch, daß man einen Container, der die Funktionalität eines Vektors besitzen soll, auch mit C programmieren könnte.
Hat man ja wohl früher auch, als es die STL noch nicht gab.
-
redrew99 schrieb:
Das stimmt natürlich, aber entscheidend in Bezug auf das Thema ist doch, daß man einen Container, der die Funktionalität eines Vektors besitzen soll, auch mit C programmieren könnte.
Du kannst jeden Container mit C nachbauen, nur halt nicht so hübsch mit Templates, Kapselung und Operatorüberladungen.
-
redrew99 schrieb:
Hm, da C++ und C gemeinsame Grundlagen haben, dürfte es unmöglich sein , C++ zu lernen, ohne auch C zu lernen.
Ich habe das unmögliche geschafft. Ich habe C++ gelernt ohne C zu lernen. Und das haben hier wohl auch andere geschafft
redrew99 schrieb:
Es gibt mit Sicherheit viele Sachen, wo C-Kenntnisse zu einem besseren Verständnis der Materie führen. So z.B. bei einem "vector", der ja, wenn ich das richtig verstanden habe, vom Kern her nichts anderes ist als eine verkettete Liste auf der Basis eines C-Arrays, die man mit C-Grundkenntnissen auch selber programmieren könnte.
Geht man diesen Gedankengang weiter, könnte man auf die Idee kommen, warum eigentlich nicht erstmal Assembler lernen, bevor man C lernt. Das Verständnis z.B. eines Arrays ist mit Sicherheit besser, wenn man das erstmal in Assembler programmiert hat. Nicht zu vergessen die detaillierte Funktionsweise der Hardware.
Was also soll der Maßstab sein, um mit C oder C++ zu beginnen?
Die Frage ist, braucht man diese Kenntnis überhaupt? Muss man dies wirklich wissen, um einen std::vector zu verwenden? Man kann nämlich auch in die andere Richtung gehen. Muss ein Java-Entwickler wirklich Assembler lernen, nur damit er Java versteht? Du kannst es auch weniger extrem haben, muss ein Java Entwickler Bytecode verstehen? Gleiches gilt auch für C# Entwickler, muss der CIL, C++, C oder Assembler können, um in C# programmieren zu können?
Sicherlich ist es interessant und zusätzliches Wissen schadet nie. Aber es ist nicht notwendig. Man kann die Sachen auch ohne die genaue Kenntnis benutzen. Es reichen oft auch schon abstrahierte Bilder. Die genauen Details muss man nicht kennen. Das ist ja eigentlich auch die Idee von Sprachen auf einem höherem Level. Man will den Low-Level Kram wegkapseln, so dass man von ihm keine Kenntnis mehr haben muss. Genau dies geschieht auch schon in C++.
Grüssli
-
falsches Forum
-
redrew99 schrieb:
Das stimmt natürlich, aber entscheidend in Bezug auf das Thema ist doch, daß man einen Container, der die Funktionalität eines Vektors besitzen soll, auch mit C programmieren könnte.
Hat man ja wohl früher auch, als es die STL noch nicht gab.Von der Funktionalität her. Der C-Vector kommt aber vom Bedienkomfort her bei weitem nicht an den C++-Vector heran. Für die automatischen Konstruktoren und Destruktoren gibt es in C keinen Ersatz und die Templates gehen nur mit Gefrickel.
-
redrew99 schrieb:
Hm, da C++ und C gemeinsame Grundlagen haben, dürfte es unmöglich sein , C++ zu lernen, ohne auch C zu lernen.
Nö, ich habe C++ ohne C gelernt. Wenn ich heute Hardcore-C-Code sehe, kratze ich mich am Kopf und denke mir "Zum Glück hast du das nicht lernen müssen!".
redrew99 schrieb:
Es gibt mit Sicherheit viele Sachen, wo C-Kenntnisse zu einem besseren Verständnis der Materie führen. So z.B. bei einem "vector", der ja, wenn ich das richtig verstanden habe, vom Kern her nichts anderes ist als eine verkettete Liste auf der Basis eines C-Arrays, die man mit C-Grundkenntnissen auch selber programmieren könnte.
Nein, denn anscheinend hat dich das nicht weit gebracht, C zu können. Denn Vector besteht nicht aus einer verketteten Liste. Und um vector zu implementieren, hilft einem C überhaupt nicht weiter, weil ich vector mit new[] und delete[] implementieren müsste, worauf ein C-Programmierer ohne C++-Wissen nicht kommen würde. Ich brauche dafür absolut kein C-Wissen.
redrew99 schrieb:
Geht man diesen Gedankengang weiter, könnte man auf die Idee kommen, warum eigentlich nicht erstmal Assembler lernen, bevor man C lernt. Das Verständnis z.B. eines Arrays ist mit Sicherheit besser, wenn man das erstmal in Assembler programmiert hat. Nicht zu vergessen die detaillierte Funktionsweise der Hardware.
Hem, nicht unbedingt. Denn Assembler ist auch eine gewisse Abstraktion. Wenn man es weiter spinnen würde, müsste man reine Hexwerte... ach ne, ist ja auch nur ne Abstraktion von zusammen gefassten Bits.
Nein, also im Ernst: es schadet nicht, wenn man Assembler mal programmiert hat. Aber es hilft einem nicht weiter, weil man dadurch nur eine CPU-Architektur kennen lernt. Und wenn man Pech hat, noch dazu eine der mieserabelsten (x86). Also ich weiß nicht. Man bekommt dann vielleicht mit, das man Glücklich sein kann, C++ als Werkzeug zu haben. Ich habe damals 6510 und ARM2 Assembler programmiert. Aber ein Indexbasiertes Feld und wie ein Computer funktioniert, habe ich davor schon mittels BASIC und dessen PEEK und POKE gelernt. Und wie ich Daten im Speicher sequenziell ablege, habe ich davor schon mit dem DATA Befehl gelernt. Das ich mit Assembler besser wurde, um die Grundlagen zu kennen, kann ich deshalb nicht bestätigen. Es waren lediglich andere Sprachen und die ARM-Assembler-Sprache ist bis heute meiner Meinung nach die beste.
redrew99 schrieb:
Was also soll der Maßstab sein, um mit C oder C++ zu beginnen?
C und C++ halte ich generell nicht für gute Einstiegssprachen, weil man neben der Sprache noch viele andere Dinge lernen muß, z.B. der Umgang mit Headern, das Linken usw.
Ich halte immer noch eine Sprache wie BASIC (nein, nicht VisualBasic.NET, das hat meiner Meinung nicht mehr viel mit BASIC-Urgedanken gemeinsam), da sie Grundlagen der Programmierung beibringt, ohne das man sich viel mit Nebenkriegsschauplätzen auseinander setzen muß.
-
@Artchi: Noch abstrakter. Du würdest natürlich nicht new[], delete[] benutzen, sondern einen nutzerdefinierten Allocator mit Standardwert std::allocator<T>.
-
-
Artchi schrieb:
weil ich vector mit new[] und delete[] implementieren müsste, worauf ein C-Programmierer ohne C++-Wissen nicht kommen würde. Ich brauche dafür absolut kein C-Wissen.
Ok, das wußte ich nicht. Dachte, daß new[] und delete[] Relikte aus C sind.
Aber solche Sachen wie Schleifen oder Funktionen z.B. sind doch eigentlich C oder?
-
redrew99 schrieb:
Ja, in vielen Fällen braucht man es vermutlich nicht.Auf der anderen Seite - z.B. habe ich mir mal den Code einer verketteten Liste angeschaut, um zumindest ansatzweise zu verstehen, wie ein c-vector funktioniert.
Nochmal, da du es nicht mitbekommen zu haben scheinst: Vector ist keine verkettete Liste! In keiner Implementierung! Vector ist ein netter Bedienkomfortwrapper um ein dynamisches Array. Wenn man die ganzen Memberfunktionen (und zusätzlichen Templateparameter) mal außen vor lässt, wird das nicht viel mehr sein als
template<class T> class vector { T* begin_data, end_data, end_allocated; };Und fertig. Aus technischen Gründen werden die Verwaltungsdaten noch in einer Unterklasse stehen, aber von der Funktionalität her war's dies schon.
