Hi leute, 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? Ich meine jedoch keine Programmierung con Mikrocontrollern, da ich bisher nur Mathematische Programme geschrieben habe. In Zukunft möchte ich das aber auch machen. Vielen Dank im Vorraus für eure Antworten!
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.
Hallo, die geringere Teil beim Programmieren hat mit der Kenntnis der Programmiersprache zu tun. Jeder gute Programmierer kann sich eine gängige Programmiersprache in paar Wochen zu eigen machen. Eine ganz andere Sache sind: - Kenntnis der Mathematik allg. und besonders der numerischen Mathematik Fähigkeiten zur Modellierung von Probleme mit Methoden der num. Mathematik. - Kenntnis zu Programmierverfahren und Programmstrukturen und Betriebssystemen. - Aneignung eines guten Stils und einer gewissen Ordnung und Disziplin beim Progr. und der Notation der Quelltexte. - Kenntnis zu Dokumentation von Programmen und Disziplin, um das auch tatsächlich sauber umzusetzen. - Kenntnis von Normen und Standard in der Programmierung, wie Datenformate, Übertragungsformate, Konvertierungen usw. - Kenntnis zu Problemen der Datensicherheit, Datenrekonstruktion sowie redundate Datenspeicherung und Datenprüfung. - Kenntnis zu Netzwerkstrukturen und Datenübertragung - Kenntnis zu Probleme der Ergonomie von Bedienoberflächen und Anzeigen. - Spezielle Kenntnisse zum jeweiligen Anwendungsbereich, besonders bei uC-Programmierung spielt der jeweilige Anwendungsbereich mit speziellen Gesetzgebungen und speziellen Standards und Mindestanforderungen an Geräte und Systeme eine Rolle (Beipiel: NAMUR-Richtlinien). - zumnindest Grundkenntnisse zu Probleme der EMV (besonders bei embedded Prog.) Das und noch einiges mehr führt dazu, dass du richtig gut wirst. Wieviel Ausbildung dazu hast du schon hinter dir? Gruß Öletronika
:
Bearbeitet durch User
http://www.amazon.de/Linux-Treiber-entwickeln-systematische-Ger%C3%A4tetreiber--Kernelprogrammierung/dp/3864902886/ref=sr_1_1?ie=UTF8&qid=1457807181&sr=8-1&keywords=Linux+treiber Da kannst du C programmieren, und erarbeitest dir gleich noch Kenntnisse über Treiber, Linux, make, gcc und kannst das ganze am Raspberry Pi üben.
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-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.
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.
Kaj G. schrieb: > http://www.amazon.de/Linux-Treiber-entwickeln-systematische-Ger%C3%A4tetreiber--Kernelprogrammierung/dp/3864902886/ref=sr_1_1?ie=UTF8&qid=1457807181&sr=8-1&keywords=Linux+treiber > > Da kannst du C programmieren, und erarbeitest dir gleich noch Kenntnisse > über Treiber, Linux, make, gcc und kannst das ganze am Raspberry Pi > üben. Da kann ich auch noch unbedingt das Buch "Embedded Linux lernen mit dem Raspberry Pi: Linux-Systeme selber bauen und programmieren" vom gleichen Autor empfehlen. Wirklich sehr verständlich und gut strukturiert vom Makefile bis zum eigenen Kernel.
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 ...
Ich habe vor etwa einem Jahr mit C und einem µC angefangen, davor hatte ich nur mit MatLab programmiert. Danach mit C und der WinApi (VisualStudio) weitergemacht. Nach etwa einem halben bis 3/4-Jahr bin ich dann auf C++ umgestiegen (Windows MFC und µC). Was mir sehr geholfen hat, war die Programmierung des µCs. Hier lernt man am Besten mit Zeigern und Speicheradressen umzugehen, da sie hier einfach benötigt werden. Wenn du irgendwelche Windows-Programme programmierst, benötigst du das Wissen hierzu grundsätzlich erstmal nicht. Allerdings tauchen dann immer wieder kleinere Probleme auf, die du dann googlen musst. Hätte ich das Wissen um Zeiger und Speicheradressen schon gehabt, bevor ich mit der Windows-API angefangen hatte, wäre mir viel Zeit erspart geblieben, die ich ins Googlen investieren musste.
Ich kann Dir folgendes Buch empfehlen: http://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken/dp/3826655486
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/
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. Wenn Du Dir dann noch Artikel wie "Smashing the Stack for Fun and Profit" durchliest, verstehst Du langsam, was C überhaupt macht, sprich zu welchen Code Dein Programm umgesetzt wird. Wenn Du so weit bist verstehst Du zumindest C. Das ist schon mal ein wichtiger Punkt. Dann ließ Dir das Buch "The Art of UNIX Programming" durch (gratis online verfügbar). Da erklärt jemand der es kann, wie man große und kleine Softwareprojekte strukturieren kann. "The Art of Computer Programming" von Donald Knuth ist auch eine schöne Zusammenfassung über Algorithmen und so. Das Buch ist noch unvollendet, sollte aber noch in dieser Hälfte unseres Jahrhunderts erscheinen. Falls Du den Gedanken hast, C++ könnte interessant sein, besorg Dir "The C++ Programming Language" vom Stroustrup und schlage die Dir so oft gegen den Kopf, bis es Dir besser geht.
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
Learn C The Hard Way ist schon mal ein guter Weg mit der Programmiersprache C sehr vertraut zu werden: http://c.learncodethehardway.org/book/index.html
Christian B. schrieb: > Falls Du den Gedanken hast, C++ könnte interessant sein, besorg Dir "The > C++ Programming Language" vom Stroustrup und schlage die Dir so oft > gegen den Kopf, bis es Dir besser geht. Ohne den Inhalt dieser Aussage zu beurteilen, es war sehr lustig und schön zu lesen.
W.S. schrieb:
> Freepascal und Lazarus
Ob Freepascal für den TE optimal ist? Habe selbst mit TPascal unter DOS
bis Win98 gearbeitet, bin später vom Umstieg auf FPC wieder abgekommen.
Die FPC-IDE hatte schwere Mängel, es gab Probleme beim Speichern/Laden
von Pfaden oder der Konfiguration allgemein, auch Quelltexte gingen ab
und zu verloren. Speichern von Pfaden klappte dann irgendwann durch
kompliziertes Prozedere in bestimmter Reihenfolge. Dokumentationen
online u. als Hilfe-Dateien zu FPC und Lazarus waren auch nicht so toll.
Vorwissen u. alte TPascal-Bücher haben mir sehr geholfen. Wie Neulinge
mit FPC oder Lazarus ohne die teuren Bücher anfangen sollen, ist mir
schleierhaft. Na ja, vllt. hat sich da einiges gebessert und die IDEs
sind immerhin kostenlos.
> 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.
Jan schrieb: > Assembler lesen und verstehen ja, aber schreiben? Du schnitzt deine > Zahnstocher auch selbst? Der beste Weg etwas zu verstehen ist es selbst zu machen. Und bei vielen kleinen Projekten ist es oft sogar weniger Arbeit das schnell mal in Assembler zu machen als eine C Entwicklungsumgebung zu installieren. Es gibt sogar Sachen die generell einfacher sind in Assembler als in C zu machen. Ein typisches Beispiel sind lange Integer. Mal 2 1024 Bit Integer zu addieren ist in Assembler trivial, in C wirklich schwierig.
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.
avr schrieb: > 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. In der Praxis funktioniert das nicht. In der Praxis laufen C++ Projekte so ab, dass jeder Entwickler von einem neuen Sprachfeature hört, und es dann an seinem Codestück ausprobiert. Das Ergebnis ist, dass nach ein paar Jahren jedes Codestück andere Sprachfeatures braucht, was dazu führt, dass jeder Entwickler im Team alle Sprachfeatures kennen muss. Effektiv hast Du dann ein Team das 50% der Zeit damit verbringt neue Features zu lernen, 40% damit den alten schrottigen Code zu debuggen und ggf. mit dem neuesten Schrei neu zu entwickeln, und vielleicht 10% der Zeit wirklich produktiv verbringen.
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
Hallo, > Aachener schrieb: > Nur das ich 95% davon getrost vergessen kann, weil nie wieder jemand > danach fragen wird. auch wenn du das nicht hören willst, aber eine fundierte theoretische Ausbildung ist für gute Ing. kaum verzichtbar. Da ist freilich viel bei, was man später tatsächlich nie mehr aktiv benötigt, aber alleine die Tatsache, das man weiß, was es alles so gibt und wofür das alles gut ist, macht schon mal den wesentlichen Unterschied zwischen Ing. und normalen Praktikern (Facharbeiter, Meister usw.). Allerdings sehe ich auch immer wieder das Problem, das Studenten zwar unheimlich viel gelernt haben, aber rein gar keine Ahnung davon haben, wa sie damit in der Praxis anfangen sollen. Aber das kommt noch. In 10 Jahren wirst du auch darüber staunen, wie naiv und unwissen man als Student und auch als Absolvent mal war. Gruß Öletronika
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 > > 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." Den Link wollte ich eigentlich auch schon einwerfen ;) Auch von der selben Seite: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all Da bleiben keine Fragen mehr offen. Falls doch empfehle ich unbedingt die "C++ Frequently Questioned Answers" http://yosefk.com/c++fqa/index.html und dabei insbesondere http://yosefk.com/c++fqa/defective.html 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. 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".
:
Bearbeitet durch User
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.
nicht"Gast" schrieb: > 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. Das macht man in C sehr oft. OOP ist ein Konzept, welches nicht unbedingt explizit von der Sprache selbst bereitgestellt werden muss. Trotzdem stellt sich natürlich die Frage, warum nicht C++, wenn man die Konzepte sowieso in C "nachprogrammiert". Außerhalb des Kernel allerdings nur. Systemprogrammierung in C++ würde ich auch nicht wollen.
Christian B. schrieb: > In der Praxis laufen C++ Projekte > so ab, dass jeder Entwickler von einem neuen Sprachfeature hört, und es > dann an seinem Codestück ausprobiert. Echt? Immer? Das ist ja schlimm! Da lobe ich mir C, da findet man diese neumodischen C99 features nur extrem selten, weil die ja noch nicht von allen Compilern unterstützt werden ;-) Da kann man dann sicher sein, dass man mit seinem einmal erlernten Wissen bis zur Rente durch kommt!
Cyblord -. schrieb: > Das macht man in C sehr oft. OOP ist ein Konzept, welches nicht > unbedingt explizit von der Sprache selbst bereitgestellt werden muss. > Trotzdem stellt sich natürlich die Frage, warum nicht C++, wenn man die > Konzepte sowieso in C "nachprogrammiert". Außerhalb des Kernel > allerdings nur. Systemprogrammierung in C++ würde ich auch nicht wollen. Naja, wenn man Anwendungsprogrammierung betreibt, dann kann man auch gleich eine ganz andere Programmiersprache, wie z.B. Java, C# oder Go nehmen. Dann muss man sich auch nicht mehr um den Speicher kümmern. Wenn man dagegen eine Library für irgendetwas schreibt, dann empfiehlt sich wieder C, da es für so ziemlich jede andere Sprache eine Anbindung gibt. Die ganze Vererbungsgeschichte von C++/Java/C# finde ich jedoch allgemein für die Katz und wenn man dem "Design Pattern" "Composition-over-Inheritance" folgt dann muss man sich z.B. bei C++ schon wieder mit virtuellen Funktionen und abstrakten Klassen verrenken. Bei C oder Go nimmt man einfach einen Struct und fertig. Wenn man in C so etwas wie Member-Funktionen möchte, dann nimmt man eben einen Struct und packt dort Pointer zu den Funktionen rein. Jeder der weiß wie Structs funktionieren und jeder der weiß was ein function-pointer macht versteht sofort den Kontext. Bei C++ geschieht "Information Hiding" vor allem zwischen Sourcecode und Programmierer.
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?
nicht“Gast“ schrieb: > Könnt ihr euch vielleicht in einen anderen Thread auskotzen? Nach dem Abendbrot. Es muß ja erst mal neue Munition dafür gebunkert werden. MfG Paul
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? > Ich meine jedoch keine Programmierung con Mikrocontrollern, > da ich bisher nur Mathematische Programme geschrieben habe. > In Zukunft möchte ich das aber auch machen. Besser C programmieren tut man nur durch Übung, recht hilfreich kann auch "pair programming" sein. Wichtiger als die Sprache sind die Konzepte, ein Programm zu strukturieren, da wurde schon einiges gesagt, sowie Kenntnis von Datenstrukturen und Algorithmen und deren Laufzeitverhalten, und eine grobe Vorstellung, welche Größenordnung die Dauer einer Operation hat (Takte, ms, s, ...). Ansonsten sind alle imperativen Programmiersprachen wie C#, C++, Java, Go etc... quasi gleich, der Hauptunterschied ist in den mitgelieferten Frameworks. Den Sprach-Teil einer neuen Sprache eignet man sich mit guten C-Vorkenntnissen dann meistens auch in 1-2 Tagen an. Sprachfights sollte man nicht allzu ernst nehmen. Bei realen Problemstellungen ist man eh meistens an fixe Vorgaben gebunden, ansonsten nimmt man was worin man schnell ist. Etwas über den Tellerrand zu schauen und zumindest eine Ahnung zu haben, wo der fundamentale Unterschied zu LISP, Haskell, Prolog und anderen Sprachen ist schadet auch nicht.
Christopher J. schrieb: > Durchstapler schrieb: >> 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." > > Den Link wollte ich eigentlich auch schon einwerfen ;) > > Auch von der selben Seite: > > http://harmful.cat-v.org/software/c++/I_did_it_for_you_all > > Da bleiben keine Fragen mehr offen. Falls doch empfehle ich unbedingt > die "C++ Frequently Questioned Answers" > > http://yosefk.com/c++fqa/index.html > > und dabei insbesondere > > http://yosefk.com/c++fqa/defective.html Viel davon hängt vom Programmierstil ab. Man muss nicht alle Features mit Gewalt nutzen. C++11/C++14 macht auch vieles einfacher. C allein ist schon grausam genug, wers nicht glaubt soll sich die creativeren Beiträge von ioccc.org oder www.underhanded-c.org anschaun. Allein der Präprozessor ermöglicht so viele Grausamkeiten, da braucht man gar kein "undefined behaviour". Auch in C muss man sich an Konventionen halten, diese sind halt etwas etablierter und einheitlicher als in C++. Im Zweifel schaut man sich die google C++ guidelines an und legt sich auf dieser Basis was zurecht.
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 > ... Diese Liste taugt auch als Basis für Bullshit-Bingo bei Design-Meetings ;-)
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..
C-Programmer schrieb: > angefangen C zu lernen und würde gerne Übungen haben ... Tipps? > keine Programmierung con Mikrocontrollern, da ich bisher nur > Mathematische Programme geschrieben habe. Was heißt "nur"? Wenn jemand fragt, empfehle ich immer sowas wie hier, wobei für Grafik neben C/C++ auch allerhand aus der WinAPI nötig ist: 1. Conway's GoL (Game of Life), geht halbwegs auch in der Konsole. 2. Baum des Pythagoras. 3. Fraktal Generator mit allem Drum und Dran. 4. Funktionsplotter oder irgendwas mit Raytracing. Erschwerte Bedingungen: Den Quellcode so schreiben, daß er mit einem Minimum an Änderungen auch in Freepascal o.a. verwendbar ist. Das soll dann aber nicht so aussehen, wie hier etwa: http://www2.informatik.uni-halle.de/lehre/c//c_prepas.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.