Announcement: there is an English version of this forum on Moinsen Ich habe ich in den letzten Monaten mit dem Arduino beschäftigt ujd würde sagen bin auch ganz gut darin. Da der Arduino einem jedoch ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Wie stell ich das am besten an schau ich mir Tutorials auf YouTube an Kauf ich mir ein Buch ? Wie habt ihr es denn gemacht. Bin für jeden Ratschlag dankbar ^^ Mfg
Bücher gibts wie Sand am Meer. Mein erster C Kurs war in der Volkshochschule da wurde alles erklärt und als Hausaufgabe saß ich zu Hause am PC und hab ausprobiert. Das hat prima funktioniert.
Du hast es zwar eh schon gesagt aber ich will nochmal drauf hinweisen das es Sinn macht mit reinem C anzufangen bevor man irgendwas anderes wie C-- oder C-Schaf lernt.
Moin, ich habe damals mit einem Taschenbuch "Programmieren in ANSI-C" oder so ähnlich angefangen. Die Befehle einmal durchlesen und dann loslegen: üben, üben, üben. M.E. ist die Praxis das Wichtigste. Heute lassen sich ja auch jede Menge Codeschnipsel/Bibliotheken im I-Net finden, da kann man auch schön nachvollziehen, wie andere das Problem gelöst haben. Selbst wenn man es anders machen würde, ist der Vergleich doch immer wieder interessant.
Ansonsten fällt mir noch diese Seite an auf der Programmlösungen zu vielen der immerwiederkehrenden Problemstellungen in verschiedenen Programmiersprachen gegeben werden: https://rosettacode.org/wiki/Category:C
Eigentlich habe die Kollegen schon das wichtigste gesagt. Nimm ein Board (nicht Arduino) und programmiere es in reinem C. Nimm vorhandene Codes oder Beispiele und zerlege die Programme und lerne wie andere es gemacht haben. Ansonsten hilft nur üben, üben und noch mals üben ...
Dennsi W. schrieb: > aber ich will nochmal drauf hinweisen > das es Sinn macht mit reinem C anzufangen bevor man irgendwas anderes > wie C-- Nein! Erstens, ist Arduino C++. Somit würde man mit C definitiv die falsche Sprache lernen, wenn man sich weiter mit Arduino beschäftigen möchte. Nichts gegen C! Es ist auch eine Sprache, wie jede andere, ... Lernt man allerdings erst eine prozedurale Sprache, dann ist man für OOP verdorben! Es ist viel schwieriger später von prozedural nach OOP zu schwenken, als sofort OOP zu lernen. Nein! Ich sage: Erst eine OOP Sprache lernen, bzw. begreifen, was OOP ist, und wie es tut. Eigentlich egal welche Sprache, wenn es denn nicht so ein völliger Exot, wie JS ist.
:
Bearbeitet durch User
Warum eigentlich C? Arduino nutzt C++. Es gibt wenig Gründe, überhaupt noch C zu verwenden - nur sehr wenige Plattformen haben keine C++-Compiler, und da du sowieso bei 0 anfängst kannst du auch direkt C++ nehmen. Erst C lernen und dann C++ klingt zwar gut ist aber nicht besonders sinnvoll, denn dann muss man erst wieder alle schlechten C-Angewohnheiten un-lernen. Besser ist es, direkt mit C++ zu lernen, wie man Programme richtig strukturiert. Sollte man dann doch mal C brauchen, muss man "nur" das weglassen, was C nicht kann und die 2, 3 Details die nur C kennt nachschlagen. 3, 2, 1... Mistgabeln und Fackeln.
Dr. Sommer schrieb: > Mistgabeln und Fackeln Auf den Scheiterhaufen mit dir! Die Prozeduraldenker sagen: > Erst C lernen > dann versuch mal C++ > und du wirst zu deinem C zurückkommen > Das ist der Beweis dafür, dass C besser ist. Die OO-Denkenden können in jeder Sprache Objekt orientierte Programme schreiben. Es ist natürlich eine Hilfe, wenn die Sprache das unterstützt.
:
Bearbeitet durch User
Gemgod schrieb: > Moinsen > > Ich habe ich in den letzten Monaten mit dem Arduino beschäftigt ujd > würde sagen bin auch ganz gut darin. Da der Arduino einem jedoch > ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Eine löbliche Einstellung. > Wie stell > ich das am besten an schau ich mir Tutorials auf YouTube an ;-) Jaja, Generation Youtube. Dort lernt man das gescheite Programmieren in C sicherlich NICHT! > Kauf ich mir > ein Buch ? Das schon eher. Du mußt es aber auch lesen und vor allem DURCHARBEITEN! Sprich, alle Übungen nachmachen. > Wie habt ihr es denn gemacht. Eben so. Und halt mit kleinen Projekten anfangen und schrittweise komplexere Dinge machen.
Dennsi W. schrieb: > Es gibt auch kombinierte C/C++ Bücher, vielleicht wäre das ja das > richtige Eher nicht. Diese Bücher hauen C und C++ üblicherweise in einen Topf. Dieses Denken muss man sich dann wieder mühsam abtrainieren.
Dr. Sommer schrieb: > C++-Compiler, und da du sowieso bei 0 anfängst kannst du auch direkt C++ Das würde ich nicht sagen der Arduino nimmt einen zwar viel ab aber C ist es ja trotzdem muss da ja auch variablen deklarieren Schleifen Verzweigungen usw.
Gemgod schrieb: > aber C > ist es ja trotzdem Ja eben nicht! Nochmal zum Mitschreiben: Arduino ist C++, Arduino ist nicht C! Gemgod schrieb: > muss da ja auch variablen deklarieren Schleifen > Verzweigungen usw. Variablen deklarieren geht in klassischem Ansi-C (wie oben "empfohlen") schon anders als in C. In C++ beschäftigt man sich mehr mit Klassen und Abstraktion und braucht daher insgesamt weniger Schleifen und Verzweigungen.
Um die Frage C vs C++ hier zu klären wäre das geplante Ziel deiner Reise gut zu wissen. Geht es darum Programmieren zu lernen und Code zu schreiben, der relativ unabhängig von einer Plattform ist, dann fang mit C++ an. Es hat eine höhere Abstraktion als C und damit kann Code in vielen Fällen übersichtlicher und sicherer in der Verwendung geschrieben werden. Durch die Objektorientierung und Templates ist es aber auch umfangreicher als C, wobei man das zum Einstieg auch noch nicht verstehen muss. Geht es darum eine Mikrocontroller zu verstehen und sich im Detail mit den einzelnen Operationen zu beschäftigen, dann würde ich mit C oder sogar Assembler anfangen. Da ist man sehr dicht am Prozessor und hat erstmal wenige Abstraktionen dazwischen. Wenn man später einfach zwischen den Sprachen wechselt sehe ich folgende "Probleme". C->C++: Man schreibt einfach weiter so wie C und hat damit durch C++ keinen Mehrwert. C++->C: Man hat sich an die Objekte und Automatismen gewöhnt und muss sich umstellen.
M.K. B. schrieb: > C++->C: Man hat sich an die Objekte und Automatismen gewöhnt und muss > sich umstellen. Wer C++ kennt, wird aber selten komplett auf C "umsteigen" müssen, denn man kann fast überall auch C++ nutzen. Ausnahmen sind nur sehr minimale Mikrocontroller und der Linux-Kernel...
Dr. Sommer schrieb: > Ja eben nicht! Nochmal zum Mitschreiben: Arduino ist C++, Arduino ist > nicht C! Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino" auch in ANSI-C zu programmieren. Geht sogar in Assembler.
Joe F. schrieb: > Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino" > auch in ANSI-C zu programmieren. Ach, wie funktioniert denn da die ANSI-C-Funktion system() ? Es ging natürlich um die Arduino-IDE, -Sprache und -Bibliothek. Dass man den Controller auch mit einer anderen Umgebung bedienen kann ist klar.
Joe F. schrieb: > Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino" > auch in ANSI-C zu programmieren. Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++.
Joe F. schrieb: > Dr. Sommer schrieb: >> Ja eben nicht! Nochmal zum Mitschreiben: Arduino ist C++, Arduino ist >> nicht C! > > Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino" > auch in ANSI-C zu programmieren. > Geht sogar in Assembler. Wenn du die Arduino IDE verwenden willst, dann muss mindestens eine Datei C++ sein. Ohne geht es nicht. Assembler, das geht nur in Libraries. Der Rest, kann wie es will! Auch C. Verzichtest du auf diese IDE, wird das Spektrum natürlich breiter.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Joe F. schrieb: >> Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino" >> auch in ANSI-C zu programmieren. > > Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung > gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++. Nein, "Arduino" ist nicht C++, und ein Anfänger erkennt eben nicht sofort, dass hier die IDE gemeint ist. Und ".ino" ist auch nicht C++. Ich fühle mich gerade wie ein alternder, rechthaberischer Mann, aber wenn es Leute wie mich nicht gäbe ist auch bald ein iPhone ein Mac und .fritzing ist Elektronik. Auch "Youtube-Tutorial" und "Lehrbuch" sind zwei verschiedene Dinge.
:
Bearbeitet durch User
Joe F. schrieb: > Nein, "Arduino" ist nicht C++, und ein Anfänger erkennt eben nicht > sofort, dass hier die IDE gemeint ist. > Und ".ino" ist auch nicht C++. Du bist verwirrt!
Arduino Fanboy D. schrieb: > Lernt man allerdings erst eine prozedurale Sprache, dann ist man für OOP > verdorben! Und das ist gut so. OOP ist bei den meisten kleinen Projekten und vor allem für µC absoluter Overkill. > Es ist viel schwieriger später von prozedural nach OOP zu schwenken, als > sofort OOP zu lernen. Es ist völlig unsinnig, auf µC wie den bei Arduino verwendeten AVRs OOP zu programmieren.
Karl K. schrieb: > Es ist völlig unsinnig, auf µC wie den bei Arduino verwendeten AVRs OOP > zu programmieren. 6 setzen!
.ino mit inline Assembler wo ist das Problem?! Oder auch C. Geht oft sogar gar nicht anders übrigens.
Nicht W. schrieb: > inline Assembler Ist eine Gnade der der verwendeten Sprache! Nicht mehr, und nicht weniger. Egal ob *.c, *.cpp, oder *.ino
Arduino Fanboy D. schrieb: > Karl K. schrieb: > Es ist völlig unsinnig, auf µC wie den bei Arduino verwendeten AVRs OOP > zu programmieren. > > 6 setzen! Du brauchst Dich hier nicht als Klassenlehrer unmündiger Programmierschüler aufzuplustern. OOP pur für kleine 8Bitter hält nur eine Minderheit für sinnvoll, noch viel weniger verwenden es. Standard ist und bleibt C, selbst Assembler hat hier noch eine größere Relevanz.
Tom V. schrieb: > aufzuplustern Stimmt! Das kann man besser dir überlassen. Mach doch den Hahn auf dem Mist. Ich gönne es dir.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Tom V. schrieb: > aufzuplustern > > Stimmt! > Das kann man besser dir überlassen. Nö. Im Gegensatz zu Dir verteil ich hier nicht Schulnote. > Mach doch den Hahn auf dem Mist. > Ich gönne es dir. Du bist schon echt bedauernswert. Aber wenn man nicht mehr weiter weiß...
Bedaure, wen du willst... Und geh kacken, wenn es nötig ist. Bitte!
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Bedaure, wen du willst... > Und geh kacken, wenn es nötig ist. > Bitte! Und Du mach weiter den Hahn auf dem Mist, den Du hier den Leuten weismachen willst. Schwachsinniger kann man sich ja fast nicht präsentieren...
Arduino Fanboy D. schrieb: > Wenn du die Arduino IDE verwenden willst, dann muss mindestens eine > Datei C++ sein. > Ohne geht es nicht. > Assembler, das geht nur in Libraries. Stimmt nicht, man kann ganz normale Assembler-Dateien in die Arduino-Verzeichnisse schmeißen, die werden anstandslos compiliert.
Nicht W. schrieb: > Oder auch C. Wie denn? Die Arduino IDE ruft den C++ Compiler auf .ino Dateien auf. Der nimmt an, es handele sich um C++. Wenn du in einer solchen Datei C-Konstrukte nutzt, die es in C++ nicht gibt, gibt es Fehler (manche C-Konstrukte unterstützt der g++ aber als Erweiterung). Nur weil man in der Arduino IDE irgendwie C oder (Inline) Assembler unterbringen kann, ist es nicht besonders erstrebenswert diese Sprachen zu lernen, wenn man die eigentliche Arduino-Sprache (C++ mit komischem Präprozessor) lernen möchte. Tom V. schrieb: > OOP pur für kleine 8Bitter hält nur eine Minderheit für sinnvoll, noch > viel weniger verwenden es. Serial.print verwenden ziemlich viele, und das ist ziemlich OOP (inkl. virtueller Funktionen). Die Verweigerung gegenüber OOP ist aber auch widersinnig. Gerade im Embedded Bereich hat man mit Objekten der echten Welt zu tun - Peripherie-Module, Sensoren, Aktoren - warum diese nicht als Objekte der Programmiersprache auffassen?
Dr. Sommer schrieb: > . Gerade im Embedded Bereich hat man mit Objekten der echten Welt zu tun > - Peripherie-Module, Sensoren, Aktoren - warum diese nicht als Objekte > der Programmiersprache auffassen? Das kann ich beantworten: weil OOP-sprachen erst dann wirkliche Vorteile bringen, wenn die Echtweltobjekte nicht konkret sind (ich verwende hier sonst den Begriff "virtuell") Ein Rad vorne links im Auto ist konkret. Das ESP braucht genau eines, genau 4 Räder insgesamt, es kann mit einer 5ten Instanz "Rad" nichts anfangen. Hier ist guter C-Code nicht schlechter, aber meist weniger komplex. M.E. der Grund, warum autosar vorwiegend C ist. Ein Plug&Play Sensor am arduino, eine Sitzverstellung, ein Medium (CD, USB-Stick) sind oft virtuell. Ein Rechteck im Zeichenprogramm auf der Zeichenfläche ist es immer. Also wo eine unbekannte Anzahl Objekte instanziiert wird, da erst spielt OOP seine Vorteile aus. Die Vorteile (und wachsende Sprachkomplexität) von Templates, constexpr, Optimierung etc. bei C++ ist davon unabhängig. C++ zu C ist wie Word zu Notepad.
Für schmerzfreie Objekte gibt es u.a. Python. Objekte haben in C nichts verloren, darum gibt es sie da auch nicht. Was sollte man auch mit Objekten in einem High-Level-Assembler. Und C++ ist wie eine Promenadenmischung aus Windhund und Bullterrier, mit schiefen Beinen und einem akromegalischen Wasserkopf.
A. S. schrieb: > Also wo eine unbekannte Anzahl Objekte instanziiert wird, da erst spielt > OOP seine Vorteile aus. Sehe ich überhaupt nicht so. Auch bei fixen Anzahlen kann man mit OOP Daten kapseln, Operationen abstrahieren, Assoziationen modellieren... Und nur weil die Anzahl bei einer Programmversion 4 ist, muss sie ja bei der nächsten - oder bei einem Unit-Test - nicht auch 4 sein. Praktisch, wenn man die Software leicht an geänderte Hardware anpassen kann! Zonengabi schrieb: > Und C++ ist wie eine Promenadenmischung Und die einzige Sprache welche Effizienz mit Abstraktion verbindet. Vielleicht gibt es bald Konkurrenz durch Rust. Python aber ist kein Ersatz für C++.
Wer wirklich lernen will, sollte Arduino und auch objektorientiertes Denken und Kauderwelsch erstmal links liegen lassen! Bei und Ossis gab es mal so nen Witz: Warum brauchen Wessis 13 Jahre fürs Abi? Weil ein Jahr Schauspiel - Unterricht dabei ist! Auf die Frage ob mit prozedural oder OOP zu beginnen sein, trifft dieser Witz auch zu!
Zonengabi schrieb: > Für schmerzfreie Objekte gibt es u.a. Python. Du schweifst ab. Es ging um C. Und daraufhin um die Frage, warum nicht doch sofort das sowieso native arduino-C++. > Objekte haben in C nichts verloren, darum gibt es sie da auch nicht. Hä? Du meintest vermutlich, dass C abgesehen von struct und Funktionspointern OOP kaum unterstützt? Ja.
Beitrag #5819235 wurde von einem Moderator gelöscht.
OOP ist nur ein Aspekt von C++ und vielen. C++ ist: - prozedural - objektorientiert - generisch - meta-programmatisch - (etwas) funktional Und C++ ist genauso ressourcen-sparend wie C, bzw. wenn man die meta-programmatischen Aspekte verwendet, noch weit mehr ressourcen-schonender als C.
Wilhelm M. schrieb: > BTW: > > "Stop teachung C" > > Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C"" Ja, Spinner gibts immer.
Tim T. schrieb: > Wilhelm M. schrieb: >> BTW: >> >> "Stop teachung C" >> >> Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C"" > > Ja, Spinner gibts immer. Deine Antwort zeigt, dass Du die Intention des Vortrages nicht verstanden hast bzw. das Video erst gar nicht gesehen hast ...
Wilhelm M. schrieb: > Tim T. schrieb: >> Wilhelm M. schrieb: >>> BTW: >>> >>> "Stop teachung C" >>> >>> Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C"" >> >> Ja, Spinner gibts immer. > > Deine Antwort zeigt, dass Du die Intention des Vortrages nicht > verstanden hast bzw. das Video erst gar nicht gesehen hast ... In diesem speziellen Fall hat mir ihr Name gereicht um zu dem Schluss zu kommen, da muss ich garnicht erst irgendeinen Vortrag von ihr sehen.
C oder C++ hin oder her, wichtig ist es auf jeden Fall, einmal das Konzept von pointern richtig verstanden zu haben!
blub schrieb: > Wilhelm M. schrieb: >> - generisch > > Was genau meinst du damit? Google kaputt heute? https://de.wikipedia.org/wiki/Generische_Programmierung In C++ realisiert das die template-Mechanik.
Wenn Englisch kein Problem ist, würde ich dir diese Tutorials ans Herz legen: https://www.newbiehack.com/MicrocontrollerWritingthefirstprogramandtransfer.aspx Da lernst du beim Durcharbeiten neben der Funktion des Microcontrollers so ganz nebenbei auch gleich C. Basiert allerdings auf einem reinen Atmega und nicht auf einem fertigen Arduino. Gruß thoern
Falk B. schrieb: > man kann ganz normale Assembler-Dateien in die > Arduino-Verzeichnisse schmeißen, die werden anstandslos compiliert. OK! Da hast du Wahr! Eine Neuerung, die mir noch nicht bekannt war. Danke. Dr. Sommer schrieb: > Wie denn? Die Arduino IDE ruft den C++ Compiler auf .ino Dateien auf. > Der nimmt an, es handele sich um C++. Wenn du in einer solchen Datei > C-Konstrukte nutzt, die es in C++ nicht gibt, gibt es Fehler (manche > C-Konstrukte unterstützt der g++ aber als Erweiterung). Nee.. Ein Großteil des Arduino Core ist in C geschrieben. *.c Dateien, werden vom C Compiler kompiliert. *.cpp. vom C++ Compiler *.ino werden erst zu *.cpp umgefuddelt und dann Compiliert. Und wie ich heute gelernt habe werden auch *.S Dateien korrekt verarbeitet.
Rufus Τ. F. schrieb: > Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung > gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++. "meine" *.ino haben c innen, denn c ist auch in c++ eine Untermenge und meine INO funktionieren mit dem C-Code seit Atari und PC. Es stimmt schon für c++ bin ich verdorben, aber das stört mich nicht. Mein eigener C-Code arbeitet sogar mit c++ der LIBs zusammen.
:
Bearbeitet durch User
Joachim B. schrieb: > Rufus Τ. F. schrieb: >> Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung >> gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++. > > "meine" *.ino haben c innen, denn c ist auch in c++ eine Untermenge und > meine INO funktionieren mit dem C-Code seit Atari und PC. C ist KEINE Untermenge von C++.
Thomas H. schrieb: > so ganz nebenbei auch gleich C Leider nicht so richtig... Da werden binär-Integer-Literale wie "0b00000001" gezeigt, ohne zu sagen, dass es die in C gar nicht gibt - in C++ aber schon! Der GCC unterstützt die in C als Erweiterung. Es wird asm volatile ("nop"); gezeigt; korrekt wäre _asm_ volatile ("nop"). Es werden fröhlich Makros benutzt - eines der Dinge, die man in C++ besser machen kann. Bei Send_A_String("Patrick"); wird ein String-Literal an char* übergeben - veraltet und fehleranfällig. Mehr Fehler habe ich jetzt keine Lust zu suchen. Sieht jedenfalls nicht so empfehlenswert aus. Joachim B. schrieb: > denn c ist auch in c++ eine Untermenge Nein. z.B. designated initializers gibt's nur in C. Joachim B. schrieb: > "meine" *.ino haben c innen Du meinst: Sie haben C++ Code, der zufällig auch gültiges C ist. Hoffentlich benutzt du kein Serial.print oder Wire.write! Joachim B. schrieb: > Mein eigener C-Code arbeitet sogar mit c++ der LIBs zusammen. Wie schaffst du das? Eigene Funktions-Prototypen mit manuellem C++-Name-Mangling?
Joachim B. schrieb: > Rufus Τ. F. schrieb: >> Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung >> gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++. > > "meine" *.ino haben c innen, Dein Code mag eine gemeinsame Untermenge aus C und C++ sein. Compilert wird es als C++. > denn c ist auch in c++ eine Untermenge und meine INO funktionieren mit dem > C-Code seit Atari und PC. Du hattest auf dem Atari .ino-Dateien? Wenn du noch so altes C benutzt, wird tatsächlich fast alles auch als C++ funktionieren.
Beitrag #5819289 wurde von einem Moderator gelöscht.
Babylonier schrieb im Beitrag #5819289: > Wilhelm M. schrieb: > >> Und C++ ist genauso ressourcen-sparend wie C, bzw. wenn man die >> meta-programmatischen Aspekte verwendet, noch weit mehr >> ressourcen-schonender als C. > > Der war gut! > > "C++ weit sparsamer an Ressourcen als C", das sorgt immer für saalweites > Schenkelklopfen. ... wer aus dem alten Babylon (hier C-Welt) kommt, kann das wohl nicht verstehen ;-)
> Bin für jeden Ratschlag dankbar
Installier dir den compiler-explorer. Dazu z.B. das 0856-ISA. Nun hackst
du das, was du für C hältst rein, und bewertest es über die Anzahl der
Assembler-Befehle.
Ist manchmal lustig. Früher hatte eine Zeile Hochsprache einen
Rattenschwanz an Assembler nach sich gezogen. Heute ist es umgekehrt.
Ich würde das gern noch mal für Dich zusammenfassen: Gemgod schrieb: > Ich habe ich in den letzten Monaten mit dem Arduino beschäftigt ujd > würde sagen bin auch ganz gut darin. Da der Arduino einem jedoch > ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Wie stell > ich das am besten an Du bringst Da einiges durcheinander. Die Sprache, die Arduino-Programme benutzen ist ganz normales c++. C++ enthält als Untermenge auch einen C Dialekt, der ist aber nicht identisch mit C. Das "Abnehmen" erledigen Aufrufe der Arduino Bibliothek, die kannst Du, musst Du aber nicht verwenden. Du kannst weitgehend low-level Programmierung mit der Verwendung der Arduino Bibliothek mischen. Wenn Du schreibst, du seist ganz gut darin, hast Du eigentlich einen naheliegenden Lernpfad vor dir. Nimm eines Deiner bestehenden funktionierenden Arduino Programme und dengel es Aufruf für Aufruf auf low-level um. So hast Du Deine Fehler schön eng eingegrenzt und weißt ungefähr, wo du suchen musst und hast schöne kleine Lernpakete. vlg Timm Je
neuer PIC Freund schrieb im Beitrag #5819320: >> Bin für jeden Ratschlag dankbar > > Installier dir den compiler-explorer. Dazu z.B. das 0856-ISA. Nun hackst > du das, was du für C hältst rein, und bewertest es über die Anzahl der > Assembler-Befehle. > Ist manchmal lustig. Früher hatte eine Zeile Hochsprache einen > Rattenschwanz an Assembler nach sich gezogen. Heute ist es umgekehrt. Ja, viele Leute glauben immer noch, schlauer als der Optimizer zu sein. Besser ist es, den Optimizer seine Arbeit machen zu lassen ;-)
Wilhelm M. schrieb: > C ist KEINE Untermenge von C++ Nur für Leute, die gern Haare spalten. Eine der wesentlichen Forderungen an C++ und IMHO die Hauptursache für alle begründeten Rants gegen C++ [1] war die weitestgehende Kompatibilität von C++ mit C. Es war ein Designziel, daß jedes [2] gültige C-Programm auch ein gültiges C++-Programm sein sollte. Insofern ist C++ also schon als Obermenge von C bzw. umgekehrt C als Untermenge von C++ gemeint. [1] C++ schleppt eine Menge Merkwürdigkeiten mit sich herum, die es nur wegen der Kompatibilität zu C braucht. Ich hätte mir z.B. gewünscht, daß C++ nur noch richtige Strings erlaubt und die Krücke mit char* von C strikt verbietet. Geht halt nicht. Im Prinzip sollte man jegliche nackten Pointer in C++ verbieten. Nur noch Referenzen und Smart Pointers. [2] natürlich ist es trivial, hierfür Ausnahmen zu finden. Man braucht bloß ein C++ Schlüsselwort als Bezeichner in einem C-Programm zu verwenden. Aber so etwas ist natürlich genauso trivial zu beheben.
:
Bearbeitet durch User
Axel S. schrieb: > Wilhelm M. schrieb: >> C ist KEINE Untermenge von C++ > > Nur für Leute, die gern Haare spalten. Eine der wesentlichen Forderungen > an C++ und IMHO die Hauptursache für alle begründeten Rants gegen C++ > [1] war die weitestgehende Kompatibilität von C++ mit C. ... war ... Zur Info: https://stackoverflow.com/questions/1201593/where-is-c-not-a-subset-of-c > Es war ein Designziel, daß jedes [2] gültige C-Programm auch ein > gültiges C++-Programm sein sollte. Insofern ist C++ also schon als > Obermenge von C bzw. umgekehrt C als Untermenge von C++ gemeint. ... war ... sollte ... C und C++ habe eine große Überdeckung, aber es ist eben keine Teilmenge, und dann sollte man es auch nicht so bezeichnen.
Wer C kennt und in großen Teilen beherrscht, braucht kein C++ Und Mikrocontroller zu programmieren, braucht man mit Sicherheit kein C++
Sturm88 schrieb: > Wer C kennt und in großen Teilen beherrscht, braucht kein C++ Wer Brainfuck beherrscht, braucht auch kein C. Es geht nicht darum, was man braucht. Es geht darum, womit man effizient und sicher arbeiten kann.
Dr. Sommer schrieb: > Serial.print verwenden ziemlich viele, und das ist ziemlich OOP (inkl. > virtueller Funktionen). Das ganze Messaging-System von OOP funktioniert auf AVRs nicht, weil dafür zu wenig Speicher vorhanden ist. Letztlich macht der Compiler aus dem was Du für OOP hältst genau das, was Du nicht willst: Prozedurale Programmabläufe. Weil es der AVR gar nicht anders kann. Dagegen verleitet OOP-artige Programmierung auf dem AVR zu Ressourcenverschwendung. Das sind dann die Leute, die rumjammern, dass ihr AVR zu langsam ist und zu wenig Speicher hat.
Karl K. schrieb: > Das ganze Messaging-System von OOP Was soll das sein? Karl K. schrieb: > Letztlich macht der Compiler aus dem was Du für OOP hältst Was hältst du für OOP? Ausschließlich asynchrone Methodenaufrufe? Das wäre eher das Aktor-Modell. Nach der Logik unterstützen nur ganz wenige Sprachen "echtes" OOP (z.B. Erlang). Und natürlich macht der Compiler aus allem eine prozedurale Folge an Befehlen. Was anderes kann kein Prozessor. OOP ermöglicht es aber, den Code besser zu strukturieren und wartbarer zu machen; selbst wenn am Ende exakt der gleiche Maschinen-Code rauskommt - genau das kann bei C++ passieren. Karl K. schrieb: > Dagegen verleitet OOP-artige Programmierung auf dem AVR zu > Ressourcenverschwendung. C auch, mit seinen ineffizienten malloc(), system(), alloca(), - Funktionen.
Karl K. schrieb: > Dr. Sommer schrieb: >> Serial.print verwenden ziemlich viele, und das ist ziemlich OOP (inkl. >> virtueller Funktionen). > > Das ganze Messaging-System von OOP funktioniert auf AVRs nicht, weil > dafür zu wenig Speicher vorhanden ist. Nein. Funktionieren tut es. Allerdings meinen viele, C++ == OOP, und das stimmt eben nicht (s.o.). > Letztlich macht der Compiler aus dem was Du für OOP hältst genau das, > was Du nicht willst: Prozedurale Programmabläufe. Weil es der AVR gar > nicht anders kann. Jeder µC kann nur Maschinencode - Assembler kann auch keiner.
Gemgod schrieb: > Da der Arduino einem jedoch > ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Merkwürdige Begründung! Ist es nicht gerade das Ziel, möglichst bequem zu proggen? Wo ist das Motiv? Anfaenger in C schrieb: > Ansonsten hilft nur üben, üben und noch mals üben ... Schon. Es kommt aber etwas noch viel wichtigeres davor: Die Motivation. Die kann von einem konkreten Projekt ausgehen oder weils die Ausbildung verlangt. Ohne konkreten Anlass wird das eine zähe Sache.
Gemgod schrieb: > Da der Arduino einem jedoch > ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Wie stell > ich das am besten an... Am besten stellst du das an mit einem Umweg. Bei Arduino benutzt du eine Menge fertig vorbereiteter Dinge, das ist (salopp gesagt) wie Bauklötzchen. Aber es ist in seiner Art objektorientiert - und das ist eine gute Seite daran. C hingegen ist rein imperativ und kennt keinerlei Objektorientiertheit. Aus deinem Anfangspost entnehme ich, daß du eigentlich nicht vorrangig das Erlernen von C im Sinn hast, sondern eher das Erlernen des Programmierens - wobei C im Bereich der Mikrocontroller eben die so ziemlich einzige Sprache oberhalb von Assembler ist, die ausreichend verfügbar ist. Aber C ist miserabel strukturiert und die als Beispiele im Internet herumfliegenden Quellen sind zu 90% ebenfalls schlecht strukturiert und chaotisch geschrieben. Gewöhne dir sowas lieber nicht an und lerne zu allererst, sauber und gut lesbar Programme zu schreiben. Aber dafür ist C in allen Geschmacksrichtungen nicht geeignet: Benutzen: ja, Erlernen:nein. Deshalb der obige Rat, es über einen Umweg zu machen: nämlich indem du auf dem PC und nur für den PC mit Lazarus in Pascal dir eigene Programme schreibst. Wenn du erstmal damit gelernt hast, wie man das Oben und das Unten (Algorithmen und Lowlevel-Dinge) auseinander hält, wie man mit Typdeklarationen sich das Leben erleichtert (Pascal ist da um Größenordnungen mächtiger als C), wie man Programme in sinnvolle Units bzw. separate Quellen aufteilt, dann ist es Zeit, sich C anzuschauen. Da wirst du dann bei C feststellen, daß es dort um einiges primitiver zugeht, was dir aber dank zuvor gelernter Grundlagen keinerlei Schwierigkeiten machen wird. Das "Herunter-Abstrahieren" von Pascal nach C ist allemal leichter als das Auswendiglernen von Dingen, die "man eben so in C macht". W.S.
Wilhelm M. schrieb: > Jeder µC kann nur Maschinencode - Assembler kann auch keiner. Naja, ganz so ists nun auch nicht. Im Gegensatz zur Hochsprache entsprechen viele Asm-Instruktionen 1:1 einem zugehörigen Maschinencode.
Dennis S. schrieb: > Wilhelm M. schrieb: >> Jeder µC kann nur Maschinencode - Assembler kann auch keiner. > > Naja, ganz so ists nun auch nicht. Im Gegensatz zur Hochsprache > entsprechen viele Asm-Instruktionen 1:1 einem zugehörigen Maschinencode. Du verstehst den Unterschied zwischen Assembler mit seinen Mnemonics und Maschinencode nicht.
Dennis S. schrieb: > Im Gegensatz zur Hochsprache > entsprechen viele Asm-Instruktionen 1:1 einem zugehörigen Maschinencode. Bei ARM ist die Zuordnung nicht so eindeutig. Viele ASM-Befehle haben da mehrere mögliche Maschinen-Instruktionen, und bei manchen Maschinen-Instruktionen gibt es verschiedene passende ASM-Befehle (Aliase). W.S. schrieb: > nämlich indem du > auf dem PC und nur für den PC mit Lazarus in Pascal dir eigene > Programme schreibst. Wichtig dabei: Es muss Pascal sein, und bloß keine aktuelle und verbreitete Sprache wie Java, C#, Python... W.S. schrieb: > Aber C ist miserabel strukturiert und die als Beispiele im Internet > herumfliegenden Quellen sind zu 90% ebenfalls schlecht strukturiert und > chaotisch geschrieben. Insbesondere deine eigenen, gell :-)
Wilhelm M. schrieb: > Du verstehst den Unterschied zwischen Assembler mit seinen Mnemonics und > Maschinencode nicht. Stimmt. Weils keinen Unterschied macht! Die 1:1 Instructions = Mnemonics garniert mit diversen Keywords, Direktiven und Ausdrücken nennt man dann Assembler.
Dennis S. schrieb: > Wilhelm M. schrieb: >> Du verstehst den Unterschied zwischen Assembler mit seinen Mnemonics und >> Maschinencode nicht. > > Stimmt. Weils keinen Unterschied macht! Die 1:1 Instructions = Mnemonics > garniert mit diversen Keywords, Direktiven und Ausdrücken nennt man dann > Assembler. Genau, aber das ist nicht der Maschinencode ;-)
Rolf M. schrieb: > Du hattest auf dem Atari .ino-Dateien? nö habe ich das irgendwo geschrieben? was ihr immer so lest :) Ich habe C-Code, den hatte ich unter Arduino #included klappte war aber doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch. Jedenfalls kommt der gcc klar damit und ich auch.
Joachim B. schrieb: > Ich habe C-Code, den hatte ich unter Arduino #included klappte war aber > doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch. Dann kompilierst du es als C++. Dein Code ist also anscheinend gültiges C und C++ gleichzeitig. Aber auch wenn der Compiler nicht meckert gibt es Fallstricke: sizeof('0') liefert in C das gleiche wie sizeof(int) (z.B. 2 oder 4), in C++ hingegen immer 1. Hättest du das in deinem Code verwendet, hättest du festgestellt dass .ino eben nicht als C aufgefasst wird.
Dr. Sommer schrieb: > Wichtig dabei: Es muss Pascal sein, und bloß keine aktuelle und > verbreitete Sprache wie Java, C#, Python... Richtig erkannt. Endlich mal, Beckmesser. Weit verbreitet ist ungleich zu zum Lernen geeignet. Das ist der Punkt. Und Lazarus hat mit Java, C# und Python nix am Hut - und produziert ausführbare Programme für die grafischen Desktops in echtem Maschinencode, die keinerlei Runtime-Zeugs brauchen. W.S.
Wilhelm M. schrieb: > Genau, aber das ist nicht der Maschinencode ;-) Und trotzdem gilt: Dennis S. schrieb: > Im Gegensatz zur Hochsprache > entsprechen viele Asm-Instruktionen 1:1 einem zugehörigen Maschinencode.
W.S. schrieb: > produziert > ausführbare Programme für die grafischen Desktops in echtem > Maschinencode, die keinerlei Runtime-Zeugs brauchen. Dasselbe leistet übrigens auch PureBasic. Mein Favorit.
W.S. schrieb: > Weit verbreitet ist ungleich zu zum Lernen geeignet. Das ist der Punkt. Genau, denn Lernen macht viel mehr Spaß wenn man keinen findet der sich damit auskennt den man bei Problemen fragen kann, und viel weniger Informationen im Internet, und weniger Bibliotheken und Beispiele... W.S. schrieb: > und produziert > ausführbare Programme für die grafischen Desktops in echtem > Maschinencode, die keinerlei Runtime-Zeugs brauchen. Klar, beim Lernen ist es wichtig sich den erzeugten Assembler-Code anzusehen. Java-Bytecode ist dafür natürlich zu uncool. Wenn es unbedingt nicht-portabler Maschinencode statt Bytecode sein muss, dann doch lieber C++, denn da findet man Millionen Bücher, Tutorials, Bibliotheken, Beispiele, sonstige Informationen zu, und man ist nicht auf eine einzige IDE (Lazarus) festgelegt sondern kann dank Normierung wechseln.
Dennis S. schrieb: > W.S. schrieb: >> produziert >> ausführbare Programme für die grafischen Desktops in echtem >> Maschinencode, die keinerlei Runtime-Zeugs brauchen. > > Dasselbe leistet übrigens auch PureBasic. Mein Favorit. Keinerlei Runtime-Zeugs?
Dennis S. schrieb: > Wilhelm M. schrieb: >> Keinerlei Runtime-Zeugs? > > Nein. So muss das auch sein (in meinen Augen). Das bezog sich ja auf Systeme mit OS und GUI: die C-Lib und weitere Libs werden dort auch dynamisch gebunden. Auch das ist RunTime-Zeugs ...
Dennis S. schrieb: > Wilhelm M. schrieb: >> Keinerlei Runtime-Zeugs? > > Nein. So muss das auch sein (in meinen Augen). Genau, die Runtime-Bibliotheken gehören in die ausführbare Datei, damit dann wenn man 100 damit erstellte Programme auf dem Rechner hat, man 100x die Bibliothek in den Programmdateien auf der Festplatte hat und damit man die bloß nicht aktualisieren kann, ohne das Programm neu kompilieren zu müssen.
Wilhelm M. schrieb: > Dennis S. schrieb: > Wilhelm M. schrieb: > Keinerlei Runtime-Zeugs? > > Nein. So muss das auch sein (in meinen Augen). > > Das bezog sich ja auf Systeme mit OS und GUI: die C-Lib und weitere Libs > werden dort auch dynamisch gebunden. Auch das ist RunTime-Zeugs ... Eine PureBasic Programm läuft auf jedem halbwegs aktuellen PC. Weitergegeben wird nur die erstellte program.exe Du kannst jetzt natürlich den RunTime Rahmen bis zum zugrundeliegenden Windows dehnen :)
Dr. Sommer schrieb: > Joachim B. schrieb: >> Ich habe C-Code, den hatte ich unter Arduino #included klappte war aber >> doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch. >Dann kompilierst du es als C++. Dein Code ist also anscheinend gültiges >C und C++ gleichzeitig. das ist mal wieder ein typischer mikrocontroller.net Thread. Warum zum Beispiel kriegt diese völlig korrekte Feststellung downvotes? Wie kommt man überhaupt auf die verrückte Idee zu behaupten C sei C++ kompatibel? Wenn man bei "Kindergarten" bleibt ist Englisch auch Deutsch. Mir scheint, dass der eine oder andere C Programmierer hier in diesem Faden vielleicht einfach kaum C kann? Hier mal ein paar Beispiele für Unterschiede, es gibt aber natürlich noch viel mehr, wie zB das schon genannte sizeof, die designated Initialzier, kein int xyz[n] mit zB int n = 42, kein restrict, etc. pp.
int main()
{
// geht nicht in c++
int b(a) int a; { }
// geht nicht in c++
struct A { struct B { int x; } y; int xy; };
struct B y;
// geht nicht in c++
auto z;
// geht nicht in c++
int a[1];
int (*ap)[] = &a;
return 0;
}
|
p.s. Und nein, ich kann nicht gut C und behaupte das auch nicht.
:
Bearbeitet durch User
Timm R. schrieb: > Dr. Sommer schrieb: >> Joachim B. schrieb: >>> Ich habe C-Code, den hatte ich unter Arduino #included klappte war aber >>> doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch. > > das ist mal wieder ein typischer mikrocontroller.net Thread. Ja, schon allein deswegen, weil keiner etwas liest! Deine Beispiele stammen aus dem Link, den ich hier Beitrag "Re: Am besten C lernen" angegeben hatte.
Dr. Sommer schrieb: > Genau, die Runtime-Bibliotheken gehören in die ausführbare Datei, damit > dann wenn man 100 damit erstellte Programme auf dem Rechner hat, man > 100x die Bibliothek in den Programmdateien auf der Festplatte Genau so ist das! Noch von der alten .dll Schule, was? Abhängigkeiten aller Art gehören konsequent ausgemerzt und der Programm- Gebrauch möglichst einfach gestaltet. Glaub mir, heutigen Festplatten ist dieses kleine Opfer leicht abzuverlangen!
Dr. Sommer schrieb: > Es muss Pascal sein, und bloß keine aktuelle und > verbreitete Sprache wie Java, C#, Python... Warum sollte Pascal nicht aktuell sein? Nur weil Du es nicht kennst? Mich nervt ja schon Java auf dem Raspi: OpenHub, HiveMQ, das frisst alles derart unsinnig Ressourcen. Aber Java auf dem AVR? Dein Ernst?
Schöner Glaubenskrieg hier... Jetzt sind wir schon bei interpretierenden Sprachen angelangt. Fehlt eigentlich nur noch COBOL, FORTH und FORTRAN. ;-)) Offenbar nutze ich C-Programme mit etwas C++, die in einem C++-Compiler übersetzt werden. Ist aber völlig egal, solange es funktioniert. Programmieren ist für mich kein Selbstzweck, sondern eine Lösung (von vielen) für ein gegebenes Problem. Hinterher würde man manches vielleicht anders machen, aber das ist dann für das nächste Projekt. Pascal wäre für mathematisch/logisch denkende Menschen sicherlich von ungeheurem Vorteil, aber die Verfügbarkeit ist doch eingeschränkt, gerade auf µC. Durch die strikte Typendefinition werden viele Fehlerquellen gleich vermieden, dafür ist manches dann ungleich schwerer als in C. Zudem kann man nur wenig von verfügbaren Libraries profitieren. Grundsätzlich würde ich alles, was eine RTL braucht, vermeiden, da es durch Releasewechsel oder die Nichtverfügbarkeit der RTL für das Zielsystem zu Problemen kommen kann, die nur für Nerds schön sind. Da C die weitverbreitetste Hochsprache vom µC bis zum Großrechner ist, dürfte es sich schon lohnen, sie zu kennen.
svensson schrieb: > Pascal wäre für mathematisch/logisch denkende Menschen sicherlich von > ungeheurem Vorteil, Genau da sehe ich den größten Vorteil von C++ gegenüber C.
Dennis S. schrieb: > Dr. Sommer schrieb: > Genau, die Runtime-Bibliotheken gehören in die ausführbare Datei, damit > dann wenn man 100 damit erstellte Programme auf dem Rechner hat, man > 100x die Bibliothek in den Programmdateien auf der Festplatte > > Genau so ist das! Noch von der alten .dll Schule, was? Abhängigkeiten > aller Art gehören konsequent ausgemerzt und der Programm- Gebrauch > möglichst einfach gestaltet. > Glaub mir, heutigen Festplatten ist dieses kleine Opfer leicht > abzuverlangen! Link ein paar mal LLVM und du fällst dem Festplattenstapel zum Opfer.
Timm R. schrieb: > // geht nicht in c++ > auto z; Ist mit dem Standard C++11 eingeführt worden. Muss aber gestehen, dass ich trotzdem auch C gerne verwende. Ich fühle mich mit C irgendwie freier. ;) Aber soll jeder/jede die Sprache verwenden, die er/sie gerne möchte. Leben und Leben lassen. Zum Thema: Egal ob C oder C++, auch wenn es am Anfang schwieriger ist, versuche deine ersten Programme ohne IDE zu erstellen. Nimm einen besseren Texteditor (ich verwende KWrite unter KDE) und lerne mit den Compiler per CLI umzugehen. Eine IDE nimmt viele Sachen ab bei größeren Projekten, verschleiert aber grundlegende Sachen wie Makefiles und die Bedienung des Compilers.
Karl K. schrieb: > Warum sollte Pascal nicht aktuell sein? Nur weil Du es nicht kennst? Kenne ich tatsächlich hauptsächlich aus der Schule (damals) und hier aus dem Forum von vermutlich ergreisenden Ingenieuren, die nie was neues gelernt haben... Karl K. schrieb: > Aber Java auf dem AVR? Dein Ernst? Nein, auf dem PC. Lies meinen Post genau. Karl K. schrieb: > Mich nervt ja schon Java auf dem Raspi: OpenHub, HiveMQ, das frisst > alles derart unsinnig Ressourcen. Das liegt nicht per se an Java, sondern an schlecht programmierten Anwendungen. In C kann man genau so ineffizient programmieren. Dennis S. schrieb: > Abhängigkeiten aller Art gehören konsequent ausgemerzt und der Programm- > Gebrauch möglichst einfach gestaltet. Am Ende will noch jemand eine Sicherheitslücke in einer statisch gelinkten TLS-Bibliothek fixen! Gerade das .net Framework ist unter Windows doch sogar vorinstalliert. Eine setup.exe is auch nur eine einzelne Datei, ob die jetzt nur eine Programm.exe oder noch zusätzlich Bibliotheken und Runtime installiert (bzw. prüft ob nicht schon installiert ist) ist auch egal. Unter Linux hat man das Problem eh nicht dank Paketmanager.
Hallo, W.S. schrieb: > Am besten stellst du das an mit einem Umweg. Ich ahne was da jetzt kommt... > ... es über einen Umweg zu machen: nämlich indem du auf dem PC und > nur für den PC mit Lazarus in Pascal dir eigene Programme schreibst. ... und meine Ahnung hat mich nicht getrogen. Das erinnert mich an einen Rat, der mir gegeben wurde als ich eine Fremdsprache erlernen musste/wollte. Ich solle doch vorher Latein lernen, dann würde mir das Erlernen der Fremdsprache viel leichter fallen. Gott sei Dank habe ich diesen Rat nicht befolgt, denn er hätte mich "meilenweit" von meinen eigentlichem Ziel entfernt und unendlich Zeit vergeudet, in der ich mich mit etwas beschäftigt hätte, das ich nie wieder brauchen würde. Was anderes wäre es wenn ich zusätzlich noch andere Sprachen hätte lernen wollen, da hätte sich der Aufwand Latein zu erlernen bezahlt gemacht. Ich rekapituliere mal: es geht Gemgod um die Programmierung eines Arduino-Boards und nicht um ein Programmierprojekt mit x-tausend Codezeilen, das auch in ferner Zukunft von einer Vielzahl anderer Entwickler weiter gepflegt werden muss. Da muss man nicht erst eine andere Sprache (die zudem im Arduino-Universum keinerlei Bedeutung hat) mühsam erlernen, anstatt sich auf das eigentliche Ziel zu konzentrieren, nämlich Hardware zum Leben zu erwecken. > Da wirst du dann bei C feststellen, daß es dort um einiges primitiver > zugeht, was dir aber dank zuvor gelernter Grundlagen keinerlei > Schwierigkeiten machen wird. Ich weiß nicht ob es da "um einiges primitiver zugeht", ich jedenfalls mag C auf Grund der unglaublichen Flexibilität und Anpassungsfähigkeit. Bei Pascal z.B. habe ich diese Flexibilität immer vermisst. > Das "Herunter-Abstrahieren" von Pascal nach C ist allemal leichter > als das Auswendiglernen von Dingen, die "man eben so in C macht". Und nachdem du dann alles "herunter-abstrahiert" hast, musst doch all die Dinge auswendig lernen, die "man eben so in C macht". Wo ist jetzt der Vorteil? rhf
Johannes K. schrieb: > versuche > deine ersten Programme ohne IDE zu erstellen Also, den Rat verstehe ich nicht. Egal für welche Programmiersprache habe ich immer eine IDE genutzt, weil sie einem so viel Arbeit abnimmt. Warum soll ich wissen, wie Programme gelinkt werden? Warum soll ich auf die Dokumentation oder das Syntaxhighlighting verzichten? Okay, stimmt nicht ganz: Perl benutze ich auch heute noch im Editor, aber das ist (auch) eine Scriptsprache.
svensson schrieb: > Warum soll ich wissen, wie Programme gelinkt werden? Um nicht beim ersten "undefined reference" hier im Forum zu fragen "warum klappt nicht"... es würde aber reichen, 2,3 mal manuell zu kompilieren um es mal gemacht zu haben. Danach kann man gerne eine IDE nutzen...
Johannes K. schrieb: > Timm R. schrieb: >> // geht nicht in c++ >> auto z; > > Ist mit dem Standard C++11 eingeführt worden. So wie es oben steht, geht es tatsächlich nicht, da für die Typinferenz der Initialisierer fehlt. Tatsächlich hat sich die Bedeutung des Schlüsselwortes auto geändert!
:
Bearbeitet durch User
Wir haben es mal in einem Jahrgang in der Uni getestet, im Grundlagenfach C Programmierung haben wir das manuelle Kompilieren und Erstellen von Makefiles nur kurz behandelt und den Studenten anschließend Geany zur Verfügung gestellt. So katastrophal wie in diesem Durchgang waren die Ergebnisse nie wieder. Dabei hatten sie exakt die gleichen Unterlagen wie die Studenten aus dem Semester zuvor, wir dachten nur wir tun ihnen was Gutes und sparen ihnen Tipparbeit.
@TO Höre auf W.S. Er hat recht auch wenn das viele hier ganz anders sehen. Der von ihm aufgezeigte Weg mag zwar auf den ersten Blick unlogisch sein, denn Du willst ja "Arduino" lernen und da paßt Pascal ja so gar nicht rein, aber um strukturiert Programmieren zu lernen ist es bestens geeignet. C läßt Dir zwar deutlich mehr Freiheiten, aber das ist gerade am Anfang Segen und Fluch zugleich. Letztendlich ist es aber Deine Entscheidung mit was Du anfangen möchtest zu lernen. Wenn Deine Entscheidung gefallen ist dann kaufe Dir ein gutes Buch, das zu der von Dir gewählten Sprache passt und arbeite es durch. Tutorials im Internet sind zwar eine schöne Sache, betrachte sie aber Anfangs nur als Ergänzung - ein gutes Buch können sie nicht ersetzen.
Wilhelm M. schrieb: > Johannes K. schrieb: >> Timm R. schrieb: >>> // geht nicht in c++ >>> auto z; >> >> Ist mit dem Standard C++11 eingeführt worden. > > So wie es oben steht, geht es tatsächlich nicht, da für die Typinferenz > der Initialisierer fehlt. > > Tatsächlich hat sich die Bedeutung des Schlüsselwortes auto geändert! Okay, wusste ich nicht. Muss mich erst an die neuen Standards gewöhnen. Man lernt nie aus. Danke!
Roland F. schrieb: > Gott sei Dank habe ich diesen Rat nicht befolgt, denn er hätte > mich "meilenweit" von meinen eigentlichem Ziel entfernt und unendlich > Zeit vergeudet, in der ich mich mit etwas beschäftigt hätte, das ich nie > wieder brauchen würde. Schön blöd gewesen - sorry wenn ich es jetzt etwas drastisch formuliert habe. Latein hat hat noch nie geschadet. Ich bedaure heute das ich mich diesbezüglich nicht befleißigt habe, aber wenn man jung ist sieht man manches eben völlig anders. Roland F. schrieb: > ich jedenfalls > mag C auf Grund der unglaublichen Flexibilität und Anpassungsfähigkeit. Schön für Dich.
svensson schrieb: > Johannes K. schrieb: >> versuche >> deine ersten Programme ohne IDE zu erstellen > > Also, den Rat verstehe ich nicht. Egal für welche Programmiersprache > habe ich immer eine IDE genutzt, weil sie einem so viel Arbeit abnimmt. > Warum soll ich wissen, wie Programme gelinkt werden? Warum soll ich auf > die Dokumentation oder das Syntaxhighlighting verzichten? > > Okay, stimmt nicht ganz: Perl benutze ich auch heute noch im Editor, > aber das ist (auch) eine Scriptsprache. Ich entwickle hauptsächlich unter Linux und da kann fast jeder gewöhnliche Texteditor Syntaxhighlighting. Will darauf auch nicht verzichten. Auf der Konsole ist VIM ganz praktisch. Kommt aber selten vor...
Also ich hab zuerst Basic auf dem Plus4 und C64 gelernt, später dann Assembler und C, anschließend in der Oberstufe Delphi/Pascal, auf der Uni dann wieder C und C++, nach der Uni dann noch aus eigenem Interesse C#. Wenn ich zurück denke muss ich feststellen das für mich Basic und Pascal die am wenigsten brauchbaren Sachen waren, ich bin relativ froh das ich mich kaum noch daran erinnern kann, ich weiß nicht wie oft ich irgendwelche Syntaxprobleme in der Uni hatte weil sich Pascal in meinem C Quelltext eingeschlichen hat. Aber aktuell stehe ich wieder vor der Frage was man am besten lernen bzw. zuerst lernen soll, da ich meiner Tochter etwas mitgeben will und da stehen momentan Assembler, C und Python in der engeren Auswahl, mit durchaus starker Tendenz zu C.
Dr. Sommer schrieb: > Gerade das .net Framework ist unter Windows doch sogar vorinstalliert. Das stimmt schon, aber es hilft Dir nicht weiter wenn Du eine .net-Anwendung benutzen willst die ein anderes Framework benutzt. Da reicht eine einzige Programmzeile aus, die ein anderes Framework als das (die) Installierte(n) erwartet. Aber gern jeder wie er mag.
Zeno schrieb: > Das stimmt schon, aber es hilft Dir nicht weiter wenn Du eine > .net-Anwendung benutzen willst die ein anderes Framework benutzt. Der Installer der Anwendung sollte die benötigte Framework-Version installieren/aktualisieren.
Tim T. schrieb: > Also ich hab zuerst Basic auf dem Plus4 und C64 gelernt, später > dann > Assembler und C, anschließend in der Oberstufe Delphi/Pascal, auf der > Uni dann wieder C und C++, nach der Uni dann noch aus eigenem Interesse > C#. Wenn ich zurück denke muss ich feststellen das für mich Basic und > Pascal die am wenigsten brauchbaren Sachen waren, ich bin relativ froh > das ich mich kaum noch daran erinnern kann, ich weiß nicht wie oft ich > irgendwelche Syntaxprobleme in der Uni hatte weil sich Pascal in meinem > C Quelltext eingeschlichen hat. Aber aktuell stehe ich wieder vor der > Frage was man am besten lernen bzw. zuerst lernen soll, da ich meiner > Tochter etwas mitgeben will und da stehen momentan Assembler, C und > Python in der engeren Auswahl, mit durchaus starker Tendenz zu C. Habe mit BASIC und dann Assembler angefangen. Dann kam C. Bereue ich nicht. War recht angetan als ich beim Buch "Hacking - Die Kunst des Exploits" wieder auf Assembler gestoßen bin. Assembler ist IMHO halt wirklich Grundlage, wenn man bei einem Mikrocontroller wissen will, was tatsächlich abläuft. Auch kann man ohne Assemblerkenntnisse so was nicht machen:
int mystrlen(char *str) { int i; while (str[i++] != '\0') ; return i; } void _start(void) { char *msg = "Hello World!\n"; int len; int result; len = mystrlen(msg); __asm__ __volatile__("movq $1, %%rax;" /* sys_write */ "movq $1, %%rdi;" /* file descriptor stdout */ "syscall;" /* call the kernel */ : "=a"(result) /* return code */ :"S"(msg), "d"(len) /* %rsi <- msg, %rdx <- len */ ); __asm__ __volatile__("movq $60, %rax;" /* sys_exit */ "movq $0, %rdi;" /* return 0 */ "syscall" /* call the kernel */ ); } |
Wäre eine Variante ohne LibC für Linux, das heißt ohne C Overhead. Wüsste nämlich nicht wie man ein Syscall ohne LibC aufrufen kann. PS: Schnell erstellt. Beware of bugs in the above code.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Der Installer der Anwendung sollte die benötigte Framework-Version > installieren/aktualisieren. Selbstverständlich. Und dann noch dies und dann noch jenes. Zeno schrieb: > Gerade das .net Framework ist unter Windows doch sogar vorinstalliert. Und von seinem Umfang her längst ausser Kontrolle geraten. Nein, nicht für den der schon vor vielen Jahren ein- und mit der Zeit langsam durchgestiegen ist sondern immer mehr für den, der da heute noch einsteigen will. Dem TO würde ich dringend raten zunächst von ganz unten auf Assemblerebene einzusteigen und sich mal mit dem Datenblatt des Controllers seiner Wahl in der Hand die Grundlagen zu erarbeiten.
Thomas schrieb: > Und von seinem Umfang her längst ausser Kontrolle geraten. Andere freuen sich über gebotene Funktionalität und ersparte Rad-Neuerfinderei. Thomas schrieb: > Dem TO würde ich dringend raten zunächst von ganz unten auf > Assemblerebene einzusteigen und sich mal mit dem Datenblatt des > Controllers seiner Wahl in der Hand die Grundlagen zu erarbeiten. Um die Lust sofort zu verlieren? So eine Quälerei kann man keinem zumuten.
Dr. Sommer schrieb: > Um die Lust sofort zu verlieren? So eine Quälerei kann man keinem > zumuten. Keineswegs. Einfache Controller sind durchaus mit angemessenem Aufwand zu durchschauen. Viele Zusammenhänge werden plötzlich klarer, man staunt wie kompakt und schnell sich einzelne Dinge umsetzen lassen. Entdeckt gar all jene Fähigkeiten seiner Hardware, von deren Existenz man durch drei Abstraktionsschichten hindurch bislang gar nichts ahnte. Das ist alles andere als langweilig.
Thomas schrieb: > Einfache Controller sind durchaus mit angemessenem Aufwand > zu durchschauen. Dafür hat man bei denen wenig Luft nach Oben. Thomas schrieb: > Viele Zusammenhänge werden plötzlich klarer Klarer? Vorher wusste man gar nichts, plötzlich alles? Thomas schrieb: > wie kompakt und schnell sich einzelne Dinge umsetzen lassen Wie z.B. eine String-Konkatenation? Hast du so gelernt? Ich hatte dieses zweifelhafte Vergnügen zum Glück nicht. Ein Kommilitone musste so in der Schule lernen und hat es gehasst - kann man ihm nicht verdenken. Er hat sich das Programmieren davon aber nicht verderben lassen und trotzdem Informatik studiert, wo man dann mit weniger schmerzhaften Methoden arbeitet (wie eben Java).
Tim T. schrieb: > Also ich hab zuerst Basic auf dem Plus4 und C64 gelernt, > später dann Assembler und C, anschließend in der > Oberstufe Delphi/Pascal, auf der Uni dann wieder C und > C++, nach der Uni dann noch aus eigenem Interesse > C#. Nun ja... manche Leute studieren Maschinenbau mit Schwerpunkt "Konstruktion von Werkzeugmaschinen", und andere machen eine Feinmechanikerlehre (falls Du den Vergleich verstehst). > Wenn ich zurück denke muss ich feststellen das für > mich Basic und Pascal die am wenigsten brauchbaren > Sachen waren, Das für den promovierten Versicherungsmathematiker am wenigsten nützliche Mathebuch in seinem Besitz ist sicherlich sein Grundschullehrbuch "Mathematik". Leitet man daraus korrekt ab, das Grundschulmathematik unnütz ist? > ich bin relativ froh das ich mich kaum noch daran > erinnern kann, ich weiß nicht wie oft ich irgendwelche > Syntaxprobleme in der Uni hatte weil sich Pascal in > meinem C Quelltext eingeschlichen hat. Danke für das Eingeständnis, dass Pascal WESENTLICH intuitiver ist als C... :) > Aber aktuell stehe ich wieder vor der Frage was man > am besten lernen bzw. zuerst lernen soll, da ich meiner > Tochter etwas mitgeben will und da stehen momentan > Assembler, C und Python in der engeren Auswahl, mit > durchaus starker Tendenz zu C. Na logisch. Programmierung darf um Gottes Willen nicht zu einfach werden -- man würde sich ja den Ast absägen, auf dem man selbst sitzt. Und außerdem müssen immaterielle Kulturgüter wie "if (a)" unbedingt erhalten bleiben. Wo kämen wir denn hin, wenn jeder dahergelaufene Gelegenheitsprogrammierer eine Sprache mit einem anständigen Typsystem verwenden würde?
Dr. Sommer schrieb: > Wie z.B. eine String-Konkatenation? Was man wie oft auf einem AVR braucht? Gerade Strings sind ein Beispiel, wieviel C hier verpfuscht, die Leute nehmen die Stringfunktionen, die sie vom PC gewohnt sind, und dann platzt ihnen auf dem AVR der Speicher.
Karl K. schrieb: > Was man wie oft auf einem AVR braucht? Wer redet eigentlich von AVRs? Anstatt mühselig mit einzelnen Bits rumzupfuschen und jedes Schrittchen zum Gewaltmarsch zu machen, sollte man erst ordentlich und strukturiert programmieren lernen. Das geht am Besten in einer höheren Programmiersprache wie Python oder Java auf dem PC. Da hat man auch hilfreiche Tools zur Verfügung. Wenn man erst einmal die logische Programmier-Denkweise hat, kann man immer noch mit der angelernten Routine alle Details des Prozessors in Assembler auskundschaften, wenn das denn unbedingt nötig ist.
Dr. Sommer schrieb: > Karl K. schrieb: >> Was man wie oft auf einem AVR braucht? > > Wer redet eigentlich von AVRs? Der TO sprach von "Arduino", und das legt den Gedanken an einen AVR-Prozessor nahe.
Dr. Sommer schrieb: > Dafür hat man bei denen wenig Luft nach Oben. Die brauchts meist gar nicht, spätestens wenn man es lowlevel effizient unter Nutzung aller Hardware Möglichkeiten hinbekommt. Offensichtlich bist Du aber ohnehin gedanklich woanders als bei der hier diskutierten Hardware > Wer redet eigentlich von AVRs? und solltest konsequenterweise gleich Deine PC-, mindestens aber 32bittige ARM Hardware beim Namen nennen. Da schaut dann vieles ganz anders aus.
Axel S. schrieb: > Wilhelm M. schrieb: >> C ist KEINE Untermenge von C++ > > Nur für Leute, die gern Haare spalten. Eine der wesentlichen Forderungen > an C++ und IMHO die Hauptursache für alle begründeten Rants gegen C++ > [1] war die weitestgehende Kompatibilität von C++ mit C. > > Es war ein Designziel, daß jedes [2] gültige C-Programm auch ein > gültiges C++-Programm sein sollte. Insofern ist C++ also schon als > Obermenge von C bzw. umgekehrt C als Untermenge von C++ gemeint. Du vergisst dabei, dass sich C und C++ unabhängig von einander weiterentwickelt haben und auch C neue Features bekommen hat, die es in C++ erstmal nicht gibt oder die anders sind.
Der letzte Beitrag des TO liegt schon über 24 Stunden zurück. Kann gut sein das all die Ratschläge ihn überfordert haben und er sich ausgeklinkt hat. Nur mal so angemerkt!
Hallo erstaunlicher Weise kann man nahezu jeden Beitrag irgendwie zustimmen, und zwar indem man sich der Sichtweise und den zu vermutenden Hintergrund und Präferenzen des jeweiligen Autors hinein versetzt. Sowohl erst mal strukturiert Programmieren lernen hat was - Wenn man halt umfassend und generell Programmieren können will oder muss, aber wer sagt das so was jeder will?. Aber auch reines C hat was wenn man halt gerne auf Ebene von (8Bit) µC bleiben möchte, viel mehr möchte man als Hobbybastler und Programmiere oft gar nicht. Aber auch direkt mit C++ "Kanonen" auf µC Spatzen zu schießen ist unter Umständen gar nicht so dumm wie es erst mal klingt - man (der TO) bleibt nah am Arduino Konzept, was ja nicht falsch sein muss, außerdem haben wir nicht mehr 1985 wo jedes Bit zählte, Programmiertools generell sehr teuer waren und ein "falsch" programmierter µC (besser Speicher)schon rein von der Hardware entweder viel Arbeit und Zeit benötigte bis ein neuer Versuch gewagt werden konnte (Löschen mittels UV Licht) oder direkt als defekt zu werten war. Aber auch selbst die Assembler Fraktion kann für manche Gruppen sehr interessant sein, nämlich für die Leute welche mehr aus der Hardwareecke kommen und wirklich bis auf unterste Ebene verstehen und "sehen" wollen was mit jeden einzelnen Bit und jeden Register geschieht und den es (vorerst) gar nicht so sehr darauf ankommt das eine bestimmte Funktonalität mit den fertig programmierten µC erreicht wird. Ja selbst den reinen Arduino System Nutzer und Code Kopierer die eigentlich kaum etwas von der Programmierung verstanden haben, kann man bezüglich ihrer Ziele und Anforderungen zustimmen: Für viele Modellbauer (und ähnliche Gruppen) zählt halt nur das fertige Produkt und das sie beim "blinden" Nachbau oft viel Geld (gerade im Modellbau bezahlt man für fertigen "Kram" aus solchen Bereichen sehr viel) sparen und die Effekte der fertigen Anwendung oft recht einfach modifizieren können (bei für solche Gruppen gut kommentierten Programmen - was im Arduino Umfeld öfter der Fall ist und womit "echte" Programmierer seltsamerweise nicht zurecht kommen können weil sie nicht erkennen wollen -oder können?- wer die Zielgruppe ist). Also bitte immer auch Versuchen sich in andere "Welten" hinein zu versetzten und nicht seine Voraussetzungen und Ziele als die umfassende Wahrheit und einzigen richtigen Weg zu sehen, zu unterschiedlich sind die Ansprüche und der jeweilige bedarf. Man sollte halt "Programmieren können" nie zu verbissen und unabhängig von jeweiligen Umfeld sehen - was "können" ist, ist wie überall von den jeweiligen Anforderungen und Ziele abhängig. Ganz unabhängig von Thema Programmierung kann man sich, und anderen, mit solch einer Grundeinstellung das Leben viel einfacher machen und den Blutdruck auf gesunde Werte halten... Jemand
Gurgl schrieb: > Der letzte Beitrag des TO liegt schon über 24 Stunden zurück. Kann gut > sein das all die Ratschläge ihn überfordert haben und er sich > ausgeklinkt hat. Nur mal so angemerkt! Davon ist auszugehen ;-)
Jemand schrieb: > Sowohl erst mal strukturiert Programmieren lernen hat was > > Aber auch direkt mit C++ "Kanonen" > > Aber auch selbst die Assembler Fraktion > > Ja selbst den reinen Arduino System Nutzer und Code Kopierer > > Man sollte halt "Programmieren können" nie zu verbissen und unabhängig > von jeweiligen Umfeld sehen eben, man hat Ziele, wie die erreicht werden ist doch jedem freigestellt, jeder nach seiner Fasson uns eint ein Hobby, es ist kein Glaubenskrieg oder sollte es nicht sein!
Joachim B. schrieb: > eben, man hat Ziele, wie die erreicht werden ist doch jedem > freigestellt, jeder nach seiner Fasson uns eint ein Hobby, es ist kein > Glaubenskrieg oder sollte es nicht sein! Schön und gut, aber einem Threadersteller ist natürlich nicht unbedingt mit solchen diplomatischen Antworten geholfen. Er/Sie sollte allerdings den Background und Ziele besser beschreiben damit die Antwort zielführender ausfallen kann.
Jemand schrieb: > Aber auch reines C hat was wenn man halt gerne auf Ebene von (8Bit) µC > bleiben möchte, viel mehr möchte man als Hobbybastler und Programmiere > oft gar nicht. Danke jemand für deine empathischen Worte. Ich möchte jedoch nochmals anmerken, dass ich in professionellen Bereichen Gründe sehe, auch 64bitter in C zu programmieren. Zwei habe ich oben genannt. Und ja, wir haben diese Erfahrung gemacht, gerade weil unsere C++ Gurus sich immer wieder zerlegen, genauso wie bei Mini-Beispielen hier im Forum. Ja, das gilt nur für wenige Arten von SW. Für die meisten PC-Applikationen sicher nicht. Für das meiste, wo ein Benutzer Daten erstellt und verarbeitet, auch nicht. Und ja, ich hätte auch gedacht, ich bin einfach zu blöd oder alt, doch autosar und Linus haben anscheinend ähnliche Erfahrungen.
A. S. schrieb: > Und ja, wir haben diese Erfahrung gemacht, gerade weil unsere C++ Gurus > sich immer wieder zerlegen, genauso wie bei Mini-Beispielen hier im > Forum. Dann lasst doch die C-Gurus C++ lernen, dann können die damit effizienter arbeiten - Arbeitszeit & Geld gespart.
Dr. Sommer schrieb: > Dann lasst doch die C-Gurus C++ lernen, dann können die damit > effizienter arbeiten - Arbeitszeit & Geld gespart. Dabei wird gern vergessen, dass die mögliche Effizienz von der Länge des Lernwegs samt schlußendlicher Beherrschung der Materie abhängt- da ist monströses C++ nicht gerade im Vorteil, insbesondere bei prozedural vorgeprägten Entwicklern.
Dr. Sommer schrieb: > Dann lasst doch die C-Gurus C++ lernen, dann können die damit > effizienter arbeiten - Arbeitszeit & Geld gespart. wieso sollte man in einer fremden Sprache flüssiger sprechen als die Muttersprachler? Wir haben bei uns doch die gleichen Probleme in C++ wie sie auch hier zu beobachten sind. In vielen Fällen ist C++ (und Python, Ruby, JS, ...) deutlich besser als C, in anderen Fällen (und nur um die geht es mi4r) halt nicht.
A. S. schrieb: > wieso sollte man in einer fremden Sprache flüssiger sprechen als die > Muttersprachler? Wer eine bestimmte Programmiersprache als Muttersprache und alle anderen als Fremdsprachen bezeichnet ist kein Programmierer.
Ich verwende gerne C++ für µCs. Die Sprache hat aber ein Problem das bei all diesen "Diskussionen" gerne ignoriert wird. Die Compiler der Toolchains unterstützen zwar durchweg C++, die Bibliotheken aber nicht oder nur unvollständig. D.h. sobald in einem C++ Code auch nur ein simples
#include <algorithm> |
oder
#include <type_traits> |
auftaucht kann ich mich nicht darauf verlassen das mir diese Funktionalität auch tatsächlich zur Verfügung steht. Crossworks z.B. unterstützt dank g++ zwar grundsätzlich C++17 aber es gibt dort keinen einzigen C++ Header der C++ Lib. Auch der ARMCC scheint nur die RogueWave C++ Lib zu bieten die soweit ich das sehe nicht einmal C++11 unterstützt. Das hält mich freilich nicht davon ab C++ zu benutzen aber wie soll ein Anfänger da vorgehen? C++ Literatur die mir bisher untergekommen ist benutzt von Anfang an die Library. Für unseren Arduino Freund sehe ich schon deshalb nur den Weg über C. Nach und nach kann er dann mit namespaces, templates usw. weitermachen. Aber ein "richtiger Einstieg in C++" ist das vermutlich nicht. Also erst auf dem PC lernen und dann für µC "downgraden"? Wenn das Ziel "C++ für alles" ist - o.k. Aber falls es "nur" um µC geht bin ich da skeptisch. Ich kann das aber nicht beurteilen (und will das auch gar nicht) da mein Einstieg (Basic -> Pascal -> C -> ASM -> C++) schon eine Weile zurückliegt und ich auch nicht auf einem µC angefangen habe. Ich kann mich allerdings noch gut daran erinnern wie froh ich seinerzeit war mit C (Turbo-C 2.0) einen Ersatz für Pascal gefunden zu haben.
Stefan schrieb: > D.h. sobald in einem C++ Code auch nur ein simples Beim AVR-GCC ist die STL nicht dabei. Jawoll! Da hast du wahr. Aber das steht auch genau so in der Produktdefinition. Und Exceptions sind auch (meist) abgeschaltet Bei so wenig Heap sind die STL Container auch nicht wirklich sinnvoll nutzbar. Das new und delete Pärchen ist da kritisch. Und tief in der STL verborgene new/delete sind umso kritischer. Je kleiner das RAM, desto eher wirkt sich die Fragmentierung aus. --- Aber bei den ARM und auch ESP sieht das schon wieder ganz anders aus. Da sollte alles dabei sein. ---
Arduino Fanboy D. schrieb: > Aber bei den ARM und auch ESP sieht das schon wieder ganz anders aus. ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären. Leider ist beides deutlich komplexer und sofort steht parallel die Frage im Raum, brauchts den Overhead für die Anwendung wirklich?
Dr. Sommer schrieb: > Wer eine bestimmte Programmiersprache als Muttersprache und alle anderen > als Fremdsprachen bezeichnet ist kein Programmierer. Ich habe das nicht getan.
Dr. Sommer schrieb: > A. S. schrieb: >> wieso sollte man in einer fremden Sprache flüssiger >> sprechen als die Muttersprachler? > > Wer eine bestimmte Programmiersprache als Muttersprache > und alle anderen als Fremdsprachen bezeichnet ist kein > Programmierer. Wer anhand frei aus der Luft gegriffener Kriterien festlegen will, wer sich Programmierer nennen darf, ist größenwahnsinnig.
Dr. Sommer schrieb: > Der Installer der Anwendung sollte die benötigte Framework-Version > installieren/aktualisieren. Ja er sollte dies tun. Ist aber alles zusätzlicher Aufwand beim Installer und wird halt auch mal gern vergessen. Die A-Karte zieht in dem Fall erst mal der Anwender. Das ist alles Mist, eine naive EXE ist da deutlich besser. Aber das sieht halt jeder anders. Ich persönlich halte von dem .net Kram gar nichts. Bringt keine Vorteile, bläst die Anwendungen unnötig auf und die Anwendungen sind in aller Regel zumindest beim erstmaligen Start schnarchlangsam. Embarcadero scheint ja bei aktuellen Delphi auch wieder vom .net Kram weg zu sein, obwohl es 2005/2006 auch bei Delphi einen großen Hype bezüglich .net gab. Man wir seine Gründe haben warum man das nicht weiter verfolgt.
Thomas schrieb: > Zeno schrieb: >> Gerade das .net Framework ist unter Windows doch sogar vorinstalliert. Zitiere bitte korrekt! Das habe nicht ich geschrieben sondern Dr.Sommer. Ich habe ihn im meinem Post nur zitiert.
Zeno schrieb: > Installer > native Exe Die Dinge sollten einfach gehalten werden. Ein Installer ist da schon überflüssig. Exe starten und gut ist! Der Software Anwender will mit dem Programm arbeiten und nicht mit System Administration/Updates belästigt werden! > (.Net) bläst die Anwendungen unnötig auf Ganz im Gegenteil. Die bleiben schön schlank. Das (richtige) installierte .Net Framework vorausgesetzt.
Egon D. schrieb: > Na logisch. > Programmierung darf um Gottes Willen nicht zu einfach > werden -- man würde sich ja den Ast absägen, auf dem > man selbst sitzt. > Und außerdem müssen immaterielle Kulturgüter wie "if (a)" > unbedingt erhalten bleiben. Wo kämen wir denn hin, wenn > jeder dahergelaufene Gelegenheitsprogrammierer eine > Sprache mit einem anständigen Typsystem verwenden würde? Du bist ja ein richtiger Ketzer, aber Du sprichst mir aus der Seele.
Dr. Sommer schrieb: > A. S. schrieb: >> Und ja, wir haben diese Erfahrung gemacht, gerade >> weil unsere C++ Gurus sich immer wieder zerlegen, >> genauso wie bei Mini-Beispielen hier im Forum. > > Dann lasst doch die C-Gurus C++ lernen, dann können > die damit effizienter arbeiten - Arbeitszeit & Geld > gespart. Was wird denn das?! Peter-Prinzip 2.0? "Jeder Programmierer steigert die Komplexität seiner Werkzeuge so lange, bis er sein Werkzeug nicht mehr beherrscht. Dieses Werkzeug verwendet er dann für den Rest seiner Berufstätigkeit."
Egon D. schrieb: > Jeder Programmierer steigert die Komplexität seiner Werkzeuge Man spürt in manchem Beitrag hier dass die eigentliche Liebe des Autoren jener Komplexität gilt. Motto: Je umfangreicher die Optionen desto flexibler! Im Prinzip jedenfalls.
M. schrieb: > Ganz im Gegenteil. > Die bleiben schön schlank. > Das (richtige) installierte .Net Framework vorausgesetzt. Wenn die Anwendung komplexer wird eben leider nicht. Ich arbeite zur Zeit mit einem Kollegen an der Neuimplementirung einer Software die bisher aus einer naiven Exe und ca. 10 DLL's (Modulen) besteht, Umfang ca. 8MB unkomprimiert (EXE+DLL's sind komprimiert) sind es ca.25-30MB. Das neue Programm in WPF bringt mit seinen Assemblies ca. 150MB auf die Waage, hat aber nur 20% des Funktionsumfanges des alten Programmes. Dafür ist aber auch jeder Scheiß als eigene Klasse implementiert, unabhängig ob das Sinn macht oder nicht. Aber mein Co meint das müsse man so machen. Ok wenn er meint dann ist das eben so. Den Part den ich dort zu programmieren habe ist Gott sei Dank vorzugsweise nur die Mathematik und da komme ich größtenteils, bis auf die Schnittstellen zum Rest des Programmes, procedural durch - oder ich mache es zumindest so- weshalb das Ganze zum Ende hin auch recht schlank ist. Gott sei Dank muß ich mir diesen Zirkus nicht mehr lange anschauen, weil ich in 2 Jahren immer Urlaub habe.
Lernt jemand heute C++ vollständig? Lernt man nicht eher eine Teilmenge davon? Am besten so ab C++ 11 und Rest möglichst meiden.
Herbert schrieb: > Arduino Fanboy D. schrieb: > >> Aber bei den ARM und auch ESP sieht das schon wieder ganz anders aus. > > ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären. Leider > ist beides deutlich komplexer und sofort steht parallel die Frage im > Raum, brauchts den Overhead für die Anwendung wirklich? Und wieder kann man hier nur sagen: OOP ist nur ein Askpekt von C++, der bei den typischen µC Anwendungen, vor allem bei denen, die auf sehr kleinen µC wie den AVR laufen sollen, kaum eine Rolle spielt. Vor allem Laufzeitpolymorphie kann oft durch statische Polymorphie ersetzt werden.
Stefan schrieb: > Ich verwende gerne C++ für µCs. Die Sprache hat aber ein Problem das bei > all diesen "Diskussionen" gerne ignoriert wird. > Die Compiler der Toolchains unterstützen zwar durchweg C++, die > Bibliotheken aber nicht oder nur unvollständig. > > D.h. sobald in einem C++ Code auch nur ein simples
#include
> <algorithm> |
oder
#include <type_traits> |
auftaucht kann ich > mich nicht darauf verlassen das mir diese Funktionalität auch > tatsächlich zur Verfügung steht. Die C++-Standardlib ist zwar für AVR beim GCC nicht da, aber das macht nichts, denn man kann den statischen Teil fast direkt übernehmen. Nur die dynamischen Container gehen mangels new/delete nicht direkt. Aber auch das macht nichts, denn auf den kleinen µC hat man auch kleine Probleme zu lösen, bei denen man die dynamischen Container nicht benötigt.
Herbert schrieb: > ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären. Nein, das sehe ich nicht so! Wenn man die Features der STL voll auskosten will, dann braucht es mehr Speicher! Das ist wohl war. Aber das kann man auch trennen! (ich behaupte, man muss) Denn die OOP Merkmale finden sich in der Sprache, die STL nutzt diese nur. OOP an sich braucht keinen "mehr" Speicher. Denn OOP findet im Kopf statt. Es heißt ja: > Objekt orientierte Programmierung Und eben diese "Orientierung" die findet sich im Kopf und nirgendwo anders. (hinkender) Vergleich: Auch mit einem VW Käfer kann man Sand transportieren. Für eine Baustelle, wirds nicht reichen. Aber für ein Aquarium halt doch. Übrigens: Es finden sich auch STL Implementierungen für den AVR-GCC. Unmöglich, sie zu verwenden, ist es also nicht.
:
Bearbeitet durch User
Stefan schrieb: > Das hält mich freilich nicht davon ab C++ zu benutzen aber wie soll ein > Anfänger da vorgehen? z.B. das Atollic Studio nutzen, welches den Open-Source GCC verwendet, welcher eine komplette C++ Standard Library enthält. Die habe ich auch schon ausführlich benutzt. Den Compiler kann man hier übrigens auch separat herunterladen: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm ARM setzt ja mittlerweile auch auf Clang statt ARMCC. Der unterstützt ebenfalls die Standardbibliothek. Stefan schrieb: > Aber ein "richtiger Einstieg in C++" ist das vermutlich nicht. Also erst > auf dem PC lernen und dann für µC "downgraden"? Das ist sowieso der sinnvollste Weg, egal ob C oder C++. Herbert schrieb: > ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären Das stimmt halt absolut nicht. OOP impliziert nicht dynamische Speicherverwaltung mit new/malloc. Zeno schrieb: > Ja er sollte dies tun. Ist aber alles zusätzlicher Aufwand beim > Installer und wird halt auch mal gern vergessen. Die A-Karte zieht in > dem Fall erst mal der Anwender. So ist das halt, wenn man auf Windows besteht. Unter Linux ist das alles viel einfacher dank Paket-Managern. Zeno schrieb: > Das ist alles Mist, eine naive EXE ist da deutlich besser. Witzig, dass hier die Form der Installation so viel wichtiger zu sein scheint als die Programmier-Paradigmen. Das wäre so als würde man die Form und Technologie von Autos an den Verkaufsraum der Händler anpassen... Zeno schrieb: > Bringt keine Vorteile Der Code läuft direkt auf verschiedenen Prozessoren und man hat eine riesige Bibliothek zur Verfügung, man kann JIT Code generieren und Reflection nutzen. Das ABI ist immer konsistent. Das sind also "keine Vorteile"? M. schrieb: > Exe starten und gut ist! Und wann werden Dateitypen assoziiert, COM-Komponenten registriert, Registry-Einträge z.B. für das "Programme"-Menü angelegt? Bei jedem Start? Das wird nervig. Wo kommen Grafiken, Sounds & Co hin - alle in die eine .exe? Damit die alle beim Start des Programms in den RAM geladen werden? Na super. Egon D. schrieb: > "Jeder Programmierer steigert die Komplexität seiner > Werkzeuge so lange, bis er sein Werkzeug nicht mehr > beherrscht. Man muss C++ nicht komplett beherrschen. Die Nutzung von z.B. std::string steigert die Effizienz schon, wenn man die Details von dessen Implementation nicht kennt.
Dr. Sommer schrieb: > Wer eine bestimmte Programmiersprache als Muttersprache und alle anderen > als Fremdsprachen bezeichnet ist kein Programmierer. Das sehe ich nicht ganz so. Klar: Ein erheblicher Teil der Fertigkeiten eines Programmierers ist unabhängig von der verwendeten Sprache. Aber ich hab schon oft genug gesehen, dass jemand schon in einem Dutzend Sprachen irgendwelche Dinge zusammengefrickelt hat, aber keine der Sprachen dabei wirklich verstanden hat. Der Code ist dann entsprechend grauenvoll. Da ist mir lieber, wenn er nur eine oder zwei Sprachen kann, die dafür aber richtig. Und die Behauptung, dass ein "richtiger Programmierer" in drei Tagen jede beliebige Sprache in Perfektion lernen kann, halte ich für Unsinn. Herbert schrieb: > Arduino Fanboy D. schrieb: > >> Aber bei den ARM und auch ESP sieht das schon wieder ganz anders aus. > > ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären. Nicht OOP, sondern die Standardbibliothek (bzw. große Teile davon), da sie viel dynamischen Speicher nutzt, den man auf kleinen µCs so weit wie möglich zu vermeiden versucht. M. schrieb: >> (.Net) bläst die Anwendungen unnötig auf > > Ganz im Gegenteil. > Die bleiben schön schlank. > Das (richtige) installierte .Net Framework vorausgesetzt. Genau, das Programm bleibt schlank, braucht aber das eine oder andere Gigabyte an .net-Framework. Und dann braucht jedes Programm sein eigenes, da jedes eine andere Version will und die ganzen Versionen natürlich untereinander nicht kompatibel sind. Dann habe ich für fünf "schlanke" Programme nachher etliche Gigabytes an .net-Framework installiert.
Rolf M. schrieb: > Nicht OOP, sondern die Standardbibliothek (bzw. große Teile davon), "groß" ist relativ. Die Bibliothek bietet noch eine Menge weiterer sehr nützlicher Dinge. Klassisches Beispiel ist std::max - sehr praktisch und in C unmöglich genau so gut nachzubauen. Dieser Code nutzt z.B. die Standard-Bibliothek und ist Mikrocontroller-geeignet: Beitrag "Re: IntToHex function"
Dr. Sommer schrieb: > Rolf M. schrieb: >> Nicht OOP, sondern die Standardbibliothek (bzw. große Teile davon), > > "groß" ist relativ. Die Bibliothek bietet noch eine Menge weiterer sehr > nützlicher Dinge. Klassisches Beispiel ist std::max - sehr praktisch und > in C unmöglich genau so gut nachzubauen. > > Dieser Code nutzt z.B. die Standard-Bibliothek und ist > Mikrocontroller-geeignet: > Beitrag "Re: IntToHex function" Mir kommt es irgendwie so vor, als ob da ein Haufen Code geschrieben wird, der am Ende nie gebraucht wird. Halt nur für den Fall, dass wenn mal... Als Programmierer alter Schule bin ich es gewohnt mit unterschiedlichen Datentypen umzugehen. Wenn ich 2 Integer vergleichen will, teste ich (a>b), wenn ich a mit einem Array vergleichen will, schreibe ich eine entsprechende Funktion dafür. Das alles immer mit einer Funktion abgekaspert werden kann, finde ich unnötig und auch verwirrend. Genauso bei deinem Beispiel "int2hex". Da würde ich mir klassischerweise eine Funktion schreiben, die einen 32-bit Wert verarbeiten kann, und ich übergebe die Länge, wie breit mein Datenwort ist. int2hex (char *str, uint32_t value, uint8_t size) { ... } Wenn ich nun einen uint8 in hex umwandeln möchte, kann ich den uint8 auch direkt an die Funktion übergeben. Der Compiler castet den uint8 auf uint32. Kein Problem.
:
Bearbeitet durch User
Joe F. schrieb: > Das alles immer mit einer Funktion abgekaspert werden kann, finde ich > unnötig und auch verwirrend. Viele finden es sehr praktisch, Code nur 1x schreiben zu müssen. Joe F. schrieb: > Da würde ich mir klassischerweise eine Funktion schreiben, die einen > 32-bit Wert verarbeiten kann, und ich übergebe die Länge, wie breit mein > Datenwort ist. Und was, wenn du ein 64bit-Wort umwandeln willst? Dann brauchst du eine 2. Funktion. Oder du machst immer 64bit, und ziehst auf nicht-64bit-Rechnern immer 32 unnötige Bits mit. Ineffizient. Joe F. schrieb: > Der Compiler castet den uint8 auf > uint32. Kein Problem. Gerade auf 8-Bit-Controllern hat man dann die 4-Fache Zeit verschwendet. Und es heißt doch immer dass C++ so viel Overhead hätte... Mit templates kann man natürlich noch viel komplexere Dinge anstellen, die ohne templates unmöglich sind. Int2Hex ist hier nur ein Mini-Beispiel.
Dr. Sommer schrieb: > Gerade auf 8-Bit-Controllern hat man dann die 4-Fache Zeit verschwendet. > Und es heißt doch immer dass C++ so viel Overhead hätte... Wenn ich auf 8-Bittern Overhead vermeiden will, nehm ich als Erstes eine Sprache, die nicht alle Byte-Variablen auf 16 Bit aufbläst, "weil es der Standard so vorsieht".
Joe F. schrieb: > int2hex (char *str, uint32_t value, uint8_t size) { ... } Zwischen str und size besteht ggf. ein Zusammenhang. Wie drückst Du das hier aus?
Karl K. schrieb: > Dr. Sommer schrieb: >> Gerade auf 8-Bit-Controllern hat man dann die 4-Fache Zeit verschwendet. >> Und es heißt doch immer dass C++ so viel Overhead hätte... > > Wenn ich auf 8-Bittern Overhead vermeiden will, nehm ich als Erstes eine > Sprache, die nicht alle Byte-Variablen auf 16 Bit aufbläst, "weil es der > Standard so vorsieht". I dare you. Bitte erklär mir den Code im Link. Am besten noch ohne Dr. Sommers eigene Erklärung direkt unter dem Schnipsel zu lesen.
Vincent H. schrieb: > Bitte erklär mir den Code im Link. Was gibts da zu erklären? Eine IntToHex Funktion, die erstmal 40 Byte Zeichenbuffer braucht - da muss ich nicht weiterlesen um zu wissen dass das scheisse ist. Meine IntToHex Funktionen für Avr schreiben auch nicht erst in einen extra Buffer, sondern direkt dahin, wo ich die Zeichen brauche, also ans Display oder an die Rs232. Wahlweise in den Displaybuffer, dann aber direkt an die gewünschte Position. Und meine IntToHex Funktionen haben eine feste Zeichenlänge, denn anders als bei Dez will ich bei Hex nicht je nach Wert 5, A5, 34AF haben, sondern ordentlich formatierte 0005, 00A5, 34AF. Spätestens wenn man z.B einen Memdumb über die Rs232 ausgibt weiss man das zu schätzen. Der Rest des Codes ist halt stupide Hex Wandlung, und da bringt C++ so gar keinen Vorteil, das sah in Basic schon vor 30 Jahren nicht anders aus.
Karl K. schrieb: > Meine IntToHex Funktionen für Avr schreiben auch nicht erst in einen > extra Buffer, sondern direkt dahin, wo ich die Zeichen brauche, Es gibt jenseits von AVR auch Controller welche DMA haben. Und DMA braucht zu sendende Blöcke (z.B. via UART oder SDIO) fertig am Stück. Da kann man nicht "On demand" jedes Zeichen einzeln berechnen. Außerdem verschwendest du so auch viel Zeit mit warten; da wäre die Verwaltung eines 40-Byte-Puffers auch halb so schlimm. Karl K. schrieb: > denn anders > als bei Dez will ich bei Hex nicht je nach Wert 5, A5, 34AF haben, Du vielleicht. Aber stell dir vor, es gibt auch andere Anforderungen... Karl K. schrieb: > das sah in Basic schon vor 30 Jahren nicht anders > aus. Konnte Basic das auch mit einer Funktion für alle Datentypen?
Wilhelm M. schrieb: > Vor allem > Laufzeitpolymorphie kann oft durch statische Polymorphie ersetzt werden. Arduino Fanboy D. schrieb: > Aber das kann man auch trennen! (ich behaupte, man muss) > Es finden sich auch STL Implementierungen für den AVR-GCC. > Unmöglich, sie zu verwenden, ist es also nicht. Alles tausend Verrenkungen um zu einem Code zu gelangen den man althergebracht auch direkt gleich mit C schreiben kann. So hört sich das für mich an. Dr. Sommer schrieb: > Und wann werden Dateitypen assoziiert, COM-Komponenten registriert, > Registry-Einträge z.B. für das "Programme"-Menü angelegt? Bei jedem > Start? Das wird nervig. Das könnte eigentlich Aufgabe des Betriebssystems sein. Es würde aber langen, sich seine .Exe auf den Deskop zu legen. > Wo kommen Grafiken, Sounds & Co hin - alle in > die eine .exe? Ja sicher, selbst wenn es dafür eine sinnvolle Obergrenze geben mag. > Damit die alle beim Start des Programms in den RAM > geladen werden? Na super. Ja das ist super. Vor allem schnell. Hast Du keinen aktuellen PC? Du scheinst mir überhaupt sehr in der Vergangenheit zu leben.
Jonas schrieb: > Wilhelm M. schrieb: >> Vor allem >> Laufzeitpolymorphie kann oft durch statische Polymorphie ersetzt werden. > > Arduino Fanboy D. schrieb: >> Aber das kann man auch trennen! (ich behaupte, man muss) >> Es finden sich auch STL Implementierungen für den AVR-GCC. >> Unmöglich, sie zu verwenden, ist es also nicht. > > Alles tausend Verrenkungen um zu einem Code zu gelangen den man > althergebracht auch direkt gleich mit C schreiben kann. So hört sich das > für mich an. Da hast Du recht: Laufzeitpolymorphie und Liskov ist dort, wo es nicht benötigt wird, tatsächlich eine Verrenkung. Aber das ist kein Argument für C, sondern für C++.
Jonas schrieb: > Alles tausend Verrenkungen um zu einem Code zu gelangen den man > althergebracht auch direkt gleich mit C schreiben kann. So hört sich das > für mich an Autos und Busse sind auch nur unnötige Verrenkungen um an Orte zu gelangen, zu denen man auch laufen kann. Jonas schrieb: > Das könnte eigentlich Aufgabe des Betriebssystems sein. Es würde aber > langen, sich seine .Exe auf den Deskop zu legen. Und woher soll das Betriebssystem wissen, wann die exe zum ersten Mal auf den Rechner gelangt ist und diese Operationen ausgeführt werden müssen? Und vor allem, wann es wieder deinstalliert werden muss? Jonas schrieb: > Hast Du keinen aktuellen PC? D Meine mageren 16 GB RAM sind leider nicht genug, um von allen laufenden Programmen alle Ressourcen ständig zu laden. Das dumme Synaptics Konfig Tool hat ja sogar Videos. Müssen die ständig geladen sein? Festplatte voll machen ist also egal, aber RAM voll machen ist ok? Ist klar.
Karl K. schrieb: > Meine IntToHex Funktionen für Avr schreiben auch nicht erst in einen > extra Buffer, sondern direkt dahin, wo ich die Zeichen brauche, also ans > Display oder an die Rs232. Wahlweise in den Displaybuffer, dann aber > direkt an die gewünschte Position. Code or GTFO.
Also Dr. Sommer, ich bleibe bei dem ganzen um ettliche Ecken denkenden Sprachaufwand lieber bei prozeduralem C. Das ist mir bei aller ach so eingängiger "Objekt" verherrlichung immer noch zehnmal intuitiver. Auf dem Controller mags in Einzelfällen nicht der entwicklungszeit- effizienteste Ansatz sein, dafür habe ich die Ausbildungszeit hin zum Dr. Titel gespart :) Dr. Sommer schrieb: > Meine mageren 16 GB RAM sind leider nicht genug, um von allen laufenden > Programmen alle Ressourcen ständig zu laden. Mit Übertreibung wirds nicht überzeugender. Für tausende einfache Programme langts locker und vereinfacht Abläufe und Handling ungemein. Für Freunde kryptischer Betriebssysteme mag die Sache ja anders ausschauen. Aber nein, ich hab nix gegen Linux :))
Tachhh zusammen, also wenn du "C" am Atmel lernen willst. Nimm das Buch ISBN 9783895762000 um die 27€ und dann hast du eine gute Grundlage um direkt in C deinen Atmel zu verstehen. Gruß Thomas
Dr. Sommer schrieb: > Und woher soll das Betriebssystem wissen, wann die exe zum ersten Mal > auf den Rechner gelangt ist und diese Operationen ausgeführt werden > müssen? Und vor allem, wann es wieder deinstalliert werden muss? So ist das eben wenn man nur in alten Kategorien denkt. Man bekämpft Probleme die man gar nicht haben müsste. Eine moderne .exe bräuchte die Installation nicht zwingend. Muss deshalb auch nicht deinstalliert werden. Bringt mit was sie braucht und greift ansonsten auf das zurück was das Betriebssystem standardmäßig mitbringt. Einträge ins Startmenü könnte das OS auch von allein veranlassen wenn es denn nötig wäre. So einfach ist das. Stellst Du den Sinn portabler Apps generell in Frage?
Jonas schrieb: > Das ist mir bei aller ach so > eingängiger "Objekt" verherrlichung immer noch zehnmal intuitiver. Hunderttausend-Arduino-User finden es intuitiv dass Serial.print und Serial1.print und Serial2.print exakt gleich funktionieren, und man viele verschiedene Datentypen übergeben kann die dann automatisch richtig ausgegeben werden, ohne so kryptische Dinge wie "%s" und "%d" und "%llu" auswendig zu wissen. Da braucht's auch keinen Dr.-Titel für. Jonas schrieb: > Für tausende einfache Programme langts locker und vereinfacht Abläufe > und Handling ungemein. Das ist doch nur ein Workaround um das miese Deployment unter Windows. Jonas schrieb: > Aber nein, ich hab nix gegen Linux :)) Unter Linux ist das noch viel schlimmer: Da gibt es keine richtigen Ressourcen-Blöcke in den ausführbaren Dateien, die Programmdateien haben nichtmal Icons. Stattdessen sind quasi alle Ressourcen extern unter /usr/share/<Programmname> abgelegt, vom Icon bis zur Sprachdatei. Die sind nichtmal zusammen mit dem Programm im selben Ordner. Trotzdem ist das Handling super einfach - über den Paketmanager kann man alles blitzschnell installieren, aktualisieren und löschen. Sogar viele Programme auf einmal.
Jonas schrieb: > Einträge ins Startmenü > könnte das OS auch von allein veranlassen wenn es denn nötig wäre. Seit wann macht Windows so etwas? Installiert es automatisch Explorer-Plugins und Datei-Assoziationen? Jonas schrieb: > Stellst Du den Sinn portabler Apps generell in > Frage? Stellst du den Sinn einer guten Integration von Programmen ins System in Frage? So Dinge wie TortoiseSVN können ohne Installation nicht funktionieren. Wie aktualisierst du eigentlich solche Single-Exe-Programme? Jedes mal die .exe komplett neu herunterladen, auch wenn sie riesig ist?
Jonas schrieb: > Für tausende einfache Programme langts locker und vereinfacht Abläufe > und Handling ungemein. Für Freunde kryptischer Betriebssysteme mag die > Sache ja anders ausschauen. Aber nein, ich hab nix gegen Linux :)) Unter Linux wird die selbe Library auch nur einmal in den speicher geladen. Dank dem Packetmanager und den Buildsystemen der Distros werden die Programme fast immer sogar mit den selben Library und Framework Versionen kompiliert, so das man dann nur eine Version dieser braucht. Natürlich versucht man mittlerweile auch, das mit Flatpacks, Snaps, Containern und AppImages zu korrigieren.
Dr. Sommer schrieb: > Seit wann macht Windows so etwas? Nein macht es nicht. Deshalb ja nur könnte. > Installiert es automatisch > Explorer-Plugins und Datei-Assoziationen? Ist das bei jedem Programm zwingend? Windows fragt übrigens selber nach und lässt zuordnen. > Stellst du den Sinn einer guten Integration von Programmen ins System in > Frage? Nein. Aber warum schließt das eine jetzt das andere aus? > So Dinge wie TortoiseSVN können ohne Installation nicht > funktionieren. Das mag ja gut sein Dr. Sommer. Dann installiert man es halt. Hat ja niemand behauptet dass man den Installer abschaffen muss. > Wie aktualisierst du eigentlich solche Single-Exe-Programme? Jedes mal > die .exe komplett neu herunterladen, auch wenn sie riesig ist? Selbstverständlich. Denn die Programme von denen ich hier rede sind weder riesig noch bei heutigem Speed langwierig herunterzuladen.
Du redest immer nur von Mini-Programmen. Simple Programme kann man "irgendwie" programmieren, da ist die Methodik ziemlich egal. Das eigentliche Geld wird aber mit komplexen Software-Paketen gemacht. Daher geht es beim Programmieren meistens darum, skalierbare Paradigmen zu lernen und nicht "einfach" alles in Assembler runterzuhacken. Dazu gehört eben auch die Nutzung von Frameworks wie .net oder Java. Würdest du Altium Designer oder MS-Office auch als einzelne .exe verteilen?
Dr. Sommer schrieb: > Das > eigentliche Geld wird aber mit komplexen Software-Paketen gemacht. Schön. Deshalb sollte man trotzdem die einzelne .exe anstreben, wenn auch nicht für Riesensoftware wie > Altium Designer oder MS-Office > Dazu > gehört eben auch die Nutzung von Frameworks wie .net oder Java. ... was die eigentlichen ".exe" Programme dann auch schön kompakt hält. Ein anderer Weg. Die Problematik mit den unterschiedlichen Forderungen nach bestimmten .net Versionen wurde allerdings schon angesprochen. Da geht das Kuddelmuddel wieder los.
> Bin für jeden Ratschlag dankbar ^^ Die Antwort gibt es wie immer im Netz: https://www.electronicsplanet.ch/mikrocontroller/avr-tutorial-c/avr-tutorial-c.htm PS: Die Grundsatzdiskussion ist völlig am Thema vorbei bzw. Arduino & C++ kann man vergessen.
ohne Account schrieb: >> Bin für jeden Ratschlag dankbar ^^ > Die Antwort gibt es wie immer im Netz: > https://www.electronicsplanet.ch/mikrocontroller/avr-tutorial-c/avr-tutorial-c.htm Dieses Tutorial ist für C-Programmierer, also für diejenigen, die das, was der TE erst lernen will, schon können.
> Dieses Tutorial ist für C-Programmierer, also für diejenigen, die das, > was der TE erst lernen will, schon können. da sind auch Buchhinweise, usw., sollte also für den Anfang ausreichen.
> Dieses Tutorial ist für C-Programmierer, also für diejenigen, die das, > was der TE erst lernen will, schon können. ansonsten C für PCs von Kirch-Prinz, etc.
Gemgod schrieb: > Ich habe ich in den letzten Monaten mit dem Arduino beschäftigt ujd > würde sagen bin auch ganz gut darin. Da der Arduino einem jedoch > ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen. Nunja, Grundlagen wie Funktionen aufrufen, Schleifen und Bedingungen verstehst du ja jetzt schon, nehme ich an. Man kann jetzt natürlich auf Abstraktionen wie Arduino verzichten, um lowlevel zeug zu lernen. Aber um C wirklich voll Ausschöpfen zu können, würde ich empfehlen Datenstrukturen, Funktionspointer und das entwerfen von sauberen Interfacen zu lernen. Ein paar Algorithmen können auch nicht schaden. Für den Anfang würde ich mal empfehlen, Programme möglichst immer in Subsysteme zu teilen, wo dies sinvoll, also unabhängige teile sind. Häufig gibt es eine init funktion für das Subsystem oder Instanzen davon. Die Daten von diesen packt man dann am besten immer gleich in ein Struct. Wichtige Datenstrukturen sind z.B. linked lists, doubly linked lists, Ringbuffer, Stacks und Queues, usw. Bei unterschiedlichen Programmteilen und Subsystemen sind einfache und stabile Interfaces empfehlenswert, das braucht etwas Übung. Ein Interface kann in C eine Headerdatei und die darin aufgelisteten Funktionen sein. Du kannst stattdessen aber auch Funktionspointer in Structs packen. Das ist unter anderem eine Methode, wie man das Dependency-Inversion-Prinzip[1] in C anwenden kann. Einfach darauf achten, welche Richtung sinn macht, also was von was abhängt. Man kann so auch mehrere Implementierungen des selben Interface/Subsystem haben, oder es auch einfacher austauschen, usw. In paar Beispiele von dem Pattern, wo ich es verwendet habe: * Die Backends meines kleinen gles dmabuffer Beispiels: - https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/src/egl_x11.c#L100 - https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/include/internal/engine.h - https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/src/engine.c#L344 * Die backends meiner libttymultiplex library: - https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/backend/curses.c#L264 - https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/include/internal/backend.h - https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/backend.c#L35 * Diverse Treiber meines (immernoch unvollständigen) DPA-UCS Projektes: - https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/headers/DPA/UCS/driver/ethernet.h - https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/generic/dummy.c#L22 - https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/generic/enc28j60.c#L19 - https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/linux/ethernet.c#L193 * etc. Und dann eventuell noch ein paar grundlegende Algorithmen üben, z.B. bubble sort, state machines, einfache parser, und solches zeug üben. 1) https://de.wikipedia.org/wiki/Dependency-Inversion-Prinzip
Dr. Sommer schrieb: > Es gibt jenseits von AVR auch Controller welche DMA haben. Es geht um AVR Controller. > verschwendest du so auch viel Zeit mit warten; da wäre die Verwaltung > eines 40-Byte-Puffers auch halb so schlimm. Wenn ich nicht warten will, nehme ich einen Tx-Ringbuffer. Dann schreibe ich das Zeichen so wie jedes andere Zeichen über die Schreibroutine des Ringbuffers. Denn auf einen Ringbuffer schreiben kann Deine Funktion nicht, und muss wieder unnötig rumkopieren. > Du vielleicht. Aber stell dir vor, es gibt auch andere Anforderungen... Und da Deine Funktion diese Anforderung nicht abdeckt - muss man eh ne neue schreiben. > Konnte Basic das auch mit einer Funktion für alle Datentypen? Ja, natürlich. Wenn Datentypen Ganzzahlen meint. Dieses ganze Rumgehüpfe mit OOP und C++ klaschiert doch nur, dass der µC letztlich prozedural arbeitet - da kann man auch prozedural programmieren. Mehr als Code Obfuscation kommt doch bei Deinem Kram nicht raus. Aber wahrscheinlich ist es genau das, was Du willst: Huh, das sieht aber kompliziert aus. Und schon bist Du der unersetztliche Guru. Wers braucht...
Hallo "Das ist doch nur ein Workaround um das miese Deployment unter Windows." "Mehr als Code Obfuscation kommt doch bei Deinem Kram nicht raus. Aber wahrscheinlich ist es genau das, was Du willst: Huh, das sieht aber kompliziert aus." und so manches mehr Ich dachte es handelt sich hier um ein deutschsprachiges Forum in dem englischsprachige Begriffe nur dann verwendet werden wenn diese allgemein bekannt sind und es keine sinnvolle deutschsprachigen Begrifflichkeiten gibt?! Ist den Autor Karl K. eigentlich die wohl ungewollte Ironie in seinen Beitrag aufgefallen? "Mehr als Code Obfuscation .....Huh, das sieht aber kompliziert aus." Hennes
Karl K. schrieb: > Dieses ganze Rumgehüpfe mit OOP und C++ klaschiert doch nur, dass der µC > letztlich prozedural arbeitet - da kann man auch prozedural > programmieren. Mehr als Code Obfuscation kommt doch bei Deinem Kram > nicht raus. Aber wahrscheinlich ist es genau das, was Du willst: Huh, > das sieht aber kompliziert aus. Und schon bist Du der unersetztliche > Guru. Wers braucht... Schau, es is ganz einfach. Du bezeichnest anderer Leute Code als "scheiße", postest aber selbst kein einziges Beispiel sondern reißt nur deppat die Goschn auf wie was wieso weshalb warum. Der Rest von dem Buchstabensalat den du von dir gibst kann man sonst eh nicht ernst nehmen. "Es arbeitet prozedural also muss ma prozedural programmieren." Oida wos? Wie arbeiten denn dann Rechenzentren? Oder das vorher erwähnte Office... aber hey, das is sicher auch in C geschrieben, muss ja schließlich prozedural arbeiten. Oida Schwed herst, bei diesem Forum schmeißt echt die Nerven...
Karl K. schrieb: > Dr. Sommer schrieb: >> Konnte Basic das auch mit einer Funktion für alle Datentypen? > > Ja, natürlich. Wenn Datentypen Ganzzahlen meint. Die einzigen Datentypen, die Du kennst, sind Ganzzahlen? Dann gehörst Du sicher auch zu der Fraktion: alles ist ein "string", und wenn nicht, dann ein "int".
Wilhelm M. schrieb: > Die einzigen Datentypen, die Du kennst, sind Ganzzahlen? Bist Du dumm? > Dr. Sommer schrieb: >>> Konnte Basic das auch mit einer Funktion für alle Datentypen? Offensichtlich ist eine IntToHex-Funktion für Strings oder Floats unsinnig. Daher hat Mr. Sommer mit "alle Datentypen" wahrscheinlich Ganzzahlen, sprich Int, Word, Byte... gemeint. Da auf ein einfaches "Ja" garantiert der Nächste mit "für Float aber nicht, mimimi" gekommen wäre meine Einschränkung: Ganzzahlen.
Karl K. schrieb: > Es geht um AVR Controller. Seit wann? Karl K. schrieb: > Dann schreibe > ich das Zeichen so wie jedes andere Zeichen über die Schreibroutine des > Ringbuffers. Also für jedes Zeichen ein Funktionsaufruf. Lahm. memcpy hingegen ist schön optimiert. Karl K. schrieb: > Denn auf einen Ringbuffer schreiben kann Deine Funktion > nicht, und muss wieder unnötig rumkopieren. Statt eines char* hätte ich auch einen generischen Typ verwenden können, an den man dann Iteratoren übergeben könnte. Dann kann man sowohl Array-Zeiger als auch Output-Iteratoren übergeben, d.h. der Aufrufer hätte die Wahl zwischen direkter Ausgabe oder Ausgabe ins Array. Karl K. schrieb: > Ja, natürlich. Wenn Datentypen Ganzzahlen meint. Wie funktioniert das denn? Dynamische Typisierung (langsam, unsicher), Generische Programmierung (genau wie C++) oder durch Nutzung eines größten Typs (langsam)? Karl K. schrieb: > Dieses ganze Rumgehüpfe mit OOP und C++ klaschiert doch nur, dass der µC > letztlich prozedural arbeitet - da kann man auch prozedural > programmieren. Genau das ist der Trugschluss. Warum muss man seine Denkstrukturen exakt so sortieren wie die Hardware? Wenn man auf einer abstrakteren Ebene arbeitet, kann man die Abläufe, Probleme und Datenstrukturen so formulieren wie sie sind, wie man sie leichter begreifen, beschreiben und auch abändern kann. Die Arbeit des Anpassens an die Hardware lässt man dann den Compiler machen. Ich bin gespannt was du zu funktionaler Programmierung, oder Prolog sagen würdest. Die Schreibweise hat da überhaupt nichts mit der prozeduralen Arbeitsweise von Prozessoren zu tun. Bei den Problemen, auf die diese Sprachen passen, sind die Programme sehr kompakt und verständlich. Nur weil man die auch prozedural formulieren "kann", ist das noch lange nicht besser. Karl K. schrieb: > Huh, > das sieht aber kompliziert aus. Und schon bist Du der unersetztliche > Guru. Wers braucht... An einem anderen Beispiel wird es deutlicher: C++:
std::string x = "Hallo, " + name + "! Du hast " + std::to_string(mem) + " MB Speicher verbraucht."; |
C:
#define FORMAT "Hallo, %s! Du hast %zu MB Speicher verbraucht." char* buf = malloc (1024); if (!buf) { errno = ENOMEM; return -1; } size_t x = snprintf(buf, 1024, FORMAT, name, mem); if (x >= 1024) { buf = realloc (buf, x+1); if(!buf) { errno = ENOMEM; return -1; } snprintf(buf, x+1, FORMAT, name, mem); } |
Was sieht jetzt komplizierter aus? Was ist leichter durch einen Anfänger zu schreiben und abändern? Hennes schrieb: > Ich dachte es handelt sich hier um ein deutschsprachiges Forum Dann nenne doch mal sinnvolle, wohlbekannte deutsche Begriffe, die nicht einfach nur eingedeutscht sind ("k" statt "c")...
Dr. Sommer schrieb: > Seit wann? Seit dem ersten Beitrag des Threads. Wenn jemand "Arduino" sagt, gehe ich erst mal vom ATmega328 (uno, nano) oder anderen AVR aus, die sind auf den meisten Boards. Wenn er ein Board mit ARM haben sollte, möge er das bitte spezifizieren. Dr. Sommer schrieb: > memcpy hingegen ist > schön optimiert. Memcpy kann in einen Ringbuffer schreiben? Dr. Sommer schrieb: > Wenn man auf einer abstrakteren Ebene > arbeitet, kann man die Abläufe, Probleme und Datenstrukturen so > formulieren wie sie sind Wenn ich einen Sensor an einem Mikrocontroller habe, denke ich mir: Der soll initialisiert werden, der soll die Messung starten, der soll den Messwert abholen und der soll den Messwert umrechnen und anzeigen / ausgeben. Was soll man sich da anders denken? Was soll OOP hier bringen? Dr. Sommer schrieb: > Ich bin gespannt was du zu funktionaler Programmierung, oder Prolog > sagen würdest. Prolog auf einem µC? Prolog hat eine völlig andere Aufgabenstellung.
Karl K. schrieb: > Memcpy kann in einen Ringbuffer schreiben? Klar, wenn der Puffer clever programmiert ist und nicht nur byteweise arbeitet. Karl K. schrieb: > Seit dem ersten Beitrag des Threads. Wenn jemand "Arduino" sagt, gehe > ich erst mal vom ATmega328 (uno, nano) oder anderen AVR aus Ich nicht. Karl K. schrieb: > Was soll man sich da anders denken? Was soll OOP hier bringen? Beispielsweise eine Abstrahierung der Hardware-Schnittstelle. Wenn man für den Zugriff auf einen I²C-Sensor die Arduino-I²C-Klasse "Wire" nimmt, kann man unabhängig von der tatsächlichen Schnittstelle den Sensor benutzen. Wenn man eine abstrakte "GPIO"-Klasse hat, die dann für Prozessor-Eigene GPIO-Pins und für per I²C- und SPI-Portexpander angebundene Pins implementiert, kann eine Sensoransteuerung, welche GPIOs braucht, diese komplett transparent nutzen. Dadurch wird der Code kompakt und portabel. Karl K. schrieb: > Prolog auf einem µC? Prolog hat eine völlig andere Aufgabenstellung. Ja, aber sowohl Desktop- als auch µC-Prozessoren arbeiten vom Grundsatz her prozedural. Daher würde dein Argument genauso lauten "Prolog arbeitet nicht wie der Prozessor prozedural und ist daher sinnlos".
Dr. Sommer schrieb: > std::string x = "Hallo, " + name + "! Du hast " + std::to_string(mem) + > " MB Speicher verbraucht."; Hier mal in Arduino:
void setup() { Serial.begin(9600); char name[] = "Walter"; int mem = 4711; Serial.println(String() + "Hallo, " + name + "! Du hast " + mem + " MB Speicher verbraucht."); } |
Vielleicht nicht die Ressourcen schonendste Variante, aber schön Bequem.
:
Bearbeitet durch User
Hallo, Dr. Sommer schrieb: > Karl K. schrieb: >> Seit dem ersten Beitrag des Threads. Wenn jemand "Arduino" sagt, gehe >> ich erst mal vom ATmega328 (uno, nano) oder anderen AVR aus > > Ich nicht. Und woran denkst du wenn im Eingangsbeitrag von "dem Arduino" die Rede ist? rhf
Roland F. schrieb: > Und woran denkst du wenn im Eingangsbeitrag von "dem Arduino" die Rede > ist? z.B. an den Olimexino-STM32 oder den Arduino Due. Außerdem war nicht klar formuliert dass C ausschließlich für den (AVR-) Arduino gelernt werden soll. Ferner ist es sowieso sinnvoll, nicht nur für die eingeschränkte AVR-Arduino-Welt programmieren zu lernen. Mit PC-Programmierung anzufangen ist eh praktikabler.
Die Frage, was "Gemgod" möchte, interessiert die Diskussionsteilnehmer schon lange nicht mehr. Was kein Wunder ist, da "Gemgod" sie in keiner Weise an der Diskussion beteiligt. Ich denke, er wollte bloß dieses Thema in de Raum werfen, um sich an der darauf folgenden hitzigen und abschweifenden Diskussion der immer gleichen Personen zu belustigen. Ganz ehrlich: Wer hier eine Empfehlung für eine Programmiersprache oder einen Mikrocontroller sucht, der ist völlig verloren. Da ist jedes noch so schlechte Youtube Video hilfreicher - oder eine ernsthaftes Gespräch mit Nachbars Hund.
So Moinsen an alle. Tut mir sehr leid für die späte Antwort, aber die Klausuren haben mich schon alle sehr beschäftigt. Ganz schön viele Antworten Danke dafür erstmal^^. War mir schon klar dass es viele verschiedene Meinungen gibt. Ich habe zwischendurch was von einem Volkshochschulkurs gehört was mir auch schon nahegelegt wurde, denke das werde ich in Angriff nehmen Außerdem habe ich mir auch ein Buch bestellt. Bin ich mal gespannt. Von zeigern habe ich zwischendurch auch was gelesen. Das fande ich sehr Interessant und werde ich mal näher mit beschäftigen. Danke Mfg
Thread beobachten
Seitenaufteilung abschalten