Programiersprache für Anfänger
-
Bulli schrieb:
Wo ist also in C++ da das Problem, wenn selbst ein dummer Compiler versteht, was gemeint ist?
das *ist* das Problem: Was für einen "dummen" Computer oder Compiler gut verständlich ist, ist in der Regel für den Menschen schwer verständlich, und umgekehrt. Man denke an Binärcode.
Abgesehen davon finde ich es auch komisch, daß ich in C++ alle Typen selbst vereinbaren muß, aber sobald ich einen Typ-Fehler begehe, mich der Compiler ermahnt, und sogar hinweist, wie der richtige Typ lauten würde a la "expected: int*, got: int**" - warum typisiert er nicht einfach selber, statt dem Programmierer diese fehlerträchtige Arbeit aufzuhalsen - offenbar kann er es ja ?
Bulli schrieb:
Es ist aber nicht so schwer zu lernen, wie es hier einige verkaufen wollen.
das hängt vom Background ab. Als ich C lernte, konnte ich schon mehrere Assemblersprachen, da war C also kein Problem.
Mir scheint, daß die Gewöhnung an logisches Denken ein Hindernis beim Lernen von C++ ist. C++ ist teilweise nicht logisch, es gibt keine eindeutige Zuordnung zwischen Syntax-Elementen und Konzepten, viele Symbole und Schlüsselwörter sind mehrfach überladen mit Bedeutungen, die teilweise nichts miteinander zu tun haben.
-
asc schrieb:
Der Name ist Programm... Wenn du C++ als " Unlogisch und kompliziert" betrachtest, gilt dies erst recht für C.
http://www.artima.com/cppsource/safebool.html
Kannst du mal schnell das mit dem safe bool idiom und dem Rückgabewert bool oder void* erklären, ich hab das noch nicht ganz verstanden. Sollte doch auch einfach, logisch und unkompliziert ohne 3 Seiten Text gehen, da C++. Und wie war das mit dem assign operator und exception safety?
-
naja, da jetzt meine anfängliche frage zur diskussion über c bzw. c++ wurde kann das thema auch geschlossen werden weil es keinen sinn mehr hat. ich werde mir jetzt einfach mal 2-3 bücher über c++ holen und bin gerade dabei mir phyton anzugucken. ich hoffe es klappt aber erwarte auch nicht von mir selbst, das ich in 1 monat programmieren kann. trotzdem vieln dank für eure beiträge und vll. bis bald mal wieder...
-
isklar schrieb:
asc schrieb:
Der Name ist Programm... Wenn du C++ als " Unlogisch und kompliziert" betrachtest, gilt dies erst recht für C.
http://www.artima.com/cppsource/safebool.html
Kannst du mal schnell das mit dem safe bool idiom und dem Rückgabewert bool oder void* erklären, ich hab das noch nicht ganz verstanden. Sollte doch auch einfach, logisch und unkompliziert ohne 3 Seiten Text gehen, da C++. Und wie war das mit dem assign operator und exception safety?Interessantes Problem, aber es erklärt nich nicht warum C weniger Kompliziert ist als C++, da es die gleichen Probleme hat, weniger Typsicherheit besitzt...
Und nur das zweifel ich hier an. Ich habe niemals gesagt das C++ unkompliziert ist, aber mehr als C (Alleine die vielen Zusatzbedingungen die man in der C-Bibliothek wissen muss um Funktionen aufzurufen, ohne in Laufzeitfehler zu rennen, die in der C++ Bibliothek zum Großteil dank Typsicherheit, Klassen etc. bereits in der Compilezeit aufgedeckt werden können).
Ich lobe weder C++ in den Himmel, noch ziehe ich C die Existenzberechtigung ab. Nur von der Komplexität sind beide ähnlich. Und beide ebenso schwer für ein Anfänger zu lernen.
fricky schrieb:
problemchen 1: 'cout' interpretiert seine eingabe. das kann schief gehen bzw. anders aussehen als gewünscht (hier gabs mal 'nen thread, in dem 'cout' in verbindung mit volatile sich ziemlich seltsam verhielt).
problemchen 1.5: deine printf-zeile enthält einen fehler.
problemchen 2: ein 'cout'-ausdruck, der mehrere objekte formatiert ausgeben soll, wird sehr lang und hässlich, jedenfalls im vergleich zu 'printf'.Zu 1 & 1.5: cout interpretiert seine Aussage wenigstens typsicher. Der Fehler in der C-Zeile soll wohl nur auf die Leichtigkeit hinweisen wie man in C einen Laufzeitfehler hinbekommt. Und Anfänger werden mit volatile (Das ich übrigens bislang nur sehr selten -eher nie- in Anwendungsprogrammen begegnet bin) wohl nur wenig bis garnicht in Kontakt kommen.
Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.u-ser_l schrieb:
Mir scheint, daß die Gewöhnung an logisches Denken ein Hindernis beim Lernen von C++ ist.
Das mag dir so gehen, ich finde C++ in vielen Bereichen logischer und vor allem auch sicherer als seine C-Altlasten...
cu André
-
~fricky schrieb:
problemchen 1.5: deine printf-zeile enthält einen fehler.
Ja, mit voller Absicht, um direkt eines der Probleme von printf aufzuzeigen.
problemchen 2: ein 'cout'-ausdruck, der mehrere objekte formatiert ausgeben soll, wird sehr lang und hässlich, jedenfalls im vergleich zu 'printf'.
Der Formatstring von printf ist hässlich, jedenfalls im Vergleich zu cout. Oder anders: Geschmacksfragen sollten wir entweder aussen vor lassen oder gegeneinander aufwiegen :p
-
asc schrieb:
ich finde C++ in vielen Bereichen logischer und vor allem auch sicherer als seine C-Altlasten...
ich finde C++ auch angenehmer als C, vor allem wegen Strings, STL-Containern und wegen der Datenkapselung durch das OO-Modell.
Logischer finde ich C++ deswegen aber nicht - eher unlogischer. Hatte man bei C nur eine Art von Referenzen (nämlich Zeiger), so hat man jetzt zwei. Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat. Der Programmierer muß in C++ einfach zu viel Verwaltungskram selbst machen, den auch der Compiler erledigen könnte: Prototypen, Typisierung, Garbage Collection (klar - geht nicht, wenn man Zeiger zuläßt), ...
Die Seitenzahl der Referenzbücher spricht da eine deutliche Sprache - je mehr erklärt werden muß, umso weniger intutiv muß eine Sprache wohl sein.
-
asc schrieb:
Zu 1 & 1.5: cout interpretiert seine Aussage wenigstens typsicher. Der Fehler in der C-Zeile soll wohl nur auf die Leichtigkeit hinweisen wie man in C einen Laufzeitfehler hinbekommt. Und Anfänger werden mit volatile (Das ich übrigens bislang nur sehr selten -eher nie- in Anwendungsprogrammen begegnet bin) wohl nur wenig bis garnicht in Kontakt kommen.
Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.Warnung: format »%d« erwartet Typ »int«, aber Argument 2 hat Typ »char *«...
u_ser-l schrieb:
Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat.
Zähl mir doch bitte mal alle Mehrdeutigkeiten von
staticin C auf...
-
u_ser-l schrieb:
ich finde C++ auch angenehmer als C, vor allem wegen Strings, STL-Containern und wegen der Datenkapselung durch das OO-Modell.
Warum diskutieren wir dann überhaupt?
u_ser-l schrieb:
Logischer finde ich C++ deswegen aber nicht - eher unlogischer. Hatte man bei C nur eine Art von Referenzen (nämlich Zeiger), so hat man jetzt zwei.
Die aber unterschiedliche Bedeutung haben, und zusätzlich je nach Verwendung vom Compiler auch anders umgesetzt werden können (Referenzen können intern Zeiger sein, können aber ebenso gänzlich wegoptimiert werden).
u_ser-l schrieb:
Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat.
Es ist klar das wenn man einerseits weitgehen C-Kompatibel sein will, anderseits aber neue Möglichkeiten eröffnen will, eine Sprache mehr Befehle oder Zeichen verwenden muss (bzw. Zeichen auch noch mehrere Kontextspezifische Bedeutungen gibt).
Nichts desto trotz spart man sich in C++, sofern man auch wirklich C++ und nicht C Programmiert, viele Fallstricke aus C. Daher sehe ich beides von der Komplexität gleich an. Ansonsten müsste man sagen das C#/Java komplexer als C/C++ ist, weil der Bibliotheksumfang größer ist.
Man kommt als Anfänger immer nur mit einem Teil in Berührung. Und nicht nur als Anfänger. Ich frage mich wieviele C++ Programmierer (prozentual) jemals direkt mit der Templatemetaprogrammierung zu tun haben. Ich tippe eher wieder auf die 90:10 Regel (90 Prozent werden es niemals direkt verwenden, indirekt über Bibliotheken vielleicht).
u_ser-l schrieb:
Der Programmierer muß in C++ einfach zu viel Verwaltungskram selbst machen, den auch der Compiler erledigen könnte: Prototypen, Typisierung, Garbage Collection (klar - geht nicht, wenn man Zeiger zuläßt), ...
Und wo bitte ist da C besser (Ich habe niemals gesagt das C++ besser, leichter... als andere Sprachen ist, verwehre mich nur dagegen das C weniger Komplex sein soll. Für einen Anfänger eher nicht.
u_ser-l schrieb:
Die Seitenzahl der Referenzbücher spricht da eine deutliche Sprache - je mehr erklärt werden muß, umso weniger intutiv muß eine Sprache wohl sein.
Dann sie bitte auch meine (Anwendungsfallspezifische) Empfehlung an. Siehst du dort an vielen Stellen C++?
cu André
-
Tim schrieb:
asc schrieb:
...Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.
Warnung: format »%d« erwartet Typ »int«, aber Argument 2 hat Typ »char *«...
Das klappt aber nur wenn der C-Compiler komplexes Parsing betreibt, und das machen beileibe nicht nicht alle. Ich weiß noch wieviele Laufzeitfehle ich wegen falscher Benutzung von C-Funktionen in Programmen suchen durfte (und nein, die C-Funktionen habe nicht ich eingebaut, ich durfte sie nur ausbaden).
cu André
-
asc schrieb:
Das klappt aber nur wenn der C-Compiler komplexes Parsing betreibt, und das machen beileibe nicht nicht alle.
Sollen wir darüber diskutieren wieviele C++ Compiler nicht komplett z.B. Templates umsetzen?
Ich wollte lediglich andeuten, dass die Beispiele die hier gegeben werden nicht sonderlich sinnvoll sind. Aber durchaus passend zur Diskussion...
-
Tim schrieb:
Zähl mir doch bitte mal alle Mehrdeutigkeiten von
staticin C auf...wieso? Hast Du kein C++ Buch ?
1. static Variable innerhalb einer Funktion
2. static globale Variable innerhalb ihrer Datei
3. static Deklaration in Klassen, vor Variablen und Funktionen3 verschiedene Konzepte teilen sich 1 Schlüsselwort. Das ist nicht logisch und dient nicht der Erfaßbarkeit der Sprache für Anfänger.
-
Ohne dass dazu ausreichend relevante Aussagen von Anfängern vorliegen ist das einfach eine unbelegte Behauptung.
-
ich verstehe auch nicht, warum das Hinderlich sein soll. Ich kann zwischen den Konzepten sogar Paralellen erkennen. Das in Funktionen und das in Klassen ist für ihren Anwendungsbereich im Prinzip sogar das gleiche. Zumindest aus rein logischer Sicht. Die Konzepte die du nennst, sind wieder die technische Sicht, die du selbst kritisierst.
-
u_ser-l schrieb:
Tim schrieb:
Zähl mir doch bitte mal alle Mehrdeutigkeiten von
staticin C auf...wieso? Hast Du kein C++ Buch ?
Ich habe in der Tat kein C++-Buch. Ich habe auch kein C-Buch, aber das war trotzdem nicht der Grund warum ich explizit nach static in C fragte.
Kurzum, C hat ebenso Mehrfachbelegung von Schlüsselwörtern/Operatoren. Teilweise sogar richtig unsinnige.
-
asc schrieb:
(Referenzen können intern Zeiger sein, können aber ebenso gänzlich wegoptimiert werden).
du verwechselst hier zwei Konzepte - die unabhängigen Referenzen (Variablenumbenennung) und die Argument-Übergabe per Referenz in Funktionen.
Nur weil diese Konzepte beide das '&' beanspruchen, ist es nicht dasselbe. Variablenumbenennungen können im Einzelfall wegoptimiert werden, bei Argumentübergabe by-reference wird die CPU im allgemeinen einen Zeiger übergeben müssen, das läßt sich nicht wegoptimieren.
Genau das ist eines der Probleme von C++ - verschiedene Konzepte stecken in ein- und demselben Syntaxelement (hier '&'), was offenbar selbst einigen Fortgeschrittenen gar nicht klar ist.
asc schrieb:
Es ist klar daß, wenn man einerseits weitgehen C-Kompatibel sein will, anderseits aber neue Möglichkeiten eröffnen will, eine Sprache mehr Befehle oder Zeichen verwenden muss (bzw. Zeichen auch noch mehrere Kontextspezifische Bedeutungen gibt).
Würde man all die zahlreichen kontext-abhängigen Mehrfachbelegungen von Syntaxelementen aus C++ entfernen, indem man zusätzliche Schlüsselwörter und Sonderzeichen einführt, dann wäre C++ ein noch viel riesigeres Sprachkonstrukt mit etlichen Schlüsselwörtern mehr.
Z.B. müßte "static" im Kontext von globalen Variablen mit Datei-weiter Gültigkeit eher "filewide" oder so heißen. "static" bei Deklarationen innerhalb von Klassen sollte besser
"unique" oder "classvar" heißen oder etwas in der Richtung.Aber immerhin könnte man damit erreichen, daß eine eindeutige Zuordnung zwischen Syntax-Elementen und Konzepten entsteht.
-
du verwechselst hier zwei Konzepte - die unabhängigen Referenzen (Variablenumbenennung) und die Argument-Übergabe per Referenz in Funktionen.
Du nennst hier Logik und unterscheidest dann zwischen technischen Unterschieden, bei, rein logisch betrachtet, gleichen Konzepten?
edit: Wie die Compiler das umsetzen und was da für Performanceunterschiede sind sollte für Anfänger doch sowas von egal sein.
-
Bashar schrieb:
Ohne dass dazu ausreichend relevante Aussagen von Anfängern vorliegen ist das einfach eine unbelegte Behauptung.
es dient grundsätzlich nie der Erfaßbarkeit und Lernbarkeit, wenn verschiedene Konzepte denselben Namen tragen oder auf dieselbe Syntax abgebildet werden.
Und z.B. die Datei-weite Variablengültigkeit globaler Variablen ist ein anderes Konzept als der Wertbehalt lokaler Variablen zwischen Funktionsaufrufen, und trotzdem heißt beides "static".
-
u-ser_l schrieb:
es dient grundsätzlich nie der Erfaßbarkeit und Lernbarkeit, wenn verschiedene Konzepte denselben Namen tragen oder auf dieselbe Syntax abgebildet werden.
Du wiederholst dich, also tu ich das auch: Wo bleibt dein Beleg?
-
Tim schrieb:
Sollen wir darüber diskutieren wieviele C++ Compiler nicht komplett z.B. Templates umsetzen?
Die Warnung bei printf ist aber eine freiwillige Leistung, die nicht vom Standard abgedeckt wird. Und auch wenn die Diskussion nicht sonderlich sinnvoll ist, kann man beim Vergleich von Sprachen nicht die Vorteile eines einzelnen Compilers zugunsten der Sprache auslegen.
Davon ab, dass Dein Fehler zur Compilezeit den Übersetzungsvorgang nicht sonderlich beeinträchtigt
-
LordJaxom schrieb:
Tim schrieb:
Sollen wir darüber diskutieren wieviele C++ Compiler nicht komplett z.B. Templates umsetzen?
Die Warnung bei printf ist aber eine freiwillige Leistung, die nicht vom Standard abgedeckt wird. Und auch wenn die Diskussion nicht sonderlich sinnvoll ist, kann man beim Vergleich von Sprachen nicht die Vorteile eines einzelnen Compilers zugunsten der Sprache auslegen.
Wenn man nur die Theorie betrachtet, hast du sicher recht.
LordJaxom schrieb:
Davon ab, dass Dein Fehler zur Compilezeit den Übersetzungsvorgang nicht sonderlich beeinträchtigt
Es ist aber trivial ihn zu erkennen
