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.
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.
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.
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.
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.
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.
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ß...
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.
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:> Tim T. schrieb:>> Wilhelm M. schrieb:>>> BTW:>>>>>> "Stop teachung C">>>>>> https://www.youtube.com/watch?v=YnWhqhNdYyk>>>> 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.
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.
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.
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.
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.
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.
1
int main()
2
{
3
// geht nicht in c++
4
int b(a) int a; { }
5
6
// geht nicht in c++
7
struct A { struct B { int x; } y; int xy; };
8
struct B y;
9
10
// geht nicht in c++
11
auto z;
12
13
// geht nicht in c++
14
int a[1];
15
int (*ap)[] = &a;
16
17
return 0;
18
}
p.s. Und nein, ich kann nicht gut C und behaupte das auch nicht.
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!
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:
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.
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
1
#include<algorithm>
oder
1
#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.
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
1
#include
2
><algorithm>
oder
1
#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.
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-rmARM 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.
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.
> 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.
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++:
1
std::stringx="Hallo, "+name+"! Du hast "+std::to_string(mem)+" MB Speicher verbraucht.";
C:
1
#define FORMAT "Hallo, %s! Du hast %zu MB Speicher verbraucht."
2
char*buf=malloc(1024);
3
if(!buf){errno=ENOMEM;return-1;}
4
size_tx=snprintf(buf,1024,FORMAT,name,mem);
5
if(x>=1024){
6
buf=realloc(buf,x+1);
7
if(!buf){errno=ENOMEM;return-1;}
8
snprintf(buf,x+1,FORMAT,name,mem);
9
}
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".
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