Wie am besten anfangen?

[pongo710]

~john schrieb:

pongo710 schrieb:

Hallo, ich möchte mir gerne C beibringen und wenn ich das schaffe danach C++. Aber zuerst mal C.

Wenn es das Ziel ist C++ zu programmieren empfiehlt es sich nicht mit C anzufangen. Auch wenn die meisten C Programme formal C++ Programme sind, würde man ein C++-Programm niemals so formulieren, wie man das in C macht. Man legt sich beim Erlernen von C einen Programmierstil zu, den man bei C++ gleich wieder verlernen muß. Andernfalls baut man ganz schnell gravierende Mängel in die Programme ein.

Wenn man C erlernen will, wird es schwierig, da es faktisch keinerlei Literatur gibt, die korrekte C Programme enthält oder das Programmieren korrekter C Programme lehren würde. C ist die Programmiersprache mit der es am einfachsten ist unsichere Programme zu schreiben. Die Liste der Exploits für die diversen C Programme ist irrsinnig lang, und es sind immer wieder die gleichen Fehler die auftreten: Buffer over-/underflow, Formatstring Attacken ... Daran sieht man, daß es auch den selbsternannten C-Könnern nicht wirklich gelingt einen korrekten Programmierstil durchzuhalten und einfachste aber fatale Fehler zu vermeiden. Auch die Standardlibrary enthält eine ganze Reihe von Funktionen, die inhärent unsicher sind und bei denen man peinlichst darauf achten muß, daß diese Designfehler nicht zu Exploits in der Software führen. Das Problem in diesem Kontext ist es, daß Anfängerliteratur das nicht erklärt und so Falsches lehrt mit verheerenden Folgen. Selbst die ISO Norm enthält falsche Programmbeispiele! Der absolute Tiefpunkt ist "gets", diese Funktion ist grundsätzlich so aufgebaut, daß die Verwendung in einem Programm unweigerlich zu einem Exploit führt. Wie man so einen Dreck überhaupt einmal in die ANSI Norm aufnehmen konnte, ist schleierhaft. Wenn es sich irgendwie vermeiden läßt C zu benutzen, sollte man dies auch tun. Hier im C Forum wird das natürlich grundsätzlich anders gesehen, davon sollte man sich nicht blenden lassen. C ist schwierig zu beherrschen und schlechte Literatur führt sehr leicht zu fehlerhaften Programmen, die zwar auf den ersten Blick korrekt funktionieren, in der Realität aber fatale Sicherheitslücken enthalten. Gute C-Literatur müßte dies berücksichtigen. Womit wir wieder am Anfang wären.

Danke für diese Ausführliche Antwort. Ich werde nach den ganzen Antworten hier wohl nicht C lernen.

[großerUnsinn]

~john schrieb:

pongo710 schrieb:

Hallo, ich möchte mir gerne C beibringen und wenn ich das schaffe danach C++. Aber zuerst mal C.

Wenn es das Ziel ist C++ zu programmieren empfiehlt es sich nicht mit C anzufangen. Auch wenn die meisten C Programme formal C++ Programme sind, würde man ein C++-Programm niemals so formulieren, wie man das in C macht. Man legt sich beim Erlernen von C einen Programmierstil zu, den man bei C++ gleich wieder verlernen muß. Andernfalls baut man ganz schnell gravierende Mängel in die Programme ein.

Wenn man C erlernen will, wird es schwierig, da es faktisch keinerlei Literatur gibt, die korrekte C Programme enthält oder das Programmieren korrekter C Programme lehren würde. C ist die Programmiersprache mit der es am einfachsten ist unsichere Programme zu schreiben. Die Liste der Exploits für die diversen C Programme ist irrsinnig lang, und es sind immer wieder die gleichen Fehler die auftreten: Buffer over-/underflow, Formatstring Attacken ... Daran sieht man, daß es auch den selbsternannten C-Könnern nicht wirklich gelingt einen korrekten Programmierstil durchzuhalten und einfachste aber fatale Fehler zu vermeiden. Auch die Standardlibrary enthält eine ganze Reihe von Funktionen, die inhärent unsicher sind und bei denen man peinlichst darauf achten muß, daß diese Designfehler nicht zu Exploits in der Software führen. Das Problem in diesem Kontext ist es, daß Anfängerliteratur das nicht erklärt und so Falsches lehrt mit verheerenden Folgen. Selbst die ISO Norm enthält falsche Programmbeispiele! Der absolute Tiefpunkt ist "gets", diese Funktion ist grundsätzlich so aufgebaut, daß die Verwendung in einem Programm unweigerlich zu einem Exploit führt. Wie man so einen Dreck überhaupt einmal in die ANSI Norm aufnehmen konnte, ist schleierhaft. Wenn es sich irgendwie vermeiden läßt C zu benutzen, sollte man dies auch tun. Hier im C Forum wird das natürlich grundsätzlich anders gesehen, davon sollte man sich nicht blenden lassen. C ist schwierig zu beherrschen und schlechte Literatur führt sehr leicht zu fehlerhaften Programmen, die zwar auf den ersten Blick korrekt funktionieren, in der Realität aber fatale Sicherheitslücken enthalten. Gute C-Literatur müßte dies berücksichtigen. Womit wir wieder am Anfang wären.

So ein Unsinn, es ist genauso leicht auch in PHP möglich heftigste Sicherheitslücken einzubauen. Ich kenne keine Sprache wo man nicht auch auf die Sicherheit achten müsste und einige Funktionen besser nicht nutzt. Man muss überall wissen welche der mitgelieferten Funktionen sicher sind und welche nicht.
Adobe Acrobat, Firefox etc. sind zum großen Teil in C++ geschrieben und da gibt es auch ständig heftigste Fehler. Nur weil man in C programmiert bedeutet dies bei weitem nicht dass man gleich unsicher programmiert. Sicherheit muss man in C genauso lernen wie in anderen Sprachen auch, das kommt aber meist erst etwas später wenn man dann anfängt größere Software zu schreiben die auch jemand anders nutzt.

Wäre dein Posting auf Papier geschrieben so müssten man es mit einem Kopfschütteln zerknüllen und in hohem Bogen in den Müllkorb werfen.

Wenn du mich fragst lerne zuerst C, die Sprache ist einfach leichter zu durchschauen. Die größte Hürde sind die Zeiger, aber das ist nix im Vergleich zu dem was man in C++ alles lernen muss, wenn man es richtig machen möchte.

Ich finde C++ einfach nur anstrengend.

Wenn du C nicht traust dann traue auch nicht den Linux/Windows-kernel und viele Industriesteuerungen. Glaub mir man kann auch in C sehr sicher programmieren, das ist kein Argument gegen die Sprache.

[pointercrash**]

Michael E. schrieb:

Nur als Tipp: In C gibts zwar Funktionen, aber man programmiert darin gewöhnlich nicht funktional

Da hat mich ein früher Halloween- Kürbis an der Birne erwischt , gemeint war natürlich prozedural, wenn überhaupt. An der Uni war Pascal das Höchste , am Gumminasium *schauder* BASIC . Ein bißchen VHDL noch zum Diplom und jeder potentielle AG fragte mich, wieviel 100k LOC ich schon in C++ produziert hatte. So "richtig OOP" hab' ich erst mit Delphi nachgeholt und das war wohl Ausdruck meiner Schädigung durch Pascal .

[volkard]

pointercrash() schrieb:

und jeder potentielle AG fragte mich, wieviel 100k LOC ich schon in C++ produziert hatte.

Wer nach vielen LOC in C++ fragt, kann kein C++.

[tztztz]

volkard schrieb:

pointercrash() schrieb:

und jeder potentielle AG fragte mich, wieviel 100k LOC ich schon in C++ produziert hatte.

Wer nach vielen LOC in C++ fragt, kann kein C++.

Na das ist doch mal eine fundierte Aussage *tztztz

[mngbd]

pointercrash() schrieb:

Da hat mich ein früher Halloween- Kürbis an der Birne erwischt , gemeint war natürlich prozedural, wenn überhaupt.

Ich fand's mit funktional besser.

[Didaktiker5]

Hmm, also wenn man noch keinerlei Programmier-Vorkenntnisse hat, gibt es nur zwei wirklich hervorragende Bücher, die keinerlei Fragen mehr offen lassen, weil sie sehr ausführlich sind und bis ins letzte Detail gehen.
Zudem auch später immer wieder mal zum Nachschlagen geeignet:

Für C:

http://www.amazon.de/Das-Grundlagen-Buch-Gerhard-Willms/dp/3815812089

Für C++:

http://www.amazon.de/Das-Grundlagenbuch-Fundament-professioneller-Programmierung/dp/3815814375

Der Autor vollbringt in beiden Fällen eine didaktische Meisterleistung, indem er (wie es sich gehört!) jeweils mit den aller einfachsten Dingen / Bausteinen der jeweiligen Sprachen beginnt, und alles erklärt, worüber sich ein Programmier-Anfänger eventuell wundern könnte.
Wer sich die Zeit nimmt, diese Bücher gründlich zu studieren, hat auch keine Angst mehr vor Zeigern, Referenzen, Funktionszeigern, Speicherverwaltung usw. (so wie die C++ Experten des neueren Schlags), sondern beherrscht die jeweiligen Sprachen (und nicht umgekehrt!).
Bevor man in einer Sprache Romane verfassen kann, muss man erstmal deren Grammatik sowie einen soliden Grundwortschatz erlernen.
Man kann nicht sofort mit dem Romane schreiben anfangen (so wie es viele C++ Lehrbücher des modernen Schlags tun |-> Ich bleib dabei, so ein Vorgehen ist
didaktischer Unfug!)
Es bringt ja auch nichts, wenn ich der dreijährigen Tochter irgendeinen komplizierten Bildungsroman vorlese, davon lernt sie Deutsch ganz bestimmt nicht besser.

MFG

[Michael E.]

Didaktiker5 schrieb:

hat auch keine Angst mehr vor Zeigern, Referenzen, Funktionszeigern, Speicherverwaltung usw. (so wie die C++ Experten des neueren Schlags)

Na den Experten musst du mir noch zeigen, der Angst vor Referenzen hat.

Bevor man in einer Sprache Romane verfassen kann, muss man erstmal deren Grammatik sowie einen soliden Grundwortschatz erlernen.
Man kann nicht sofort mit dem Romane schreiben anfangen (so wie es viele C++ Lehrbücher des modernen Schlags tun |-> Ich bleib dabei, so ein Vorgehen ist
didaktischer Unfug!)
Es bringt ja auch nichts, wenn ich der dreijährigen Tochter irgendeinen komplizierten Bildungsroman vorlese, davon lernt sie Deutsch ganz bestimmt nicht besser.

Man sollte im ersten Schuljahr auch erst mal die Grundlagen wie Mengenlehre und Gruppentheorie lehren, bevor es an die Addition geht

[.lll]

Didaktiker5

[__--]

volkard schrieb:

pointercrash() schrieb:

und jeder potentielle AG fragte mich, wieviel 100k LOC ich schon in C++ produziert hatte.

Wer nach vielen LOC in C++ fragt, kann kein C++.

lass mal überlegen... 100000/(4000sloc/pm) ≈ 2 jahre berufserfahrung

[Gast]

~john schrieb:

Der absolute Tiefpunkt ist "gets", diese Funktion ist grundsätzlich so aufgebaut, daß die Verwendung in einem Programm unweigerlich zu einem Exploit führt. Wie man so einen Dreck überhaupt einmal in die ANSI Norm aufnehmen konnte, ist schleierhaft.

Und das soll jetzt ein Argument für/gegen C/C++ sein? Oder wolltest du dadurch einfach indirekt SeppJ widersprechen der sagt:

SeppJ schrieb:

Auch wenn der Name es verheißt, baut C++ nicht auf C auf.

Insgesamt ist es ziemlich lächerlich gets() als Argument zu verwenden.

~john schrieb:

Wenn es sich irgendwie vermeiden läßt C zu benutzen, sollte man dies auch tun.

Auweia. Immer diese totalen Aussagen. Kennst du mehr als deinen PC? Nein, ich brauche keine Antwort.

~john schrieb:

Hier im C Forum wird das natürlich grundsätzlich anders gesehen, davon sollte man sich nicht blenden lassen.

Ebenso sollte man sich nicht von den C++lern blenden lassen. Im übrigen schreit deine ganze Argumentation geradezu nach Java oder anderen Sprachen die dich so richtig schön an die Hand nehmen. Ich empfehle dem OP hiermit Java

[*john 0]

Tim schrieb:

Insgesamt ist es ziemlich lächerlich gets() als Argument zu verwenden.

Keineswegs, es ist ein Anzeichen der Sicherheitsunkultur die in C-Kreisen herrscht. gets() existierte schon vor der ANSI-Norm, wie konnte es also sein, daß dieser Dreck Einzug in die ANSI-Norm fand? Zu diesem Zeitpunkt hätte man schon wissen müssen, daß diese Funktion rotten by design ist.

Es wird fortlaufend gepfuscht. Das krasse Gegenbeispiel ist Ada, da gibt es eine Sicherheitskultur. Eine Sicherheitskultur macht zwar Fehler nicht unmöglich reduziert aber deren Auftreten deutlich.

Das nächste Negativbeispiel sind die ganzen IO-Funktionen von C, diese werden mit Formatstrings benutzt. Da C aber kein RTTI kennt, wird zur Laufzeit nicht überprüft, ob Formatstring und Parameter der Funktion überhaupt zusammenpassen. Der Notbehelf sind Compilezeitüberprüfungen, die aber nicht vollständig sind, und natürlich funktioniert dies nicht, wenn man während der Laufzeit die Formatstrings zusammen baut oder Zeiger statt Stringliterale nutzt.

Das absolut ägerlichste ist es, daß selbst in der ISO Norm es niemand für notwendig erachtet, das korrekte Einlesen eines Strings zu beschreiben.

Folgender Code ist direkt aus der ISO-Norm herauskopiert.

#include <stdio.h>
/* ... */
int n, i; float x; char name[50];
n = fscanf(stdin, "%d%f%s", &i, &x, name);

Das ist ein Exploit! Wie kann man so einen Mist in eine ISO-Norm schreiben?

Was ist denn so schwierig daran, den korrekten Umgang mit scanf & Co. zu lehren? Warum muß faktisch jeder Autor eines C-Lehrbuch es falsch machen? Warum gibt es darauf keine Antwort sondern die immer gleichen Sprechblasen mit Unsinn? Warum ist Pfusch unter C-Programmieren die Regel und nicht die Ausnahme? Wie soll mit einer solchen Unkultur des Pfuschs ein Anfänger jemals korrektes C lernen?

Es wäre schön, wenn es Hinweise auf Literatur gäbe, die C korrekt vermittelt, aber wahrscheinlich läuft es wieder nur darauf hinaus, daß die C-Programmierer hier aufschreien, weil man ihnen ihr Schäuffelchen weggenommen hat.

[nichtschluessig]

Ist doch totaler Schwachsinn. Das hat nix mit der Sprache zu tun und auch nicht jede Funktionerklärung muss über alles Sicherheitsaspekte aufklären.

Das Thema Sicherheit ist in jeder Sprache wichtig und für jede Sprache gibt es auch genug Exploits wenn bestimmte Standardfunktionen einfach genutzt werden ohne deren Parameter zu validieren. Du kannst in C genauso sicher programmieren wie in alle anderen Sprachen auch. C User haben wohl eher ein Sicherheitsbewusst entwickelt als ein PHP oder C++ Programmierer weil Leute wie du denen suggerieren bei Sprache X muss ich mich nicht so sehr um Sicherheit bemühen.

In einem gebe ich dir recht, Fachbücher egal für welche Sprache sollten auch auf das Thema Sicherheit nochmals gesondert eingehen bei den eigentlichen typischen Grundlagenthemen hat das aber nicht viel zu suchen, da der Programmieranfänger schon genug damit zu tun hat die Grundlagen zu lernen, Sicherheit sollte dann immer extra behandelt werden am besten als eigenes Buch denn ein Fachbuch was beides gut behandeln will wird sicherlich scheitern.

[Ausnahmeerscheinung]

~john schrieb:

gets() existierte schon vor der ANSI-Norm, wie konnte es also sein, daß dieser Dreck Einzug in die ANSI-Norm fand?

Ok, wo fängt man da an ...

(1) Mit gets() kann man sich sehr bequem Kommandos für einen Worker-Thread aus einer Message Queue, einer temporären Datei u.ä. pflücken, und das sogar ziemlich OS - unabhängig. Ich nehme an, Sie haben gets() bisher wohl nur als Lesefunktion für Konsoleneingaben kennengelernt, sonst würden Sie auch die Vorzüge von gets() kennen. Dazu nur soviel: Viele OS erlauben eine sog. Stream-Umleitung, gets() kann also auch mit Daten aus einer temporären Datei gefüttert werden.

(2) Man kann umgekehrt auch mit der sichersten Funktion der Welt unsicher programmieren, wenn man will.

(3) Arbeiten mehrere Leute an einem Projekt zusammen, dann haben sie idR nicht das Ziel, Funktionen eines Mitstreiters absichtlich mit fehlerhaften Parametern, zu kleinen Buffern oder sonstwie unter Missachtung der Sicherheitshinweise des Implementierers aufzurufen. Wenn es gar nicht vorgesehen oder gar unmöglich ist, dass eine derartige Funktion eines Tages von nicht-eingebundenen Dritten verwendet werden wird, sondern nur innerhalb des Teams, und zudem ihren Job hervorragend erfüllt, dann pfeift man eben auch auf die Sicherheitsbedenken (verständlicher Weise!) zu Gunsten eines optimierten Moduls. Niemand zwingt einen Programmierer dazu, seinen Quellcode zu öffnen und damit eventuelle Verwundbarkeiten oder Unsicherheitsfaktoren darin preiszugeben. Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.
Aber alle anderen, 'ehrlichen' Anwender des Programms (99%) interessieren diese internen (aber eben nur innerhalb des Entwickler-Teams tolerierten) Sicherheitsbedenken ohnehin nicht, dafür können sie die Gewissheit haben, dass ihre Copy der Anwendung auch auf ihrem Uralt-Rechner noch das Maximum rausholt und sich nicht mit performance-technisch überflüssigen Doppel- und Dreifachprüfungen irgendwelcher Zeiger und Rückgabewerte beschäftigt, weil nämlich alle Entwickler des Teams an einem Strang gezogen haben und sie in eine Funktion niemals boshafter Weise eine 10 reinstecken, wenn nur 16 oder 32 erlaubt ist.
Alles klar?
--> Es krankt bei den modernen OOP-Entwicklern generell daran, dass sie den potentiellen Nutzern ihrer Monsterobjekte mit Misstrauen begegnen, was aber selbstverständlich unangebracht ist, wenn man man im Team arbeitet, jeden Beteiligten kennt, man sich aufeinander verlassen kann, da fällt es dann auch leichter diese Sicherheitsprobleme zu tolerieren, weil ja von der Source ohnehin niemals geplant ist, dass sie je open oder gar public wird.
Ein Hoch auf Closed Source

MFG

[Michael E.]

Ausnahmeerscheinung schrieb:

Ist das Ding erst mal kompiliert, wird es ohnehin schwierig und aufwendig genug, derartige Sicherheitslücken (per Disassembly o.ä.) auszunutzen. Diejenigen, die sich diese Mühe antun, wird man auch trotz Super-Sicherster Programmierung nicht davon abbringen können, irgendwelche Verwundbarkeiten aufzuspüren und in boshafter Weise auszunutzen.

WTF? Wir können Programme nicht zu 100% sicher machen, also können wir es auch gleich sein lassen?

[ITPolizei]

Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.

[Michael E.]

ITPolizei schrieb:

Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.

Dann sollten wir es auch gar nicht mehr versuchen

[volkard]

ITPolizei schrieb:

Bis heute hat es kein Mensch geschafft sichere Software zu schreiben, also haltet den Ball flach. Es gibt auch hier keinen der das auch nur annähert könnte sonst wäre der schon durch die Presse gegangen.

Ich schreibe nur sichere Software. Warum sollte der Normalzustand durch die Presse gehen?

[ITPolizei]

Schon klar, na dann fang mal bei den BigPlayern an wie Apple, MS, Oracle oder Adobe. Denn die haben es bis jetzt noch nicht geschafft sichere Software zu schreiben. Du wärst also der erste Mensch der sichere Software schreiben kann.
Ich glaube als Politiker würdest du auch sagen dass du immer die Wahrheit erzählst

An den Poster davor, klar sollte weiter versucht werden an die Software sicherer zu machen. Da die IT-Branche aber noch sehr jung ist kann man das eher mit Architekten vergleichen die aus ein paar Palmenblätter Behausungen bauen können, aber erzählen ein Wolkenkratzer wäre kein Problem.

In 50 Jahren werden die Menschen zurückblicken und darüber lachen das sich einige aus der heutigen Zeit als Softwarearchitekten bezeichnet haben.

Softwareentwicklung ist doch im Vergleich zu andere Branchen ein gigantisches Rumgepfusche.

[Nobelpreiser]

Mir ist auch noch nicht bekannt dass es auch nur einen Menschen gibt der weiß wie man wirtschaftlich sichere Software schreibt. Wenn es den mal gibt bekommt der bestimmt den Nobelpreis

Wir fassen zusammen: Es gibt keinen der weiß wie man richtig Software entwickelt, aber die meisten lassen sich als Softwareentwickler einstellen. Ist schon geil, zum Glück gibt es das nicht in der Form in anderen Branchen.