Wirkungsgrad von 100 m RG213U...

[Helmut Schellong]

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:

Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".

Nö.

Den Spruch habe ich sogar schon von Arbeitgebern gehört.
Von deren leitenden Angestellten (MdGL) erst recht.

> \"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus.\"

Das trifft nur auf diejenigen zu, die mit C undiszipliniert umgehen.

\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts weiter ausgeben als ein
paar Warnungen.\"

Das ist gewollt, und sehr gut so.

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem
Weiterbildungslehrgang damals aufheben sollen.

Wer sich da herumdrückt, ist in den meisten Fällen beruflich nahezu völlig abgehängt.
Ganz schlecht für C-Hasser.

Richtig, C muss man lieben. Aber wenn ich das richtig sehe, gehört die \"digitalisierte\" Welt
doch den Interpretersprachen - läuft denn z.B. irgendwas im Netz heute noch ohne PHP ...

Unter den vielen unixoiden Betriebssystemen liegen in den Verzeichnissen
/bin /sbin /usr/bin /usr/sbin /usr/local/bin
die ausführbaren Dateien (Executables).
Mindestens 99% davon sind compilierte binäre Exe, in C oder C++ geschrieben.

Der Kernel und alle Libraries sind ebenfalls in C/C++ und zu kleinen Teilen in Assembler.
Hinzu kommen (FreeBSD) fast 40000 fertig compilierte Packages - alle in C/C++ geschrieben.

Windows ist seit langer Zeit in C/C++/C# geschrieben (früher in Pascal).

Binäre Exe bilden folglich die übergroße Mehrheit.
Interpreter-Skripte sind selten, und fast immer sind sie Frontend- oder Service-Skripte.

PHP arbeitet weit überwiegend serverseitig und ist dazu in HTML eingemischt.
Die Webserver (z.B. Apache) sind - natürlich in C/C++ geschrieben.
Qt und MySQL sind in C/C++ geschrieben.
Weitere Datenbanken sind ebenfalls in C geschrieben.

Die verbreitete Code-Basis in C/C++ ist gigantisch groß.
Im uC-Bereich (embedded) gibt es nahezu ausschließlich C/C++.
Wobei der uC-Bereich größer ist, als alle anderen Bereiche.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Wolfgang Allinger]

On 21 Sep 23 at group /de/sci/electronics in article uegt1gUl1fuL1@news.in-ulm.de
<spamless@gmx.de> (Holger Schieferdecker) wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'


(*) C ist zB: (*(void(*)())0)()

Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.
Na denn!

Wer weiss, für was der Obige Müll gut ist?

Auflösung auf Anfrage







Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Hans-Peter Diettrich]

On 9/20/23 4:27 PM, Helmut Schellong wrote:

Am 20.09.2023 um 11:56 schrieb Hans-Peter Diettrich:
On 9/19/23 9:13 PM, Sieghard Schicktanz wrote:

Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.

Daß C auch ein High-Level-Assembler ist, kann gesagt werden.
Als Konglomerat von mehreren Sprachen kann sie nicht bezeichnet werden,

Ach, dann sind C, C-Preprozessor, Make und vielleicht heute noch M4 und
Autobloat für Dich keine unterschiedlichen Programmiersprachen?

DoDi

 

[Carla Schneider]

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article uegt1gUl1fuL1@news.in-ulm.de
spamless@gmx.de> (Holger Schieferdecker) wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

(*) C ist zB: (*(void(*)())0)()

Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion aufgerufen
die an Adresse Null liegt. Auf einem PC gibt das ein Segmentation fault,
aber ich will nicht ausschliessen dass es Systeme gibt wo an Adresse 0
eine wichtige Funktion liegt die er auf diese Weise aufgerufen hat,
vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist ja
manches moeglich.


Vielleicht ist es auch ein Test fuer ein fehlertolerantes Programm
das dieses Signal abfaengt statt abzustuerzen.

Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.

Dann hat er es in der gegebenen Zeit wohl nicht geschafft.

Na denn!

Wer weiss, für was der Obige Müll gut ist?

Er wollte halt nicht extra einen Pointer auf eine Funktion definieren,
dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar Byte
einsparen.

Auflösung auf Anfrage

 

[Carla Schneider]

Hans-Peter Diettrich wrote:

On 9/20/23 4:27 PM, Helmut Schellong wrote:
Am 20.09.2023 um 11:56 schrieb Hans-Peter Diettrich:
On 9/19/23 9:13 PM, Sieghard Schicktanz wrote:

Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.

Daß C auch ein High-Level-Assembler ist, kann gesagt werden.
Als Konglomerat von mehreren Sprachen kann sie nicht bezeichnet werden,

Ach, dann sind C, C-Preprozessor, Make und vielleicht heute noch M4 und
Autobloat für Dich keine unterschiedlichen Programmiersprachen?

C geht auch ohne make, und make geht auch fuer andere Programmiersprachen.
Der Preprozessor ist auch kein Teil von C er macht nur Textverarbeitung auf
dem Quellcode und wird auch fuer andere Sprachen benutzt.

 

[Helmut Schellong]

Am 21.09.2023 um 13:18 schrieb Hans-Peter Diettrich:

On 9/20/23 4:27 PM, Helmut Schellong wrote:
Am 20.09.2023 um 11:56 schrieb Hans-Peter Diettrich:
On 9/19/23 9:13 PM, Sieghard Schicktanz wrote:


Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.

Daß C auch ein High-Level-Assembler ist, kann gesagt werden.
Als Konglomerat von mehreren Sprachen kann sie nicht bezeichnet werden,

Ach, dann sind C, C-Preprozessor, Make und vielleicht heute noch M4 und Autobloat für Dich keine
unterschiedlichen Programmiersprachen?

Seit wann werden sonstige Kommandos eines Entwicklungssystems als Bestandteil
des Compilers und als interne Programmiersprachen der Sprache C angesehen?
C ist eine Touring-vollständige Programmiersprache 3GL.
Alle weiteren oben aufgeführten Kommandos nicht.

Der C-Standard definiert die Sprache C.
In der Sprache C ist das Preprocessing untrennbar enthalten.
Es ist dem C-Standard vollkommen egal, WIE eine Implementation von C ausgestaltet ist.
Sie muß an Berührungspunkten nur den Definitionen des C-Standards folgen.

Ich gebrauche Make, M4 und Autobloat für meine C-Projekte nicht.
Der C-Standard beschreibt diese Kommandos nicht.
Sie sind kein Bestandteil der Sprache C.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 21.09.2023 um 08:03 schrieb Marte Schwarz:

Ach Kinders,

Richtig, C muss man lieben. Aber wenn ich das richtig sehe, gehört die \"digitalisierte\" Welt
doch den Interpretersprachen - läuft denn z.B. irgendwas im Netz heute noch ohne PHP ...

Es gibt unterschiedliche Anwendungen, die programmiert werden. Je nach Anwendung nutzt man dann die
Tools/ Programmiersprache, die dafür geeignet ist. Interpretersprachen sind weder prinzipiell
besser noch schlechter. Häufig sind sie einfach zu langsam. Da sind compilierte Programme im Vorteil.

Eine \"digitalisiete\" Welt gibts nicht wirklich. PHP hat seinen Platz an ganz anderen Stellen, als
im 4- bis 16-Bit µC Bereich ist das ist eine ganz andere \"digitalisierte\" Welt, als  mit 32/ 64
Bit-Multicore-µC-Bereich, mit denen Multimedia-Konsolen und vieles mehr programmiert wird. Eine
Spezialanwendung an einem Prüf- oder Forschungsplatz wird mit anderen Anforderungen laufen
müssen/dürfen, als bei einem Massenprodukt. Beim einen dürften Hardwarebeschränkungen keine Rolle
spielen, man nimmt eben mehr Rechenleistung und gut. Beim anderen zählt jedes Cent und man spart an
Speicher und Rechenleistung wo immer es geht.

Kein vernünftiger Programmierer wird ein Massenprodukt mit 4/8-Bit µC mit PHP oder Python
programmieren. Genausowenig wird man eine Webanwendung mit C interaktiv gestalten wollen.

All diese Ebenen in einen Topf zu werfen und dann zu behaupten, 95 % aller Programme seien C/C++
ist einfach Unsinn, zumal die Basis nicht definiert wurde. Was sollen denn 100 % sein? Anzahl der
geschriebenen Codezeilen, ausgelieferte Stück Hardware, im zeitlichen Mittel laufender Code ... ?

Es ist wahrscheinlich, daß es ungefähr 95% für C/C++ sind.
Siehe auch [1].
Die Berechnungsbasis ist die VERBREITUNG, die Code-Basis.
Also die
o Anzahl verschiedener Quell-Codes in C/C++, die jeweils eine Exe generieren.
o Anzahl verbreiteter Kompilationen (Exe) aus dem jeweiligen Quell-Code.
o Anzahl KByte des jeweiligen Quell-Codes.

Mit den Gewichtungen 0,85 | 0,1 | 0,05.
dateien.h gelten nicht.
Es muß mindestens ein Funktionskörper in einer zählenden Datei enthalten sein.


[1] heute 11:51 :
Unter den vielen unixoiden Betriebssystemen liegen in den Verzeichnissen
/bin /sbin /usr/bin /usr/sbin /usr/local/bin
die ausführbaren Dateien (Executables).
Mindestens 99% davon sind compilierte binäre Exe, in C oder C++ geschrieben.

Der Kernel und alle Libraries sind ebenfalls in C/C++ und zu kleinen Teilen in Assembler.
Hinzu kommen (FreeBSD) fast 40000 fertig compilierte Packages - alle in C/C++ geschrieben.

Windows ist seit langer Zeit in C/C++/C# geschrieben (früher in Pascal).

Binäre Exe bilden folglich die übergroße Mehrheit.
Interpreter-Skripte sind selten, und fast immer sind sie Frontend- oder Service-Skripte.

PHP arbeitet weit überwiegend serverseitig und ist dazu in HTML unter gemischt.
Die Webserver (z.B. Apache) sind - natürlich in C/C++ geschrieben.
Qt und MySQL sind in C/C++ geschrieben.
Weitere Datenbanken sind ebenfalls in C geschrieben.

Die verbreitete Code-Basis in C/C++ ist gigantisch groß.
Im uC-Bereich (embedded) gibt es nahezu ausschließlich C/C++.
Wobei der uC-Bereich größer ist, als alle anderen Bereiche.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hartmut Kraus]

Am 21.09.23 um 11:51 schrieb Helmut Schellong:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Aber wenn ich das richtig sehe, gehört die \"digitalisierte\" Welt doch den Interpretersprachen - läuft denn z.B. irgendwas im Netz heute noch ohne PHP ...

Unter den vielen unixoiden Betriebssystemen liegen in den Verzeichnissen
       /bin  /sbin  /usr/bin  /usr/sbin  /usr/local/bin
die ausführbaren Dateien (Executables).
Mindestens 99% davon sind compilierte binäre Exe, in C oder C++ geschrieben.

Der Kernel und alle Libraries sind ebenfalls in C/C++ und zu kleinen Teilen in Assembler.
Hinzu kommen (FreeBSD) fast 40000 fertig compilierte Packages - alle in C/C++ geschrieben.

Windows ist seit langer Zeit in C/C++/C# geschrieben (früher in Pascal).

Binäre Exe bilden folglich die übergroße Mehrheit.
Interpreter-Skripte sind selten,

Hast du \'ne Ahnung. PHP ist nicht die einzige Interpretersprache.

und fast immer sind sie Frontend- oder Service-Skripte.

PHP arbeitet weit überwiegend serverseitig und ist dazu in HTML eingemischt.

Umgekehrt wird ein Schuh draus. Üblicherweise bastelt PHP auf dem Server die HTML-Seiten zusammen, die werden dann an den Client gesendet. Enthalten des öfteren allerdings auch noch JavaScript ...

Die Webserver (z.B. Apache) sind - natürlich in C/C++ geschrieben.
Qt und MySQL sind in C/C++ geschrieben.
Weitere Datenbanken sind ebenfalls in C geschrieben.

Die verbreitete Code-Basis in C/C++ ist gigantisch groß.
Im uC-Bereich (embedded) gibt es nahezu ausschließlich C/C++.
Wobei der uC-Bereich größer ist, als alle anderen Bereiche.

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf

 

[Hergen Lehmann]

Am 21.09.23 um 12:12 schrieb Wolfgang Allinger:

> C tut weh! (*)

K&R C war seinerzeit ein *TRAUM* gegenüber der für die
Systemprogrammierung einzig verfügbaren Alternative, dem Assembler.

Seitdem wurde die Sprache kontinuierlich weiter entwickelt, und in
aktuellen Versionen lässt sich sehr komfortabel gut lesbarer und
sicherer Code schreiben.


> Der C-Programmierer hat den Compiler im Kopf.

Ich arbeite heute zwar überwiegend mit C++, aber auch zu C-Zeiten habe
ich nie ein Programm von Hand compiliert.


> Der FORTH-Programmierer hat den Compiler im Target.

Wenn mich meine Erinnerung nicht täuscht, \"compiliert\" FORTH lediglich
in eine Art Zwischencode, welcher auf 99.9998% der verfügbaren Hardware
anschließend interpretiert wird.
Es gab zwar mal auf FORTH optimierte Hardware, aber das war eine Nische
in der Nische in der Nische.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

Der schlechte FORTH-Programmierer hat gar keine andere Wahl, als die
Nacht durch zu arbeiten und IRGEND ETWAS abzuliefern, weil er sonst für
seine Wahl einer obsoleten, obskuren Programmiersprache zu Recht vom
Management geköpft wird. SCNR

(*) C ist zB: (*(void(*)())0)()

Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.
Na denn!

In jeder Programmiersprache lässt sich unleserlicher, unkommentierter
Code schreiben. Was willst du hier beweisen?


> Wer weiss, für was der Obige Müll gut ist?

Auf den ersten Blick: Liest aus Speicheradresse 0 einen Zeiger auf eine
Funktion, welche dann aufgerufen wird. Klingt nach einer Knobelaufgabe
aus dem Programmierkurs und nicht nach realem Code.

Obwohl, ein Anwendungsfall fällt mir ein: Die verwendete CPU hat dort
ihren Reset-Vektor stehen und es soll so ein Soft-Reset ausgeführt werden.

 

[Helmut Schellong]

Am 21.09.2023 um 14:10 schrieb Carla Schneider:

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article uegt1gUl1fuL1@news.in-ulm.de
spamless@gmx.de> (Holger Schieferdecker) wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

(*) C ist zB: (*(void(*)())0)()

Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion aufgerufen
die an Adresse Null liegt. Auf einem PC gibt das ein Segmentation fault,
aber ich will nicht ausschliessen dass es Systeme gibt wo an Adresse 0
eine wichtige Funktion liegt die er auf diese Weise aufgerufen hat,
vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist ja
manches moeglich.

Ich habe meine Zweifel, daß hier der korrekte Kontext sicher erahnt werden kann.
Es wird jedenfalls die Konstante 0 gecastet: (cast)0, zu einem (void(*)()) Funktions-Pointer.
Außen herum befindet sich eine obsolete Aufrufsyntax (*fup)().
Heutzutage kann mittels fup(); aufgerufen werden.

# define NEsp0ARR(S,A) (sizeof(((S*)0)->A) / sizeof(*((S*)0)->A))

Vorstehend gibt es auch eine Konstante 0 in Verwendung.
Der Name bedeutet: Anzahl Einträge struct pointer 0 Array

Wer weiss, für was der Obige Müll gut ist?

Er wollte halt nicht extra einen Pointer auf eine Funktion definieren,
dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar Byte
einsparen.

Es gibt in C von Beginn an das Schlüsselwort typedef, um solche komplexen Typen zu vermeiden.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 9/21/23 2:42 PM, Helmut Schellong wrote:

Seit wann werden sonstige Kommandos eines Entwicklungssystems als
Bestandteil
des Compilers und als interne Programmiersprachen der Sprache C angesehen?

Fiel mir erst später auf, gemeint waren \"formale\" Sprachen.

C ist eine Touring-vollständige Programmiersprache 3GL.
Alle weiteren oben aufgeführten Kommandos nicht.

Was willst Du damit sagen?

Der C-Standard definiert die Sprache C.
In der Sprache C ist das Preprocessing untrennbar enthalten.

Also doch ein Konglomerat von Sprachen ;-)

Es ist dem C-Standard vollkommen egal, WIE eine Implementation von C
ausgestaltet ist.

Sooo sensibel ist kein Standard, eher dessen Benutzer.

> Sie muß an Berührungspunkten nur den Definitionen des C-Standards folgen.

Hmm, wer berührt wen wo? Me2?


> Ich gebrauche Make, M4 und Autobloat für meine C-Projekte nicht.

Dann fummelst Du also so alleine vor Dich hin?

Der C-Standard beschreibt diese Kommandos nicht.
Sie sind kein Bestandteil der Sprache C.

Aber für die Herstellung portabler Programme sind sie unverzichtbar,
sagt die FSF.

DoDi

 

[Hans-Peter Diettrich]

On 9/21/23 2:44 PM, Hergen Lehmann wrote:

Am 21.09.23 um 12:12 schrieb Wolfgang Allinger:

C tut weh! (*)

K&R C war seinerzeit ein *TRAUM* gegenüber der für die
Systemprogrammierung einzig verfügbaren Alternative, dem Assembler.

Seitdem wurde die Sprache kontinuierlich weiter entwickelt, und in
aktuellen Versionen lässt sich sehr komfortabel gut lesbarer und
sicherer Code schreiben.

Das kann nur jemand behaupten, der Delphi nicht kennt, und vielleicht
auch sonst keine benutzerfreundlicheren Sprachen.

Der C-Programmierer hat den Compiler im Kopf.

Ich arbeite heute zwar überwiegend mit C++, aber auch zu C-Zeiten habe
ich nie ein Programm von Hand compiliert.

Auf einer pdp ging das ganz einfach im Kopf, keine Notwendigkeit zum
Warten auf einen schnarchlangsamen C Compiler.

Der schlechte FORTH-Programmierer hat gar keine andere Wahl, als die
Nacht durch zu arbeiten und IRGEND ETWAS abzuliefern, weil er sonst für
seine Wahl einer obsoleten, obskuren Programmiersprache zu Recht vom
Management geköpft wird.   SCNR

Der C/C++ Programmierer hat viele ruhige Nächte, in denen nur der
Compiler für ihn arbeitet. SCNR2

Nun ja, etwas C-bashing muß ab und an mal sein ;-)

DoDi

 

[Helmut Schellong]

Am 21.09.2023 um 16:42 schrieb Hans-Peter Diettrich:

On 9/21/23 2:42 PM, Helmut Schellong wrote:

Seit wann werden sonstige Kommandos eines Entwicklungssystems als Bestandteil
des Compilers und als interne Programmiersprachen der Sprache C angesehen?

Fiel mir erst später auf, gemeint waren \"formale\" Sprachen.

C ist eine Touring-vollständige Programmiersprache 3GL.
Alle weiteren oben aufgeführten Kommandos nicht.

Was willst Du damit sagen?

Daß C kein Konglomerat aus den aufgeführten Kommandos ist.

Der C-Standard definiert die Sprache C.
In der Sprache C ist das Preprocessing untrennbar enthalten.

Also doch ein Konglomerat von Sprachen ;-)

Das Preprocessing ist keine Sprache!
Sondern wie bei einem Zwei-Pass-Assembler der erste Pass (Durchlauf).

Ich gebrauche Make, M4 und Autobloat für meine C-Projekte nicht.

Dann fummelst Du also so alleine vor Dich hin?

Ja, andere stören mich nur.

Der C-Standard beschreibt diese Kommandos nicht.
Sie sind kein Bestandteil der Sprache C.

Aber für die Herstellung portabler Programme sind sie unverzichtbar, sagt die FSF.

make, M4 und Autobloat sollen unverzichtbar sein, um portable Programme schreiben zu können.
Wie soll das denn funktionieren?
make, M4 und Autobloat schreiben selbsttätig einen portablen Inhalt der C-Dateien?
Das schafft noch nicht einmal eine KI, auch nicht, wenn sie 100 Mio kostet.

Eine Methode für portables Programmieren ist, dem C-Standard strikt zu folgen.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hergen Lehmann]

Am 21.09.23 um 16:53 schrieb Hans-Peter Diettrich:

On 9/21/23 2:44 PM, Hergen Lehmann wrote:
Seitdem wurde die Sprache kontinuierlich weiter entwickelt, und in
aktuellen Versionen lässt sich sehr komfortabel gut lesbarer und
sicherer Code schreiben.

Das kann nur jemand behaupten, der Delphi nicht kennt, und vielleicht
auch sonst keine benutzerfreundlicheren Sprachen.

Ich war vor langer Zeit mal für die Wartung einer Delphi-Applikation
zuständig. Das war hübsch fürs UI-Prototyping, aber eine Katastrophe,
sobald man etwas näher an die Hardware heran musste.

Vor allem aber ist es hochgradig proprietär. Man ist auf Gedeih und
Verderb einem einzelnen Lieferanten und dessen (Lizenz-)Kapriolen
ausgeliefert. Wie oft hat die Produktfamilie jetzt schon Namen und
Besitzer gewechselt? Und Zielplattformen jenseits des
PC+Smartphone-Mainstream sind auch nicht.


> Nun ja, etwas C-bashing muß ab und an mal sein ;-)

Aber bitte mit Niveau. Dumme Sprüche sind langweilig.

 

[Helmut Schellong]

Am 21.09.2023 um 16:53 schrieb Hans-Peter Diettrich:

On 9/21/23 2:44 PM, Hergen Lehmann wrote:
Am 21.09.23 um 12:12 schrieb Wolfgang Allinger:

C tut weh! (*)
[...]
Auf einer pdp ging das ganz einfach im Kopf, keine Notwendigkeit zum Warten auf einen
schnarchlangsamen C Compiler.


Der schlechte FORTH-Programmierer hat gar keine andere Wahl, als die Nacht durch zu arbeiten und
IRGEND ETWAS abzuliefern, weil er sonst für seine Wahl einer obsoleten, obskuren
Programmiersprache zu Recht vom Management geköpft wird.   SCNR

Der C/C++ Programmierer hat viele ruhige Nächte, in denen nur der Compiler für ihn arbeitet. SCNR2

Nun ja, etwas C-bashing muß ab und an mal sein ;-)

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in 3,7s.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Wolfgang Allinger]

On 21 Sep 23 at group /de/sci/electronics in article 650C329F.14B4EC2C@proton.me
<carla_schn@proton.me> (Carla Schneider) wrote:

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article
uegt1gUl1fuL1@news.in-ulm.de <spamless@gmx.de> (Holger Schieferdecker)
wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

(*) C ist zB: (*(void(*)())0)()

Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion
aufgerufen die an Adresse Null liegt.

Hab das ; weggelassen, da IMHO nicht relevant

Auf einem PC gibt das ein Segmentation
fault, aber ich will nicht ausschliessen dass es Systeme gibt wo an Adresse
0 eine wichtige Funktion liegt die er auf diese Weise aufgerufen hat,
vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist ja
manches moeglich.

Einige uC haben an der Adresse 0000 einen Vector auf die Kaltstartroutine.
Hab bei diesem Speibiel vergessen, was es für ein uC war.

Für mich sind i.a. alle uC gleich bzw. ähnlich, da ich mit FORTH
arbeite(te)

Nur ein paar spezielle Register Zugriffe und hochfrequente IRSV schreibe
ich ggf. in Assembler (um), nachdem ich sie vorher als HLL \':\'
Definitionen ausprobiert habe.
:-def als Vorbild für CODE-def. Sehr schnell und einfach, da die funzende
HLL-def ja die Struktur und Funktion vorgibt.

Vielleicht ist es auch ein Test fuer ein fehlertolerantes Programm
das dieses Signal abfaengt statt abzustuerzen.


Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.

Dann hat er es in der gegebenen Zeit wohl nicht geschafft.

Na denn!

Wer weiss, für was der Obige Müll gut ist?

Er wollte halt nicht extra einen Pointer auf eine Funktion definieren,
dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar Byte
einsparen.


Auflösung auf Anfrage

Du hast es recht gut getroffen.
in Z80 Assembler:
LD HL,0000h
JMP (HL)

Also die SW Emulation eines HW PWR up






Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 21 Sep 23 at group /de/sci/electronics in article 4eqttj-u7rc3.ln1@hergen.spdns.de
<hlehmann.expires.12-22@snafu.de> (Hergen Lehmann) wrote:

Am 21.09.23 um 12:12 schrieb Wolfgang Allinger:

C tut weh! (*)

K&R C war seinerzeit ein *TRAUM* gegenüber der für die
Systemprogrammierung einzig verfügbaren Alternative, dem Assembler.

Seitdem wurde die Sprache kontinuierlich weiter entwickelt, und in
aktuellen Versionen lässt sich sehr komfortabel gut lesbarer und
sicherer Code schreiben.

Der C-Programmierer hat den Compiler im Kopf.

Ich arbeite heute zwar überwiegend mit C++, aber auch zu C-Zeiten habe
ich nie ein Programm von Hand compiliert.

Damit war gemeint, dass der C-Programmierer im Kopf haben muss, was der
Compiler veranstaltet.

Der FORTH-Programmierer hat den Compiler im Target.

Wenn mich meine Erinnerung nicht täuscht, \"compiliert\" FORTH lediglich
in eine Art Zwischencode, welcher auf 99.9998% der verfügbaren Hardware
anschließend interpretiert wird.
Es gab zwar mal auf FORTH optimierte Hardware, aber das war eine Nische
in der Nische in der Nische.

Nein, Du irrst. FORTH schaltet zwischen Interpreter und Compiler ständig
hin und her. Kommt drauf an, was da gerade im Eingabestrom gefunden wird.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

Der schlechte FORTH-Programmierer hat gar keine andere Wahl, als die
Nacht durch zu arbeiten und IRGEND ETWAS abzuliefern, weil er sonst für
seine Wahl einer obsoleten, obskuren Programmiersprache zu Recht vom
Management geköpft wird. SCNR

Aber er hat was vorzuweisen. Typischerweise ist ein Forth Programmierer
2-30! mal produktiver, als ein C-Programmierer.

Da staunen dann die Jeffes

There are always strange people, doing strange things! Watch them!!!

Latürnich kann man auch sehr produktiv Scheisse bauen.
Einfach mal \"-1 EXECUTE <CR>\" eintippern

Ich hab etliche Projekte als Rapid-Prototyping gemacht, die dann
anschließend in eine andere Programmiersprache umgesetzt worden

(*) C ist zB: (*(void(*)())0)()

Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.
Na denn!

In jeder Programmiersprache lässt sich unleserlicher, unkommentierter
Code schreiben. Was willst du hier beweisen?

Ich nix, ist was, was ich gefunden habe, bei einem gecrashten Projekt!

Wer weiss, für was der Obige Müll gut ist?

Auf den ersten Blick: Liest aus Speicheradresse 0 einen Zeiger auf eine
Funktion, welche dann aufgerufen wird. Klingt nach einer Knobelaufgabe
aus dem Programmierkurs und nicht nach realem Code.

Obwohl, ein Anwendungsfall fällt mir ein: Die verwendete CPU hat dort
ihren Reset-Vektor stehen und es soll so ein Soft-Reset ausgeführt werden.

Jau, BINGO!



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Hans-Peter Diettrich]

On 9/21/23 6:18 PM, Helmut Schellong wrote:

> Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in 3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu
übersetzt werden müssen.

DoDi

 

[Hans-Peter Diettrich]

On 9/21/23 5:24 PM, Hergen Lehmann wrote:

Am 21.09.23 um 16:53 schrieb Hans-Peter Diettrich:

On 9/21/23 2:44 PM, Hergen Lehmann wrote:
Seitdem wurde die Sprache kontinuierlich weiter entwickelt, und in
aktuellen Versionen lässt sich sehr komfortabel gut lesbarer und
sicherer Code schreiben.

Das kann nur jemand behaupten, der Delphi nicht kennt, und vielleicht
auch sonst keine benutzerfreundlicheren Sprachen.

Ich war vor langer Zeit mal für die Wartung einer Delphi-Applikation
zuständig. Das war hübsch fürs UI-Prototyping, aber eine Katastrophe,
sobald man etwas näher an die Hardware heran musste.

Vor allem aber ist es hochgradig proprietär. Man ist auf Gedeih und
Verderb einem einzelnen Lieferanten und dessen (Lizenz-)Kapriolen
ausgeliefert.

Es gibt noch FreePascal/Lazarus, damit lassen sich auch µC
programmieren. Die Architektur ist unerreicht was Projekt-Management,
turn-around Zeiten und Fehlersuche betrifft. Aber wer nur C kennt, der
weiß nicht, was ihm in dieser Hinsicht alles entgeht.

DoDi

 

[Carla Schneider]

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article 650C329F.14B4EC2C@proton.me
carla_schn@proton.me> (Carla Schneider) wrote:

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article
uegt1gUl1fuL1@news.in-ulm.de <spamless@gmx.de> (Holger Schieferdecker)
wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

(*) C ist zB: (*(void(*)())0)()

Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion
aufgerufen die an Adresse Null liegt.

Hab das ; weggelassen, da IMHO nicht relevant

Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Auf einem PC gibt das ein Segmentation
fault, aber ich will nicht ausschliessen dass es Systeme gibt wo an Adresse
0 eine wichtige Funktion liegt die er auf diese Weise aufgerufen hat,
vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist ja
manches moeglich.

Einige uC haben an der Adresse 0000 einen Vector auf die Kaltstartroutine.
Hab bei diesem Speibiel vergessen, was es für ein uC war.

Für mich sind i.a. alle uC gleich bzw. ähnlich, da ich mit FORTH
arbeite(te)

Und wie sieht dieser Aufruf in FORTH aus, nur so zum Vergleich ?
Wenn ich mich recht erinnere ist das eine Sprache die so um 1990 herum
populaer war.

Nur ein paar spezielle Register Zugriffe und hochfrequente IRSV schreibe
ich ggf. in Assembler (um), nachdem ich sie vorher als HLL \':\'
Definitionen ausprobiert habe.
:-def als Vorbild für CODE-def. Sehr schnell und einfach, da die funzende
HLL-def ja die Struktur und Funktion vorgibt.

Vielleicht ist es auch ein Test fuer ein fehlertolerantes Programm
das dieses Signal abfaengt statt abzustuerzen.


Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :]
in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.

Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei
überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht.

Dann hat er es in der gegebenen Zeit wohl nicht geschafft.

Na denn!

Wer weiss, für was der Obige Müll gut ist?

Er wollte halt nicht extra einen Pointer auf eine Funktion definieren,
dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar Byte
einsparen.

Gemeint ist natuerlich dort die Adresse hineinschreiben die auf Adresse gespeichert ist.

Auflösung auf Anfrage

Du hast es recht gut getroffen.
in Z80 Assembler:
LD HL,0000h
JMP (HL)

Ist nicht genau das gleiche weil kein Funktionsaufruf, aber egal
weil der Hardware-Reset den Stapel auf Null setzt.

Also die SW Emulation eines HW PWR up

Waere also etwas das in den Libraries zu diesem System
drin sein sollte, z.B. als Funktion mit Namen \"hw_reset\".

Weil es das offenbar nicht war, musste
sich der Programmierer so abhelfen.

Das ganze ist aber kein Beispiel dafuer das zeigt
ob FORTH besser ist als C oder umgekehrt.