Erst C lernen oder weiter mit C++ machen?

von allen sprachen die ich bisher "gelernt" hab, hat mir c am meisten gebracht! wer dann noch versucht 'highlevel' features in c nachzubauen, wird ein viel tieferes verständniss erlangen und auf dauer viel besseren code erzeugen.

asc

__-- schrieb:

von allen sprachen die ich bisher "gelernt" hab, hat mir c am meisten gebracht! wer dann noch versucht 'highlevel' features in c nachzubauen, wird ein viel tieferes verständniss erlangen und auf dauer viel besseren code erzeugen.

Man kann auch mit C++ die Grundlagen auf binärebene usw. lernen, nur muss man dazu deshalb dennoch weder den C-Stil, noch die C-Bibliotheken lernen. Ich wiederspreche auch nicht, wenn man sagt, das gewisses Lowlevel-Wissen sinnvoll ist, aber wie gesagt muss man dazu dennoch kein C lernen.

man lernt sowas aber nicht freiwillig (wer baut in c++ oop nach? den deppen zeigst mir mal!). dazu lernt man, dass funktionen rückgabe werte haben und vertraut nicht gleich darauf, mit einem try/catch die ganzen fehler abzufangen. dazu dann noch die stdlib funktionen die sich in vielen anderen programmiersprachen wiederfinden (c++ stdlib funktionen hab ich noch nie in anderen sprachen gefunden).

Lass am besten C++ ganz sein. Die Sprache war und ist noch immer der größte Krampf in der IT-Geschichte.

__-- schrieb:

(c++ stdlib funktionen hab ich noch nie in anderen sprachen gefunden).

erzähle nicht so einen Grind. In PHP beispielsweise wird mit SPL sowas in der Richtung gemacht.

haben wir uns nicht schon öfter daruf geeinigt, dass php nicht der große wurf war

dazu lernt man, dass funktionen rückgabe werte haben und vertraut nicht gleich darauf, mit einem try/catch die ganzen fehler abzufangen.

Immer diese Scheinargumente. Lernt man das in C++ etwa nicht? Wie kommt's, dass ich mit C++ angefangen habe und trotzdem mit solchen Funktionen umgehen kann? Als Beispiel für Funktionen, die über ihren Rückgabewert einen Fehler ausgeben, seien auch die IOStreams Klassen genannt (wobei man hier sogar die Wahl hat), deren Handhabung in jedem besseren C++ erklärt wird.

dazu dann noch die stdlib funktionen die sich in vielen anderen programmiersprachen wiederfinden (c++ stdlib funktionen hab ich noch nie in anderen sprachen gefunden).

Ja, aber wozu? Zu vielen Funktionen gibt es eine C++ Alternative und wenn nicht, schaut man sich halt mal auf www.cplusplus.com die Spezifikation und die Beispiele an und schon hat's sich. Ist ja nicht so als wäre C kompliziert.

asc schrieb:

**(2)**Die Folge ist, das wer zuerst C und dann C++ lernt, nicht selten C mit Klassen, aber kein C++ programmiert.

C funktioniert nach dem Prinzip 'Teile und Herrsche' bzw. lässt sich damit
viel einfacher als mit C++ auch große, stabile, zuverlässige und
professionelle Software schreiben.
In C++ gilt ja demgegenüber schon alleine
diese Herangehensweise an größere Projekte (aka. 'Funktionale Dekomposition'),
als schädlich und deshalb wird man mit C++ auch nicht so ohne weiteres
ein größeres Projekt ordentlich analysieren können.
In C++ und OOP arbeitet man ja scheinbar lieber nach dem Prinzip
'Versuch und Irrtum', dort bastelt irgendwelche wildfremden Klassen
und Objekte zu einer (meistens) ziemlich verbuggten Scheinlösung
der Aufgabenstellung zusammen, ohne sich je sonderliche Gedanken über eine
geeignete Modularisierung der Aufgabenstellung (== funktionale Dekomposition ist
ja in C++ ein sog. Design-Anti-Pattern) gemacht zu haben. Man nimmt halt
meistens irgendwelche Klassen her, die man schon hat oder irgendwo im Internet
findet (ohne Gewähr ob sie überhaupt funktionieren oder von wem sie eigentlich
erfunden wurden), und pfercht sie dann unreflektiert zu einem Spaghetti-Code
zusammen. Und das nennt man dann halt lustiger Weise OOP und ist wohl eher
eine Marketing-Schlagwort und hat eigentlich ansonsten keinerlei Vorteile.

Naja, also mE ist es vernünftiger, dass man C lernt, weil man sich dann die
schlampige und problemferne (aka 'abstrakte') Arbeitsweise der C++ Programmierer
gar nicht erst angewöhnt. Man möchte ja meistens doch eher etwas Konkretes
programmieren (== C) als irgend einen abstrakten OOP-C++-Käse.

Funktionale Dekomposition und damit auch Problemlösungskompetenz lernt man
eigentlich nur, wenn man viel mit C arbeitet.
Mit C++ wird man eher zum Konsumenten und Anwender irgendwelcher
vorgebastelter Klassen und Frameworks 'erzogen', die man selten wirklich versteht oder
lt. C++ Lehrmeinung gar nicht verstehen soll.
Programmieren in C++ ist sehr gut vergleichbar mit einem Koch, der
das Gericht verwürzt, weil er keine Ahnung davon hat, was in seinen
verschiedenen Gewürz-Behältern eigentlich drinnen ist (bzw. weil er sich auch
gar nicht sonderlich dafür interessiert). Also nimmt er halt irgendwelche
Behälter her und kippt auf gut Glück halt auch irgend welche Zufälligen Gewürze
in die Suppe.
Guten Appettit !! In etwa so schmecken nämlich auch die C++ - Erzeugnisse
(verglichen mit C-Software, wo man Software ganz allgemein viel gründlicher
plant und idR auch mehr Kontrolle darüber / Interesse daran hat, welche
Gewürze man dem Konsumenten zumuten möchte und welche nicht !!)
mfg

volkard

Paradigma1 schrieb:

...

Und schon wieder der selbe unregistrierte C++-Basher.

ipsec

@Paradigma1:
Eigentlich erstaunlich, dass mit C++ überhaupt jemals irgendwelche halbwegs vernünftig laufende und annehmbar stabile Anwendungen entwickelt worden sind. Überhaupt mit OOP-Sprachen allgemein. Die Programmierer müssen reine Genies gewesen sein.
Natürlich wäre das mit C auch alles viel besser gegangen...

Irgendwer schrieb:

Ist ja nicht so als wäre C kompliziert.

das ist doch das schöne

ipsec schrieb:

@Paradigma1:
Eigentlich erstaunlich, dass mit C++ überhaupt jemals irgendwelche halbwegs vernünftig laufende und annehmbar stabile Anwendungen entwickelt worden sind. Überhaupt mir OOP-Sprachen allgemein. Die Programmierer müssen reine Genies gewesen sein.
Natürlich wäre das mit C auch alles viel besser gegangen...

Sagt ja niemand, dass nicht auch mal ein blindes Huhn ein Korn findet
(Yhprum's Gesetz), aber 99 von 100 OOP/C++ Projekte gehen idR total daneben,
(weil ja in C++ auch nach dem Muster 'Versuch & Irrtum' vorgegangen wird,
während man in C viel besser und zielgerichteter
mit der funktionalen Dekomposition('Teile und Herrsche')
einen komplexen Prozess in brauchbare (und meistens viel besser
wiederverwendbare ...) Teilmodule gliedern kann. Aber die C++ Experten
halten die Methode ja für ein Anti-Pattern und sind deshalb zu so einer
Analyse gar nicht erst in der Lage. Und deshalb sind ja auch 99% aller
C++/OOP Projekte verbuggt, weil völlig ohne der funktionalen Dekomposition
in willkürlicher Weise x-beliebige abstrakte und verbuggte Basisklassen zu
einem Topf Spaghetti zusammengewürfelt werden, gewürzt mit dem Inhalt aus
Containern, für den sich keiner der Entwickler interessiert!

mfg

Auch in C++ versucht man die Funktionen so kurz und präzise wie möglich zu halten. Auch Klassen sollten idealerweise nur eine Aufgabe haben.

All das zeigt, dass du einfach keine Ahnung hast.

ipsec

Wenn 99% der C++-Anwendungen (oder allgemeiner: OOP-Anwendungen) komplett verbuggt wären, wäre dein Computer komplett unbenutzbar. Das fängt vielleicht nicht beim Kernel, aber bei den Treibern und Diensten an und hört beim Office und beim Browser noch lange nicht auf.
Wie viele Anwendungen des täglichen Bedarfs sind in C geschrieben?

Irgendwer schrieb:

Auch in C++ versucht man die Funktionen so kurz und präzise wie möglich zu halten. Auch Klassen sollten idealerweise nur eine Aufgabe haben.

All das zeigt, dass du einfach keine Ahnung hast.

Nein, das zeigt nur deutlich den grundlegenden Unterschied der Herangehens-
weise an die Aufgabenstellung:

(I) OOP
OOP stellt zuerst einige Regeln, Dogmen, Gundsätze, 'Patterns' usw. auf,
um festzulegen, wie man jedes Problem prinzipiell zu lösen hätte, und
wie man es jedenfalls nie lösen darf.
Erst danach sieht man sich das konkrete Problem an, und ist dann bereits bei
der Analyse ziemlich gefangen in diesem dogmatischen Denken, da man schon
im Voraus eine Menge (prinzipiell) gangbare Wege gar nicht erst in Betracht
zieht - das Risiko ist deshalb sehr groß, dass man entweder zu keiner Lösung
(im Rahmen der selbst auferlegten 'Regeln') gelangt, oder jedenfalls nur zu
einer suboptimalen Lösung (da man andere Lösungsansätze aus design-ästhetischen
oder was-auch-immer Gründen gar nicht erst 'entdecken' kann).

(II)
In der prozeduralen Programmierung nach Maßgabe der funktionalen
Dekomposition (eines der übelsten Anti-Patterns aus Sicht der OOP-Gilde),
ist genau das Gegenteil der Fall.
Man nimmt nämlich nicht schon im Vorhinein an, dass es so etwas wie
'prinzipiell schlechte' oder 'prinzipiell gute' Design-Patterns
für jedes nur erdenkliche Problem überhaupt geben kann. Stattdessen geht
man von der konkreten Aufgabenstellung aus, und kommt dann nach Analyse
('Teile und Herrsche') der implizierten Teilaufgaben zu einer
Design-Entscheidung, die sich vorrangig am konkreten Problem orientiert,
und weniger an irgend welchen dogmatischen OOP-Patterns,
('wie man es immer und in jedem Fall zu machen hätte, und was man auf keinen
Fall machen darf!'). Dadurch gewinnt man überhaupt erst die notwendige FREIHEIT,
die notwendig ist, um zu einer Lösung zu kommen, weil man eben nicht im
Vorhinein schon mögliche (wenn auch oft aus design-Gründen problematische)
Lösungswege ausschließt. (Selbstverständlich wird man auch eher auf diese
Weise jemals zu innovativen Lösungsansätzen gelangen, da man ja prinzipiell
nichts ausschließt und auch uU. ein Mädchen für alles (God Object) oder ähnli-
che OOP-Sünden in seinem Projekt duldet - wenn es ansonsten keine bessere
Möglichkeit gibt oder auch einfach nur die zur Verfügung stehende Zeit nicht
ausreicht).

Habe mich wirklich bemüht, hier die zwei grundlegend verschiedenen
Paradigmen
(I) OOP
(II) prozedurale/modulare Programmierung
zu vergleichen.

Es sei noch einmal darauf hingewiesen, dass diese Konzepte eigentlich
überhaupt nicht an eine Sprache (C oder C++) gekoppelt wären, und man sich
selbstverständlich auch in C an die Schablonen und Regeln vom Typ (I) 'OOP'
halten bzw. objektorientiert programmieren kann, so man möchte.
(Gute Lektüre zu dem Thema -> http://www.planetpdf.com/codecuts/pdfs/ooc.pdf).

Umgekehrt könnte man auch (wenn man möchte), als C++ Programmierer
mal eine richtig dicke Superklasse oder Superfunktion basteln und sämtliche
OOP-Grundsätze über Bord werfen, wenn es (aus welchen Gründen auch immer)
plötzlich angebracht erscheint. Nur schaffen es die aller wenigsten C++ Jünger,
über diesen Schatten zu springen, weil sie sich nicht von dem dogmatischen
Design-Quatsch vieler 'moderner' C++ Bücher (tu dieses nicht, tu jenes immer,
C ist futchtbar, nimm niemals char, Zeiger, Macros oder sonstwas etc. etc.)
loslösen können und nur Problemlösung nach Schablone (==template)
gelehrt bekommen. Wehe, wenn dann mal eine Aufgabe mit keiner der bekannten
Schablonen und Toolkits lösbar ist ...

Also ich bleib' dabei: C sollte jedenfalls die Vorschulung für C++ sein,
damit überhaupt erst mal das selbständige Problemlösen trainiert wird.
Und dann kann man immer noch C++ lernen und dann willenlos die eisernen
Lehrsätze der OOP-Gurus befolgen (und sogar u.U. nachvollziehen!).

mfg

SideWinder

Das wird hier ja doch keine vernünftige Diskussion...closed.

MfG SideWinder