Besserer Programmierer Werden (C)

Ja,
was solls nun werden, entweder C auf µC dann ist das das richtige Forum 
oder PC-Programmierung dann sollte man das auch dahin verschieben ?
Egal was es werden soll erstmal ein gutes Buch zur Programmiersprache 
kaufen.
Heute ist es sinnvoller gleich mit C++ anzufangen, vor allem wenn's auch 
PC werden soll und mit grafischer Oberfläche.
Da würde ich QT und passendsen C++ Compiler/IDE nehmen.
Bei µC kommt es auf den Käfer an und welche Compiler da zur Verfügung 
stehen.
Übung macht den Meister und da kannst Du einfach mal im Netz nach 
Tutorials suchen, entweder für Deinen µC oder für C++ und QT.
C++ ist bereits sehr mächtig nd mit QT steht Dir eine guten 
Klassenbibliothek plattformübergreifend zur Verfügung, d.h. Deine 
Programme laufen auf Windows wie auf Un*x/X11 ohne das Du im Programm 
selber was ändern mußt.
Nimm Dir ordentlich Zeit und versuche zu verstehen was Vererbung ist, 
wie Templates funktionieren und welche Standardbibliotheken Dir Dein 
Leben einfacher machen.

All das lernt man nicht durch Lesen eines Buches oder Abarbeiten von ein 
paar Aufgaben. Du wächst mit den Aufgaben, sammelst Erfahrungen und 
wirst dabei immer besser, wenn du deinen Job gut machst.

Die besten Programmierer findest du kaum unter 16 Jährigen, sondern eher 
unter den Opas.

C-Programmer schrieb:
> ich habe bereits angefangen C zu lernen und würde gerne Übungen haben um
> mit der Zeit immer besser zu werden,
> hat da jemand von euch Tipps?

Ja.

Lade dir Freepascal und Lazarus herunter und lerne damit (in der 
Programmiersprache Pascal) vernünftiges Programmieren.

Programmieren zu erlernen heißt nämlich NICHT, auf irgend eine 
Programmiersprache gedrillt zu werden wie zum Beispiel C.

Jaja, du hast ja explizit nach Übung in C nachgefragt, aber das kommt 
später. Zu allererst steht was ganz anderes auf dem Programm, nämlich 
Verständnis für das Denken in sinnvollen Algorithmen erlernen, sich 
einen sauberen, biederen und lesbaren Stil anzugewöhnen und Verständnis 
für die Dinge zu erlangen.

Das ist was GANZ ANDERES als einfach nur auf C "getrimmt" zu werden.
C ist von hause aus eine nicht wirklich logische Programmiersprache, 
sondern eher eine diktatorisch angelegte Sprache. Immer nach dem Motto 
"das ist hier eben so, basta! lerne das auswendig oder stirb". Bevor du 
also in C einsteigst, solltest du soviel an geistigem Horizont haben, um 
über den C-internen Befindlichkeiten zu stehen, sonst wirst du 
unversehens zum "Codeaffen", also zu jemandem, dessen Horizont sich nur 
auf C beschränkt. Und dagegen hilft eben nur zuvoriges Können woanders 
zu erlangen. Immer mal an Adenauer denken:
http://www.zitate-online.de/sprueche/politiker/144/wir-leben-alle-unter-dem-gleichen-himmel.html

Und nochwas zu C++, das ist ein aufgebohrtes und verschlimmbessertes C, 
wo man noch mehr implizite Seiteneffekte hat als in C. Deswegen ist es 
bei der Mikrocontroller-Programmierung auch weitestgehend außen vor. Es 
gibt hier zwar ein paar Hanseln, die verzweifelt versuchen, µC mittels 
C++ programieren zu wollen, aber deren verzweifelte Suche nach wirklich 
sinnvoller Anwendung von C++ auf'm µC war bislang nur wenig erfolgreich.

W.S.

Christopher J. schrieb:
> wassollswerden schrieb:
>> Heute ist es sinnvoller gleich mit C++ anzufangen, vor allem wenn's auch
>> PC werden soll und mit grafischer Oberfläche.
>> Da würde ich QT und passendsen C++ Compiler/IDE nehmen.
>> Bei µC kommt es auf den Käfer an und welche Compiler da zur Verfügung
>> stehen.
>
> Dann lernt er aber vor allem mit QT umzugehen und wenn überhaupt lernt
> er was über C++, er möchte aber C lernen und das ist auch gut so, denn
>

C ist ein Subset von C++, also wenn er schon lernen will dann erstmal OO 
und C++, da lernt er automatisch C mit.
Oder wie werden z.B. getter und setter implementiert ?
QT habe ich angeführt weil er ja nicht auf µC beschränkt sein will, so 
wie ich das verstanden habe.


> C-Programmer schrieb:
>> Ich meine jedoch keine Programmierung con Mikrocontrollern,
>> da ich bisher nur Mathematische Programme geschrieben habe.
>> In Zukunft möchte ich das aber auch machen.
>
> Wenn dir Mathe taugt, dann mach doch was mit digitalen Filtern. Da gibt
> es gerade im Embedded Bereich unzählige Anwendungen und du kannst deine
> Erfahrungen später gut gebrauchen. Für den PC könntest du zum Beispiel
> etwas mit OpenCV machen. Versuch eben mal eigene Filter zu
> implementiern. Da gibt es auch eine C-API. Von C++ würde ich unbedingt
> abraten, besonders im Bereich uC.

Da sind wir wieder bei meiner Anfangsfrage, was solls sein ?
Man könnte jetzt noch Mathlab anführen oder sonstwas.
Solange der TO nicht selber weiß was er nun genau lernen will und warum 
ist das Glaskugel polieren.
OO bietet wesentlich mehr als reines C oder PASCAL oder BASIC.
Und lernen tut man idR aus eigenen Fehlern beim Debugging ...

Hi

>Lade dir Freepascal und Lazarus herunter und lerne damit (in der
>Programmiersprache Pascal) vernünftiges Programmieren.

Ich komme aus der Delphi Ecke (D6 prof.). Und da empfinde ich Lazerus 
maximal als schwachen Ersatz.

MfG Spess

C-Programmer schrieb:
> ich habe bereits angefangen C zu lernen und würde gerne Übungen haben um
> mit der Zeit immer besser zu werden,
> hat da jemand von euch Tipps?

Dieses Buch könnte evtl. für Dich etwas sein, wenn Du schon ein wenig 
programmiert hast:

http://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675/

Christian B. schrieb:
> Also um C gut zu können musst Du erst mal Assembler können. Wenn Du mal
> ein mittleres Projekt in einem Assembler umgesetzt hast, so hast Du das
> Rüstzeug zu verstehen was Dein C Programm überhaupt macht

Was für ein Unsinn.
Assembler lesen und verstehen ja, aber schreiben? Du schnitzt deine 
Zahnstocher auch selbst?

Gruß
Jan

Hi

>Assembler lesen und verstehen ja,...

Assembler versteht man erst, wenn man selbst programmiert hat. Also 
maximal kannst du es lesen.

MfG Spess

> Von C++ würde ich unbedingt abraten, besonders im Bereich uC.
nicht nur im uC Bereich, auch im PC Bereich kannst Du auf C++ 
verzichten, solange Du es nur privat als Hobby betreiben willst.
Die fehlende Grafikkomponente von C kannst Du mit GTK+ abdecken - da 
mußt Du aber schon sehr gut sein ... und deshalb hat sich ja C++ 
durchgesetzt.
Als Einstiegsbuch fand ich C für PCs von Kirch Prinz ganz gut.
Assembler kann auch nicht schaden, war eine zeitlang als Inline Routinen 
in vielen C und Pascal Programmen Usus.

> C ist ein Subset von C++, also wenn er schon lernen will dann erstmal OO
> und C++, da lernt er automatisch C mit.
Ein guter C Programmierer wird niemals ein guter C++ Programmierer sein 
und umgekehrt auch nicht - besser eine Sprache und die dann gründlich 
als Mischmasch.
Oder als Alternative gleich mit Java anfangen - das ist dann wenigstens 
plattformunabhängig.

Ich denke, man sollte immer Programme anderer lesen und versuchen 
herauszufinden, was einem das Verständnis erschwert oder erleichtert. Es 
hilft ungemein die eigenen Programme anderen zu lesen zu geben. Dabei 
ist natürlich gegenseitiger professioneller und menschlicher Respekt 
notwendig.

In diesem Forum mangelt es daran leider häufig.

Wenn Dich mathematische und numerische Algorithmen interessieren, dann 
habe ich zwei Buchempfehlungen für Dich. Diese Bücher erklären die 
Algorithmen im Fließtext und die Programme sind meist spärlich 
dokumentiert.

Für einen professionellen Entwickler (allein oder auch im Team) kann das 
meiner Meinung nach aber nicht die Richtschnur sein. Wir schreiben ja 
nicht nur Algorithmen ab, die man überall nachlesen kann, sondern 
schaffen etwas Neues. Dieses "Neue" muß in Kommentaren, zusätzlichen 
Dokumenten und Tests dokumentiert sein und es ist immer wieder verdammt 
schwierig, den richtigen Mix zu finden.

Hier meine Empfehlungen:
1) Numerical Recipes in C (oder C++, Fortran...)
2) Introduction to Algorithms, Cormen, Leiserson

Gruß
Georg

quergelesen schrieb:
>> Von C++ würde ich unbedingt abraten, besonders im Bereich uC.
> nicht nur im uC Bereich, auch im PC Bereich kannst Du auf C++
> verzichten, solange Du es nur privat als Hobby betreiben willst.

Warum auf etwas verzichten, dass nur Vorteile bringt? C++ hat gegenüber 
C nur Vorteile. Man muss die Sachen, die in C++ dazukommen nicht nutzen. 
Man kann es sogar mit C-Code mischen.

> Die fehlende Grafikkomponente von C kannst Du mit GTK+ abdecken - da
> mußt Du aber schon sehr gut sein ... und deshalb hat sich ja C++
> durchgesetzt.

Genau. Das endet dann in OOP in C. Das mag für kleinere Sachen machbar 
sein. Aber im Vergleich zu C++ ist es einfach ein Aufwand der nicht sein 
muss. Und spätestens wenn man virtuelle Funktionen und ähnliches 
braucht, nimmt der C++ Compiler einem eine Menge ab. Aber manche mögen 
es ja, wenn sie beim Programmieren dauernd gegängelt werden.

>> C ist ein Subset von C++, also wenn er schon lernen will dann erstmal OO
>> und C++, da lernt er automatisch C mit.
> Ein guter C Programmierer wird niemals ein guter C++ Programmierer sein
> und umgekehrt auch nicht - besser eine Sprache und die dann gründlich
> als Mischmasch.

Das ist Käse. Wer gut C++ programmiert und damit auch die vielen 
Paradigmen verstanden hat, der programmiert auch gut C, weil eben C ein 
Subset der Paradigmen von C++ ist.

> Oder als Alternative gleich mit Java anfangen - das ist dann wenigstens
> plattformunabhängig.

Damit lernt man ganz bestimmt nicht C. Denn Java ist eigentlich nur 
Objektorientiert. Und mit Java lässt man sich übrigens wieder als 
Programmierer gängeln (z.B. fehlende Operatorüberladung und unchecked 
Exceptions). C# im Vergleich zu Java bietet deutlich mehr Möglichkeiten.

Bei so einer Frage gibt es genauso viele Antworten wie Meinungen. Da der 
Frager nicht wieder geantwortet hat, kann man davon ausgehen, daß es nur 
ums Lostreten dieser Meinungslawine ging.

Warum fragt sich eigentlich keiner der Antwortenden, warum er so scharf 
darauf ist, unbedingt seine Meinung zum besten zu geben und nicht die 
Finger still zu halten?

So allgemein die Frage ist, kann doch die Antwort nicht sein: "lerne 
C++", "QT", "C#". Da muß man doch allgemein antworten: "Wie wird der 
Kock besser, der Fliesenleger, der Elektroniker, wie wird überhaupt 
irgendetwas besser? Durch üben üben üben oder machen machen machen."

Also, Herr "C-Programmer (Gast)", schreibe weiter mit großem Fleiß und 
Wißbegier Mathematische Programme und stecke Dir hohe Ziele. Über die 
Monate und Jahre wirst Du automatisch besser.

Für Hardwarenahme Programmierung ist Java allerdings denkbar schlecht 
geeignet. Es unterstützt weder Bluetooth, noch serielle Schnittstellen 
und schon gar keine GPIO Ports.

Jedenfalls nicht, ohne C Libraries einzubinden.

Zum Erlernen strukturierter Programmierung spricht allerdings meiner 
Meinung nach nichts gegen Java. Für uns Elektroniker ist es gut, beide 
Sprachen zu können. Und ganz ehrlich: Wer C und Java kann, für ist C++ 
nur noch ein kleiner Schritt. Nämlich das Auswendig Lernen der wenigen 
Unterschiede zwischen Java und C++.

Dieses Javagedöns überbrückt eine fehlende Verbindung zu Smartphone und 
Co.
Dafür ist es wunderbar.

Java allein hat auf dem PC nichts zu suchen und ist eine Bremse...

-----------------------------
ich habe bereits angefangen C zu lernen und würde gerne Übungen haben um
mit der Zeit immer besser zu werden,
-----------------------------

Mach dein reines  "c", es gibt mit Google viele deutsche Übungen und 
Beschreibungen und auch buchähnliche Lektüre.

Stefan U. schrieb:
> Nämlich das Auswendig Lernen der wenigen
> Unterschiede zwischen Java und C++.

Die Unterschiede zwischen Java und C++ sind gewaltig. C++ ist um einiges 
mächtiger. Der Satz gilt eher für die Richtung C++ -> Java.

Ein besserer Programmierer zu werden, bedeutet nicht, die 
Sprachkonstrukte einer Programmiersprache zu kennen, sondern sie auch 
möglichst sinnvoll anwenden zu können.

Wichtig ist strukturiertes Denkvermögen, die Fähigkeit zu abstrahieren 
und sich ähnelnde, wiederkehrende Muster erkennen zu können.

Mir ist schon viel Code untergekommen, und der meiste Anteil davon 
fokussiert sich auf das Wie anstatt auf das Was. Solcher Code ist oft 
schwer zu verstehen, da er die eigendliche Problemstellung (das Was) in 
hochdetaillierten Anweisungen versteckt: dem Wie. Was in solchen Code 
abgeht, ist dann nicht mehr einfach zu erkennen und für die Tonne.

Die Programmiersprache zu beherrschen, steht nur ganz am Anfang.
Mach Dich mal schlau bzgl. der Begriffe
- Sofware Design
- Event Driven Design
- Domain Driven Design
- Message Passing
- Objektorientiertes Design
- Design Patterns
- Strukturierte Programmierung
- Modularisierung
- Schichtenarchitektur
- EVA-Prinzip
- Separation of Concerns
- Information Hiding
- Kohäsion
- Inversion of Control
- Dependency Inversion
- Dependency Injection
- Testbarkeit
...

Man was für ein Theater,

das ziehe ich mir ein zwei  Wochen rein und dann bin ich sicher im 
oberen Viertel der Besten angelangt.

Genauso läuft das hier im E-Technik Studium.
Nur das ich 95% davon getrost vergessen kann, weil nie wieder jemand 
danach fragen wird.

Ferkel

Nein ich komme aus Essen und die Sau lass ich erst raus wenn ich mit dem 
Studium hier fertig bin.
Das dauert nur noch ein halbes Jahr und dann lasse ich wirklich die Sau 
raus, von mir aus auch in Berlin.

Denn danach gibt's noch ein WI Studium als Aufbau.
Mit E-Technik allein werde ich zukünftig meine Kohle wohl nicht 
scheffeln obgleich ich es wohl könnte.

"Ferkel" ist mein Spitzname ;-ö)

U. M. schrieb:
> auch wenn du das nicht hören willst, aber eine fundierte theoretische
> Ausbildung ist für gute Ing. kaum verzichtbar.

Genau, reinziehen und vergessen.
Nur gut das ich dazu offenbar ein gewisses Talent habe.
Ich kann auch Telefonbücher auswendig lernen...

Die das nicht können fallen durch das Sieb.
Ok, ein paar Konkurrenten weniger schaden mir nicht.

Ich denke ich habe verstanden wie die Jobwelt funktioniert.
C, Java Assembler nd Konsorten können mich dann mal.

Aachener schrieb:
> Genauso läuft das hier im E-Technik Studium.
> Nur das ich 95% davon getrost vergessen kann, weil nie wieder jemand
> danach fragen wird.
Weil Du halt E-Techniker und deshalb Dein Leben lang höchstens 
Trivialprogramme entwerfen wirst.
Software-Entwickler aber werden um diese Paradigmen und Konzepte nicht 
herumkommen, da sie ansonsten auch nur Stümperprogramme entwerfen 
werden.

Markus schrieb:

> Die Programmiersprache zu beherrschen, steht nur ganz am Anfang.
> Mach Dich mal schlau bzgl. der Begriffe
> - Sofware Design
> - Event Driven Design
> - Domain Driven Design
> - Message Passing
> - Objektorientiertes Design
> - Design Patterns
> - Strukturierte Programmierung
> - Modularisierung
> - Schichtenarchitektur
> - EVA-Prinzip
> - Separation of Concerns
> - Information Hiding
> - Kohäsion
> - Inversion of Control
> - Dependency Inversion
> - Dependency Injection
> - Testbarkeit

Frag mal Linus wieviel von den üben genannten Konzeptent er bei der 
Entwickelung des Linux-Kernels beachtet und umgesetzt hat. 
Wahrscheinlich nur wenige. Aber er kannte die Prozessorinternals sehr 
gut und hat in x386 Assembler einen Task scheduler stabil ans laufen 
gebracht. Der Rest war Hartnäckigkeit und Compiler Detailkenntnisse bei 
der Anüassung der historischen Minix-Sourcen.

MfG,

Fpga K. schrieb:
> Frag mal Linus wieviel von den üben genannten Konzeptent er bei der
> Entwickelung des Linux-Kernels beachtet und umgesetzt hat.
> Wahrscheinlich nur wenige. Aber er kannte die Prozessorinternals sehr
> gut und hat in x386 Assembler einen Task scheduler stabil ans laufen
> gebracht. Der Rest war Hartnäckigkeit und Compiler Detailkenntnisse bei
> der Anüassung der historischen Minix-Sourcen.

Na vermutlich alle.

Bloß weil Linus mal mal angefangen hat, eine Terminal Emulation zu 
hacken, heißt das nicht, dass der Kernel in der heutigen Form 
Exisitieren könnte, wenn er nicht die meisten Konzepte umgesetzt hätte.

nicht"Gast" schrieb:
> Fpga K. schrieb:
>> Frag mal Linus wieviel von den üben genannten Konzeptent er bei der
>> Entwickelung des Linux-Kernels beachtet und umgesetzt hat.
>> Wahrscheinlich nur wenige. Aber er kannte die Prozessorinternals sehr
>> gut und hat in x386 Assembler einen Task scheduler stabil ans laufen
>> gebracht. Der Rest war Hartnäckigkeit und Compiler Detailkenntnisse bei
>> der Anüassung der historischen Minix-Sourcen.
>
> Na vermutlich alle.

Nö Linus ist Erfahrungsreicher C++ - Hasser:
http://harmful.cat-v.org/software/c++/linus

Zitat:
"In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID 
IDEA."

...
 "- any compiler or language that likes to hide things like memory
   allocations behind your back just isn't a good choice for a kernel. "

Durchstapler schrieb:
> Nö Linus ist Erfahrungsreicher C++ - Hasser:
> http://harmful.cat-v.org/software/c++/linus

Das weiß ich. Zum Glück stand C++ ja auch nicht in der Liste. 
objektorientiertes Design gibts aber auch im Linux Source Code^^.

Das wird da nur etwas anders gehandhabt. Es werden structs benutzt, 
welche die Informationen halten und als Parameter an die Funktionen 
übergeben werden.

Leute,

Darf ich dran erinnern, dass das hier kein C++ ist Kacke Thread ist. Es 
geht nicht mal um C++. Es geht um C

Könnt ihr euch vielleicht in einen anderen Thread auskotzen?

spess53 schrieb:
> Ich komme aus der Delphi Ecke (D6 prof.). Und da empfinde ich Lazerus
> maximal als schwachen Ersatz.

Rainer V. schrieb:
> Ob Freepascal für den TE optimal ist?

Ach ihr beiden... Was soll unsereiner denn sonst empfehlen? Ja, Delphi6 
ohne Datenbank-Lib wurde mal als Freeware-CD in diverse Zeitungen 
getackert - und D6 ist bis heute immer noch gut.

Aber ein aktuelles Embarcadero-Delphi jemandem anraten? Die 
Einstiegs-Version für ca. 300€ etwa? Ich könnte jemandem zwar meine 
steinalte Heft-CD mit dem kostenlosen D6 geben, aber wie dann weiter?

Nee, angesichts der Preispolitik von Embarcadero sehe ich Lazarus als 
einzige sinnvolle Lösung für jemanden, der erstmal irgendwie einsteigen 
will. Zumindest kann man damit das ordentliche Programmieren lernen und 
man kann damit auch verstehen, wie echte Hochsprachen funktionieren. 
Damit kann an anschließend einiges an Gedöns bei C richtig einordnen, 
kurzum: siehe Adenauer. Ich hab das weiter oben nicht ohne Grund 
angesprochen.

-----------------------

Ach, helau oder so: die 5. Jahreszeit ist vorbei!
Aachener schrieb:
> Ich denke ich habe verstanden wie die Jobwelt funktioniert.

So? hast du? Nun ja, es ist ja nicht nur so, daß die Absolventen immer 
älter werden, nein..auch diejenigen, die im Leben auf die Nase fallen, 
werden immer älter, weil das AufDieNaseFallen später erfolgt. Das hat 
dann im Endeffekt ein verkorkstes Leben zur Folge, weil das Fallen dann 
eben heftiger ist.

Nochmal helau und willkommen im eher gemütlichen Teil nach dem Erledigen 
des Thread-Themas.

W.S.

Christopher J. schrieb:
> Durchstapler schrieb:

>> Fpga K. schrieb:
>>> Frag mal Linus wieviel von den üben genannten Konzeptent er bei der
>>> Entwickelung des Linux-Kernels beachtet und umgesetzt hat.
>>> Wahrscheinlich nur wenige. Aber er kannte die Prozessorinternals sehr
>>> gut und hat in x386 Assembler einen Task scheduler stabil ans laufen
>>> gebracht. Der Rest war Hartnäckigkeit und Compiler Detailkenntnisse bei
>>> der Anüassung der historischen Minix-Sourcen.
>>
>> Na vermutlich alle.
>
> Ein paar davon ganz sicher, z.B.
>
>> - Strukturierte Programmierung
>> - Modularisierung
>> - Schichtenarchitektur
>> - EVA-Prinzip
>
> Das gab es aber auch alles schon bei UNIX, also seit Urzeiten.
>
> Er hat sich aber bestimmt nicht von irgendeinem, mit Buzzwords um sich
> werfenden "Consultant", erklären lassen was "Separation of Concerns" ist
> bevor er mit der Kernelprogrammierung angefangen hat. Dazu passt dann
> wieder Stroustrups "I did it for you all".

Ja sehe ich ähnlich, die 4 oben genannten sind keine Konzepte für deren 
Beherrschung man eine Akademie besuchen muß sondern erschliessen von 
sich selbst bei der Programmierung. Wobei es nicht mal "Programmierung" 
sein muß, Modularisierung und Schichtenarchitektur ergeben sich schon 
bei Häuslichen Tätigkeiten wie Koffer packen oder Brot schmieren. 
Strukturierte Problemlösung eben.

MfG,

Fpga K. schrieb:
> Ja sehe ich ähnlich, die 4 oben genannten sind keine Konzepte für deren
> Beherrschung man eine Akademie besuchen muß sondern erschliessen von
> sich selbst bei der Programmierung.
Bis der eine oder andere Anfänger von selbst drauf kommt, kann das 
dauern, je nachdem wie fleißig und schlau er ist. Für die fleißigen und 
schlaueren Anfänger sind Hinweise auf solche Paradigmen/Konzepte m.E. 
extrem hilfreich.

Manch andere interessiert das aber alles gar nicht. Die verstehen 
derartige Konzepte nicht. Die programmieren seit Jahrzehnten immer den 
selben Stuß.
Habe regelmäßig mit solchen Gesellen zu tun. Die können einen mehr als 
einen Tag versauen. Ich frag mich, wie die sonst im Leben mit 
Formalismen zurecht kommen, z.B. mit Mikrowelle, Waschmaschine, 
Videorekorder, Steuererklärung..