mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Am besten C lernen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Gemgod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dennsi W. (googoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennsi W. (googoo)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: svensson (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gurgl (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert

Autor: Gurgl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Anfaenger in C (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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 ...

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Dennsi W. schrieb:
> aber ich will nochmal drauf hinweisen
> das es Sinn macht mit reinem C anzufangen bevor man irgendwas anderes
> wie C--

Nein!

Erstens, ist Arduino C++.
Somit würde man mit C definitiv die falsche Sprache lernen, wenn man 
sich weiter mit Arduino beschäftigen möchte.

Nichts gegen C!
Es ist auch eine Sprache, wie jede andere, ...

Lernt man allerdings erst eine prozedurale Sprache, dann ist man für OOP 
verdorben!
Es ist viel schwieriger später von prozedural nach OOP zu schwenken, als 
sofort OOP zu lernen.

Nein!
Ich sage:
Erst eine OOP Sprache lernen, bzw. begreifen, was OOP ist, und wie es 
tut. Eigentlich egal welche Sprache, wenn es denn nicht so ein völliger 
Exot, wie JS ist.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Mistgabeln und Fackeln
Auf den Scheiterhaufen mit dir!

Die Prozeduraldenker sagen:
> Erst C lernen
> dann versuch mal C++
> und du wirst zu deinem C zurückkommen
> Das ist der Beweis dafür, dass C besser ist.

Die OO-Denkenden können in jeder Sprache Objekt orientierte Programme 
schreiben.
Es ist natürlich eine Hilfe, wenn die Sprache das unterstützt.

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Dennsi W. (googoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch kombinierte C/C++ Bücher, vielleicht wäre das ja das 
richtige

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Gemgod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Joe F. (easylife)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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++.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:
> Dr. Sommer schrieb:
>> Ja eben nicht! Nochmal zum Mitschreiben: Arduino ist C++, Arduino ist
>> nicht C!
>
> Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino"
> auch in ANSI-C zu programmieren.
> Geht sogar in Assembler.

Wenn du die Arduino IDE verwenden willst, dann muss mindestens eine 
Datei C++ sein.
Ohne geht es nicht.
Assembler, das geht nur in Libraries.
Der Rest, kann wie es will!
Auch C.

Verzichtest du auf diese IDE, wird das Spektrum natürlich breiter.

: Bearbeitet durch User
Autor: Joe F. (easylife)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Joe F. schrieb:
>> Seltsam, ich habe überhaupt keine Schwierigkeiten damit "den Arduino"
>> auch in ANSI-C zu programmieren.
>
> Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung
> gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++.

Nein, "Arduino" ist nicht C++, und ein Anfänger erkennt eben nicht 
sofort, dass hier die IDE gemeint ist.
Und ".ino" ist auch nicht C++.
Ich fühle mich gerade wie ein alternder, rechthaberischer Mann, aber 
wenn es Leute wie mich nicht gäbe ist auch bald ein iPhone ein Mac und 
.fritzing ist Elektronik.
Auch "Youtube-Tutorial" und "Lehrbuch" sind zwei verschiedene Dinge.

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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!

Autor: Karl K. (karl2go)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Karl K. schrieb:
> Es ist völlig unsinnig, auf µC wie den bei Arduino verwendeten AVRs OOP
> zu programmieren.

6 setzen!

Autor: Nicht W. (nichtsowichtig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.ino mit inline Assembler wo ist das Problem?! Oder auch C.

Geht oft sogar gar nicht anders übrigens.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Nicht W. schrieb:
> inline Assembler
Ist eine Gnade der der verwendeten Sprache!

Nicht mehr, und nicht weniger.

Egal ob *.c, *.cpp, oder *.ino

Autor: Tom V. (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Tom V. schrieb:
> aufzuplustern
Stimmt!
Das kann man besser dir überlassen.

Mach doch den Hahn auf dem Mist.
Ich gönne es dir.

: Bearbeitet durch User
Autor: Tom V. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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ß...

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Bedaure, wen du willst...
Und geh kacken, wenn es nötig ist.
Bitte!

: Bearbeitet durch User
Autor: Tom V. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn du meinst...

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. S. (achs)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Zonengabi (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++.

Autor: Sturm88 (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zonengabi schrieb:
> Für schmerzfreie Objekte gibt es u.a. Python.
Du schweifst ab. Es ging um C. Und daraufhin um die Frage, warum nicht 
doch sofort das sowieso native arduino-C++.

> Objekte haben in C nichts verloren, darum gibt es sie da auch nicht.
Hä? Du meintest vermutlich, dass C abgesehen von struct und 
Funktionspointern OOP kaum unterstützt? Ja.

Beitrag #5819235 wurde von einem Moderator gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert

Autor: Tim T. (tim_taylor) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> BTW:
>
> "Stop teachung C"
>
> Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C""

Ja, Spinner gibts immer.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. schrieb:
> Wilhelm M. schrieb:
>> BTW:
>>
>> "Stop teachung C"
>>
>> Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C""
>
> Ja, Spinner gibts immer.

Deine Antwort zeigt, dass Du die Intention des Vortrages nicht 
verstanden hast bzw. das Video erst gar nicht gesehen hast ...

Autor: blub (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> - generisch

Was genau meinst du damit?

Autor: Tim T. (tim_taylor) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Tim T. schrieb:
>> Wilhelm M. schrieb:
>>> BTW:
>>>
>>> "Stop teachung C"
>>>
>>> Youtube-Video "CppCon 2015: Kate Gregory “Stop Teaching C""
>>
>> Ja, Spinner gibts immer.
>
> Deine Antwort zeigt, dass Du die Intention des Vortrages nicht
> verstanden hast bzw. das Video erst gar nicht gesehen hast ...

In diesem speziellen Fall hat mir ihr Name gereicht um zu dem Schluss zu 
kommen, da muss ich garnicht erst irgendeinen Vortrag von ihr sehen.

Autor: blub (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
C oder C++ hin oder her, wichtig ist es auf jeden Fall, einmal das 
Konzept von pointern richtig verstanden zu haben!

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blub schrieb:
> Wilhelm M. schrieb:
>> - generisch
>
> Was genau meinst du damit?

Google kaputt heute?

https://de.wikipedia.org/wiki/Generische_Programmierung

In C++ realisiert das die template-Mechanik.

Autor: Gundula G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitchfight at its best

Autor: Thomas H. (thoern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joachim B. (jar)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung
> gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++.

"meine" *.ino haben c innen, denn c ist auch in c++ eine Untermenge und 
meine INO funktionieren mit dem C-Code seit Atari und PC.

Es stimmt schon für c++ bin ich verdorben, aber das stört mich nicht.

Mein eigener C-Code arbeitet sogar mit c++ der LIBs zusammen.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Rufus Τ. F. schrieb:
>> Die meisten haben erkannt, daß mit "Arduino" die Entwicklungsumgebung
>> gemeint ist, die mit "ino"-Dateien arbeitet. Und das ist C++.
>
> "meine" *.ino haben c innen,

Dein Code mag eine gemeinsame Untermenge aus C und C++ sein. Compilert 
wird es als C++.

> denn c ist auch in c++ eine Untermenge und meine INO funktionieren mit dem
> C-Code seit Atari und PC.

Du hattest auf dem Atari .ino-Dateien?
Wenn du noch so altes C benutzt, wird tatsächlich fast alles auch als 
C++ funktionieren.

Beitrag #5819289 wurde von einem Moderator gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: neuer PIC Freund (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> C ist KEINE Untermenge von C++

Nur für Leute, die gern Haare spalten. Eine der wesentlichen Forderungen 
an C++ und IMHO die Hauptursache für alle begründeten Rants gegen C++ 
[1] war die weitestgehende Kompatibilität von C++ mit C.

Es war ein Designziel, daß jedes [2] gültige C-Programm auch ein 
gültiges C++-Programm sein sollte. Insofern ist C++ also schon als 
Obermenge von C bzw. umgekehrt C als Untermenge von C++ gemeint.


[1] C++ schleppt eine Menge Merkwürdigkeiten mit sich herum, die es nur 
wegen der Kompatibilität zu C braucht. Ich hätte mir z.B. gewünscht, 
daß C++ nur noch richtige Strings erlaubt und die Krücke mit char* von 
C strikt verbietet. Geht halt nicht. Im Prinzip sollte man jegliche 
nackten Pointer in C++ verbieten. Nur noch Referenzen und Smart 
Pointers.

[2] natürlich ist es trivial, hierfür Ausnahmen zu finden. Man braucht 
bloß ein C++ Schlüsselwort als Bezeichner in einem C-Programm zu 
verwenden. Aber so etwas ist natürlich genauso trivial zu beheben.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sturm88 (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wer C kennt und in großen Teilen beherrscht, braucht kein C++

Und Mikrocontroller zu programmieren, braucht man mit Sicherheit kein 
C++

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mach (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wer C kennt nimmt Pascal...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Dennis S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Joachim B. (jar)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dennis S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Keinerlei Runtime-Zeugs?

Nein. So muss das auch sein (in meinen Augen).

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Joachim B. schrieb:
>> Ich habe C-Code, den hatte ich unter Arduino #included klappte war aber
>> doof zu pflegen, also die *.c in *.ino umbenannt, klappt auch.
>Dann kompilierst du es als C++. Dein Code ist also anscheinend gültiges
>C und C++ gleichzeitig.

das ist mal wieder ein typischer mikrocontroller.net Thread.
Warum zum Beispiel kriegt diese völlig korrekte Feststellung downvotes?

Wie kommt man überhaupt auf die verrückte Idee zu behaupten C sei C++ 
kompatibel? Wenn man bei "Kindergarten" bleibt ist Englisch auch 
Deutsch.

Mir scheint, dass der eine oder andere C Programmierer hier in diesem 
Faden vielleicht einfach kaum C kann?

Hier mal ein paar Beispiele für Unterschiede, es gibt aber natürlich 
noch viel mehr, wie zB das schon genannte sizeof, die designated 
Initialzier, kein int xyz[n] mit zB int n = 42, kein restrict, etc. pp.


int main()
{
    // geht nicht in c++
    int b(a) int a; { }

    // geht nicht in c++
    struct A { struct B { int x; } y; int xy; };
    struct B y;

    // geht nicht in c++
    auto z;

    // geht nicht in c++
    int a[1];
    int (*ap)[] = &a;

    return 0;
}



p.s. Und nein, ich kann nicht gut C und behaupte das auch nicht.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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!

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: svensson (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes K. (krjdev)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: svensson (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes K. schrieb:
> Timm R. schrieb:
>>     // geht nicht in c++
>>     auto z;
>
> Ist mit dem Standard C++11 eingeführt worden.

So wie es oben steht, geht es tatsächlich nicht, da für die Typinferenz 
der Initialisierer fehlt.

Tatsächlich hat sich die Bedeutung des Schlüsselwortes auto geändert!

: Bearbeitet durch User
Autor: Tim T. (tim_taylor) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Johannes K. (krjdev)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes K. (krjdev)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Tim T. (tim_taylor) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Karl K. schrieb:
> Warum sollte Pascal nicht aktuell sein?

Weil's nicht sein darf.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes K. (krjdev)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim T. schrieb:
> Also ich hab zuerst Basic auf dem Plus4 und C64 gelernt, später
> dann
> Assembler und C, anschließend in der Oberstufe Delphi/Pascal, auf der
> Uni dann wieder C und C++, nach der Uni dann noch aus eigenem Interesse
> C#. Wenn ich zurück denke muss ich feststellen das für mich Basic und
> Pascal die am wenigsten brauchbaren Sachen waren, ich bin relativ froh
> das ich mich kaum noch daran erinnern kann, ich weiß nicht wie oft ich
> irgendwelche Syntaxprobleme in der Uni hatte weil sich Pascal in meinem
> C Quelltext eingeschlichen hat. Aber aktuell stehe ich wieder vor der
> Frage was man am besten lernen bzw. zuerst lernen soll, da ich meiner
> Tochter etwas mitgeben will und da stehen momentan Assembler, C und
> Python in der engeren Auswahl, mit durchaus starker Tendenz zu C.

Habe mit BASIC und dann Assembler angefangen. Dann kam C. Bereue ich 
nicht.
War recht angetan als ich beim Buch "Hacking - Die Kunst des Exploits" 
wieder auf Assembler gestoßen bin.

Assembler ist IMHO halt wirklich Grundlage, wenn man bei einem 
Mikrocontroller wissen will, was tatsächlich abläuft.

Auch kann man ohne Assemblerkenntnisse so was nicht machen:
int mystrlen(char *str)
{
    int i;
    
    while (str[i++] != '\0')
        ;
    
    return i;
}

void _start(void)
{
    char *msg = "Hello World!\n";
    int len;
    int result;
    
    len = mystrlen(msg);
    
    __asm__ __volatile__("movq $1, %%rax;" /* sys_write */
                         "movq $1, %%rdi;" /* file descriptor stdout */
                         "syscall;"        /* call the kernel */
                         : "=a"(result)       /* return code */
                         :"S"(msg), "d"(len)  /* %rsi <- msg, %rdx <- len */
                        );
    
    __asm__ __volatile__("movq $60, %rax;" /* sys_exit */
                         "movq $0, %rdi;" /* return 0 */
                         "syscall" /* call the kernel */
                         );
}
Wäre eine Variante ohne LibC für Linux, das heißt ohne C Overhead. 
Wüsste nämlich nicht wie man ein Syscall ohne LibC aufrufen kann.

PS: Schnell erstellt. Beware of bugs in the above code.

: Bearbeitet durch User
Autor: Thomas (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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).

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gurgl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Jemand (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Ernst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich verwende gerne C++ für µCs. Die Sprache hat aber ein Problem das bei 
all diesen "Diskussionen" gerne ignoriert wird.
Die Compiler der Toolchains unterstützen zwar durchweg C++, die 
Bibliotheken aber nicht oder nur unvollständig.

D.h. sobald in einem C++ Code auch nur ein simples
#include <algorithm>
 oder
#include <type_traits>
 auftaucht kann ich mich nicht darauf verlassen das mir diese 
Funktionalität auch tatsächlich zur Verfügung steht.

Crossworks z.B. unterstützt dank g++ zwar grundsätzlich C++17 aber es 
gibt dort keinen einzigen C++ Header der C++ Lib.
Auch der ARMCC scheint nur die RogueWave C++ Lib zu bieten die soweit 
ich das sehe nicht einmal C++11 unterstützt.

Das hält mich freilich nicht davon ab C++ zu benutzen aber wie soll ein 
Anfänger da vorgehen? C++ Literatur die mir bisher untergekommen ist 
benutzt von Anfang an die Library.

Für unseren Arduino Freund sehe ich schon deshalb nur den Weg über C. 
Nach und nach kann er dann mit namespaces, templates usw. weitermachen.
Aber ein "richtiger Einstieg in C++" ist das vermutlich nicht. Also erst 
auf dem PC lernen und dann für µC "downgraden"?
Wenn das Ziel "C++ für alles" ist - o.k. Aber falls es "nur" um µC geht 
bin ich da skeptisch.

Ich kann das aber nicht beurteilen (und will das auch gar nicht) da mein 
Einstieg (Basic -> Pascal -> C -> ASM -> C++) schon eine Weile 
zurückliegt und ich auch nicht auf einem µC angefangen habe.
Ich kann mich allerdings noch gut daran erinnern wie froh ich seinerzeit 
war mit C (Turbo-C 2.0) einen Ersatz für Pascal gefunden zu haben.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
---

Autor: Herbert (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Wer eine bestimmte Programmiersprache als Muttersprache und alle anderen
> als Fremdsprachen bezeichnet ist kein Programmierer.

Ich habe das nicht getan.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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."

Autor: M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Atemis H. (at0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lernt jemand heute C++ vollständig? Lernt man nicht eher eine Teilmenge 
davon? Am besten so ab C++ 11 und Rest möglichst meiden.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Ich verwende gerne C++ für µCs. Die Sprache hat aber ein Problem das bei
> all diesen "Diskussionen" gerne ignoriert wird.
> Die Compiler der Toolchains unterstützen zwar durchweg C++, die
> Bibliotheken aber nicht oder nur unvollständig.
>
> D.h. sobald in einem C++ Code auch nur ein simples
#include 
> <algorithm>
 oder
#include <type_traits>
 auftaucht kann ich
> mich nicht darauf verlassen das mir diese Funktionalität auch
> tatsächlich zur Verfügung steht.

Die C++-Standardlib ist zwar für AVR beim GCC nicht da, aber das macht 
nichts, denn man kann den statischen Teil fast direkt übernehmen. Nur 
die dynamischen Container gehen mangels new/delete nicht direkt. Aber 
auch das macht nichts, denn auf den kleinen µC hat man auch kleine 
Probleme zu lösen, bei denen man die dynamischen Container nicht 
benötigt.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Herbert schrieb:
> ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären.

Nein, das sehe ich nicht so!

Wenn man die Features der STL voll auskosten will, dann braucht es mehr 
Speicher!
Das ist wohl war.

Aber das kann man auch trennen! (ich behaupte, man muss)
Denn die OOP Merkmale finden sich in der Sprache, die STL nutzt diese 
nur.

OOP an sich braucht keinen "mehr" Speicher.
Denn OOP findet im Kopf statt.

Es heißt ja:
> Objekt orientierte Programmierung
Und eben diese "Orientierung" die findet sich im Kopf und nirgendwo 
anders.

(hinkender) Vergleich:
Auch mit einem VW Käfer kann man Sand transportieren.
Für eine Baustelle, wirds nicht reichen.
Aber für ein Aquarium halt doch.


Übrigens:
Es finden sich auch STL Implementierungen für den AVR-GCC.
Unmöglich, sie zu verwenden, ist es also nicht.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefan schrieb:
> Das hält mich freilich nicht davon ab C++ zu benutzen aber wie soll ein
> Anfänger da vorgehen?

z.B. das Atollic Studio nutzen, welches den Open-Source GCC verwendet, 
welcher eine komplette C++ Standard Library enthält. Die habe ich auch 
schon ausführlich benutzt. Den Compiler kann man hier übrigens auch 
separat herunterladen:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

ARM setzt ja mittlerweile auch auf Clang statt ARMCC. Der unterstützt 
ebenfalls die Standardbibliothek.

Stefan schrieb:
> Aber ein "richtiger Einstieg in C++" ist das vermutlich nicht. Also erst
> auf dem PC lernen und dann für µC "downgraden"?
Das ist sowieso der sinnvollste Weg, egal ob C oder C++.

Herbert schrieb:
> ... womit wir wieder bei 'OOP braucht stärkere Hardware" wären

Das stimmt halt absolut nicht. OOP impliziert nicht dynamische 
Speicherverwaltung mit new/malloc.

Zeno schrieb:
> Ja er sollte dies tun. Ist aber alles zusätzlicher Aufwand beim
> Installer und wird halt auch mal gern vergessen. Die A-Karte zieht in
> dem Fall erst mal der Anwender.

So ist das halt, wenn man auf Windows besteht. Unter Linux ist das alles 
viel einfacher dank Paket-Managern.

Zeno schrieb:
> Das ist alles Mist, eine naive EXE ist da deutlich besser.

Witzig, dass hier die Form der Installation so viel wichtiger zu sein 
scheint als die Programmier-Paradigmen. Das wäre so als würde man die 
Form und Technologie von Autos an den Verkaufsraum der Händler 
anpassen...

Zeno schrieb:
> Bringt keine Vorteile
Der Code läuft direkt auf verschiedenen Prozessoren und man hat eine 
riesige Bibliothek zur Verfügung, man kann JIT Code generieren und 
Reflection nutzen. Das ABI ist immer konsistent. Das sind also "keine 
Vorteile"?

M. schrieb:
> Exe starten und gut ist!

Und wann werden Dateitypen assoziiert, COM-Komponenten registriert, 
Registry-Einträge z.B. für das "Programme"-Menü angelegt? Bei jedem 
Start? Das wird nervig. Wo kommen Grafiken, Sounds & Co hin - alle in 
die eine .exe? Damit die alle beim Start des Programms in den RAM 
geladen werden? Na super.

Egon D. schrieb:
> "Jeder Programmierer steigert die Komplexität seiner
> Werkzeuge so lange, bis er sein Werkzeug nicht mehr
> beherrscht.

Man muss C++ nicht komplett beherrschen. Die Nutzung von z.B. 
std::string steigert die Effizienz schon, wenn man die Details von 
dessen Implementation nicht kennt.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Joe F. (easylife)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Rolf M. schrieb:
>> Nicht OOP, sondern die Standardbibliothek (bzw. große Teile davon),
>
> "groß" ist relativ. Die Bibliothek bietet noch eine Menge weiterer sehr
> nützlicher Dinge. Klassisches Beispiel ist std::max - sehr praktisch und
> in C unmöglich genau so gut nachzubauen.
>
> Dieser Code nutzt z.B. die Standard-Bibliothek und ist
> Mikrocontroller-geeignet:
> Beitrag "Re: IntToHex function"

Mir kommt es irgendwie so vor, als ob da ein Haufen Code geschrieben 
wird, der am Ende nie gebraucht wird. Halt nur für den Fall, dass wenn 
mal...

Als Programmierer alter Schule bin ich es gewohnt mit unterschiedlichen 
Datentypen umzugehen.
Wenn ich 2 Integer vergleichen will, teste ich (a>b), wenn ich a mit 
einem Array vergleichen will, schreibe ich eine entsprechende Funktion 
dafür.
Das alles immer mit einer Funktion abgekaspert werden kann, finde ich 
unnötig und auch verwirrend.

Genauso bei deinem Beispiel "int2hex".
Da würde ich mir klassischerweise eine Funktion schreiben, die einen 
32-bit Wert verarbeiten kann, und ich übergebe die Länge, wie breit mein 
Datenwort ist.

int2hex (char *str, uint32_t value, uint8_t size) { ... }

Wenn ich nun einen uint8 in hex umwandeln möchte, kann ich den uint8 
auch direkt an die Funktion übergeben. Der Compiler castet den uint8 auf 
uint32. Kein Problem.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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".

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Vincent H. (vinci)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jonas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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++.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vincent H. (vinci)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Jonas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :))

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jonas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jonas (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jonas (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: ohne Account (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
> Bin für jeden Ratschlag dankbar ^^
Die Antwort gibt es wie immer im Netz:
https://www.electronicsplanet.ch/mikrocontroller/avr-tutorial-c/avr-tutorial-c.htm

PS:
Die Grundsatzdiskussion ist völlig am Thema vorbei bzw. Arduino & C++ 
kann man vergessen.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohne Account schrieb:
>> Bin für jeden Ratschlag dankbar ^^
> Die Antwort gibt es wie immer im Netz:
> 
https://www.electronicsplanet.ch/mikrocontroller/avr-tutorial-c/avr-tutorial-c.htm

Dieses Tutorial ist für C-Programmierer, also für diejenigen, die das,
was der TE erst lernen will, schon können.

Autor: ohne Account (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: ohne Account (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gemgod schrieb:
> Ich habe ich in den letzten Monaten mit dem Arduino beschäftigt ujd
> würde sagen bin auch ganz gut darin. Da der Arduino einem jedoch
> ziemlich viel abnimmt wollte ich anfangen richtig c zu lernen.

Nunja, Grundlagen wie Funktionen aufrufen, Schleifen und Bedingungen 
verstehst du ja jetzt schon, nehme ich an. Man kann jetzt natürlich auf 
Abstraktionen wie Arduino verzichten, um lowlevel zeug zu lernen. Aber 
um C wirklich voll Ausschöpfen zu können, würde ich empfehlen 
Datenstrukturen, Funktionspointer und das entwerfen von sauberen 
Interfacen zu lernen. Ein paar Algorithmen können auch nicht schaden.

Für den Anfang würde ich mal empfehlen, Programme möglichst immer in 
Subsysteme zu teilen, wo dies sinvoll, also unabhängige teile sind. 
Häufig gibt es eine init funktion für das Subsystem oder Instanzen 
davon. Die Daten von diesen packt man dann am besten immer gleich in ein 
Struct.

Wichtige Datenstrukturen sind z.B. linked lists, doubly linked lists, 
Ringbuffer, Stacks und Queues, usw.

Bei unterschiedlichen Programmteilen und Subsystemen sind einfache und 
stabile Interfaces empfehlenswert, das braucht etwas Übung. Ein 
Interface kann in C eine Headerdatei und die darin aufgelisteten 
Funktionen sein. Du kannst stattdessen aber auch Funktionspointer in 
Structs packen. Das ist unter anderem eine Methode, wie man das 
Dependency-Inversion-Prinzip[1] in C anwenden kann. Einfach darauf 
achten, welche Richtung sinn macht, also was von was abhängt. Man kann 
so auch mehrere Implementierungen des selben Interface/Subsystem haben, 
oder es auch einfacher austauschen, usw. In paar Beispiele von dem 
Pattern, wo ich es verwendet habe:
 * Die Backends meines kleinen gles dmabuffer Beispiels:
    - 
https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/src/egl_x11.c#L100
    - 
https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/include/internal/engine.h
    - 
https://github.com/Daniel-Abrecht/egl-gles2-linux-dmabuf-camera-texture-example/blob/master/src/engine.c#L344
 * Die backends meiner libttymultiplex library:
    - 
https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/backend/curses.c#L264
    - 
https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/include/internal/backend.h
    - 
https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/backend.c#L35
 * Diverse Treiber meines (immernoch unvollständigen) DPA-UCS Projektes:
    - 
https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/headers/DPA/UCS/driver/ethernet.h
    - 
https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/generic/dummy.c#L22
    - 
https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/generic/enc28j60.c#L19
    - 
https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/server/driver/linux/ethernet.c#L193
  * etc.

Und dann eventuell noch ein paar grundlegende Algorithmen üben, z.B. 
bubble sort, state machines, einfache parser, und solches zeug üben.

1) https://de.wikipedia.org/wiki/Dependency-Inversion-Prinzip

Autor: Karl K. (karl2go)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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...

Autor: Hennes (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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

Autor: Vincent H. (vinci)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Karl K. schrieb:
> Es geht um AVR Controller.

Seit wann?

Karl K. schrieb:
> Dann schreibe
> ich das Zeichen so wie jedes andere Zeichen über die Schreibroutine des
> Ringbuffers.

Also für jedes Zeichen ein Funktionsaufruf. Lahm. memcpy hingegen ist 
schön optimiert.

Karl K. schrieb:
> Denn auf einen Ringbuffer schreiben kann Deine Funktion
> nicht, und muss wieder unnötig rumkopieren.
Statt eines char* hätte ich auch einen generischen Typ verwenden können, 
an den man dann Iteratoren übergeben könnte. Dann kann man sowohl 
Array-Zeiger als auch Output-Iteratoren übergeben, d.h. der Aufrufer 
hätte die Wahl zwischen direkter Ausgabe oder Ausgabe ins Array.

Karl K. schrieb:
> Ja, natürlich. Wenn Datentypen Ganzzahlen meint.
Wie funktioniert das denn? Dynamische Typisierung (langsam, unsicher), 
Generische Programmierung (genau wie C++) oder durch Nutzung eines 
größten Typs (langsam)?

Karl K. schrieb:
> Dieses ganze Rumgehüpfe mit OOP und C++ klaschiert doch nur, dass der µC
> letztlich prozedural arbeitet - da kann man auch prozedural
> programmieren.

Genau das ist der Trugschluss. Warum muss man seine Denkstrukturen exakt 
so sortieren wie die Hardware? Wenn man auf einer abstrakteren Ebene 
arbeitet, kann man die Abläufe, Probleme und Datenstrukturen so 
formulieren wie sie sind, wie man sie leichter begreifen, beschreiben 
und auch abändern kann. Die Arbeit des Anpassens an die Hardware lässt 
man dann den Compiler machen.

Ich bin gespannt was du zu funktionaler Programmierung, oder Prolog 
sagen würdest. Die Schreibweise hat da überhaupt nichts mit der 
prozeduralen Arbeitsweise von Prozessoren zu tun. Bei den Problemen, auf 
die diese Sprachen passen, sind die Programme sehr kompakt und 
verständlich. Nur weil man die auch prozedural formulieren "kann", ist 
das noch lange nicht besser.

Karl K. schrieb:
> Huh,
> das sieht aber kompliziert aus. Und schon bist Du der unersetztliche
> Guru. Wers braucht...
An einem anderen Beispiel wird es deutlicher:
C++:
std::string x = "Hallo, " + name + "! Du hast " + std::to_string(mem) + " MB Speicher verbraucht.";
C:
#define FORMAT "Hallo, %s! Du hast %zu MB Speicher verbraucht."
char* buf = malloc (1024);
if (!buf) { errno = ENOMEM; return -1; }
size_t x = snprintf(buf, 1024, FORMAT, name, mem);
if (x >= 1024) {
  buf = realloc (buf, x+1);
  if(!buf) { errno = ENOMEM; return -1; }
  snprintf(buf, x+1, FORMAT, name, mem);
}
Was sieht jetzt komplizierter aus? Was ist leichter durch einen Anfänger 
zu schreiben und abändern?

Hennes schrieb:
> Ich dachte es handelt sich hier um ein deutschsprachiges Forum

Dann nenne doch mal sinnvolle, wohlbekannte deutsche Begriffe, die nicht 
einfach nur eingedeutscht sind ("k" statt "c")...

Autor: Karl K. (karl2go)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: BlaBla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau :-)

Autor: BlaBla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach schrieb:
> Wer C kennt nimmt Pascal...

Oh, da fehlte was...
Genau :-)

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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".

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> std::string x = "Hallo, " + name + "! Du hast " + std::to_string(mem) +
> " MB Speicher verbraucht.";

Hier mal in Arduino:
void setup() 
{
 Serial.begin(9600);
 char name[] = "Walter";
 int mem = 4711;
 Serial.println(String() + "Hallo, " + name + "! Du hast " + mem + " MB Speicher verbraucht.");
}

Vielleicht nicht die Ressourcen schonendste Variante, aber schön Bequem.

: Bearbeitet durch User
Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gemgod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.