Wirkungsgrad von 100 m RG213U...

[Hartmut Kraus]

Am 23.09.23 um 01:30 schrieb Hans-Peter Diettrich:

On 9/22/23 10:49 AM, Hergen Lehmann wrote:
Am 22.09.23 um 00:23 schrieb Wolfgang Allinger:

Ein C-Programmierer sollte verstanden haben, was ein Zeiger ist, das ist aber auch alles.

Wer nicht weiß, daß Zugriffe über Pointer nicht überwachbar sind, hat die Konsequenzen nicht verstanden. Eine sichere Sprache kommt ohne Pointer aus, ohne an Effizienz zu verlieren.


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

Und wenn er compiliert, compiliert er in echten Maschinencode?

Ein Compiler erzeugt oft auch nur Aufrufe von Bibliotheksfunktionen. Da kann threaded Code auch mal schneller sein. Und FORTH ist auch nicht mehr das, was es mal war. Siehe auch Wikipedia zu Forth:

there are modern implementations that generate optimized machine code like other language compilers.


Wie soll das gehen, bei einer Stack-orientierten Spracharchitektur und Mikrocontrollern, deren Hardware-Stack teilweise auf eine handvoll Ebenen beschränkt ist?

In welcher Sprache läßt sich so ein Zwerg programmieren, außer in Assembler?

Vielleicht in C?

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

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

 

[Hartmut Kraus]

Am 23.09.23 um 01:55 schrieb Wolfgang Allinger:
> Bin von Haus aus HW-bitpopler, Hardcore-Assemblierer und Elektroniker.

Von der alten Garde, sozusagen.

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

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

 

[Hans-Peter Diettrich]

On 9/23/23 9:25 AM, Hartmut Kraus wrote:

Am 23.09.23 um 00:50 schrieb Hans-Peter Diettrich:
Bei der Konvertierung eines Komprimierungsprogramms (zip?) von C nach
Delphi bin ich auf einen Fehler gestoßen, der schon 10 Jahre lang
unentdeckt im Quelltext gelauert hat. D.h. nicht ich habe den Fehler
gefunden, sondern der Compiler.

Nicht schlecht. Ausgerechnet ein Komprimierungsprogramm, wie sie
massenweise eingesetzt werden. Ist der Fehler noch drin?

Nein, als ich den Fehler gemeldet habe hat sich herausgestellt, daß er
ein paar Wochen vorher schon gefixt worden war. Ich habe allerdings
vergessen zu fragen, wie lange der Fehler zuvor schon drin war.

Oder kriegt man
mit der \"fehlerfreien\" Version Dateien, die mit der \"fehlerhaften\"
gepackt sind, nie wieder entpackt ...

Der Fehler tritt nur sehr selten auf, deshalb wurde er ja zuvor nicht
bemerkt. Die ganze Geschichte ist schon über 10 Jahre her, allerdings
habe ich seitdem auch nicht mehr kontrolliert. Es können sich also
durchaus neue Fehler eingeschlichen haben, wie das bei unsicheren
Programmiersprachen immer wieder vorkommt.

DoDi

 

[Helmut Schellong]

Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:

On 9/22/23 10:07 AM, Stefan Ram wrote:
Carla Schneider <carla_schn@proton.me> writes:
Der Preprozessor ist auch kein Teil von C

   Die Programmiersprache C wird durch die ISO/IEC 9899
   beschrieben. Und diese Beschreibung umfaßt auch den
   Präprozessor:

Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax haben, also unterschiedliche
formale Sprachen darstellen.

Nein, beispielsweise
# if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ist C.

Es gibt keine separate Präprozessor-Sprache.
Der C-Standard beschreibt _nur_ die Sprache C.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:

On 9/22/23 10:54 AM, Stefan Ram wrote:

   In Python ist es auch möglich, Teile einer Bibliothek oder
   eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 00:50 schrieb Hans-Peter Diettrich:

On 9/22/23 11:12 AM, Helmut Schellong wrote:

Ich hatte im Jahr 2000 rechts von mir einen Kollegen, Tarek, sitzen, der mit Delphi programmierte.
Ich bekam mit, wie sehr er sich mit Delphi abmühen mußte.
Delphi verlangte dauernd krampfartige Zusatzarbeiten, wenn man z.B. nur etwas
bitweise Undieren wollte.

Genau das ist eine Stärke von Delphi, mit Sets etc.
Natürlich muß man seine Sprache auch kennen, wenn man damit komfortabel arbeiten möchte.

Da gab es den Typ Kardinal, 29 Bit breit oder so - Hää?!

Quatsch mit Soße :-(
Du offenbarst immer mehr Deine Unkenntnis von Delphi. Da stellt sich praktisch jeder Deiner
Kritikpunkte an Delphi als tatsächlicher Vorteil heraus! Mach nur weiter so ;-)

Falsche Adresse!
Der Kollege Tarek, neben mir sitzend, erzählte mir das alles!
Verstehst Du kein Deutsch?, der einleitende Absatz oben ist doch eindeutig formuliert.

Ich selbst kenne nur Pascal, Delphi gar nicht.

Welchen Wertebereich hat denn nun der Typ Cardinal?
Der Kollege Tarek nannte mir eine Bitbreite kleiner als 32.

> C/C++ ist mit int, long und long long <schauder> viel unpräziser als Delphi.

Es gibt seit langer Zeit die Typen
int32_t uint32_t uint8_t int16_t ...
in C.
Sogar fast_int32_t (oder ähnlich), ...

Wenn Du schon auf exotische Datentypen hinaus möchtest, da sind die Delphi Subranges jedem anderen
bit/byte-size Gehampel haushoch überlegen. Ob die jemals Einzug in C++ halten werden? Vermutlich
nicht, wer zu viel C/C++ programmiert ist hoffnungslos in seiner Blase gefangen.

Siehe oben.

Ja, Delphi macht Tests zur Runtime.
Man merkt das deutlich!
Brauche ich nicht, ich sorge selbst für Vorabsicherheit, plausible Werte, etc.

Das Schöne an den Runtime-Tests ist, daß man sie in den Projekt-Optionen einfach global, unitweise
oder lokal ein- und ausschalten kann, Debug und Release Versionen ohne großen Aufwand. Zudem kosten
die Runtime-Tests so wenig Laufzeit, daß ich sie meist eingeschaltet lasse. Wo bleiben denn solche
Testmöglichkeiten in C/C++?

Pascal habe ich mal als 5-fach langsamer als C gemessen.
Ich verzichte daher gerne auf runtime-Tests.

Solche kann ich in C explizit und ausgesucht implementieren.
In C gibt es assert(), abort(), longjmp().


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 00:50 schrieb Hans-Peter Diettrich:

On 9/22/23 10:31 AM, Hergen Lehmann wrote:
Am 22.09.23 um 00:45 schrieb Hans-Peter Diettrich:
[...]

Mit OPL bin ich völlig zufrieden, da fehlt es an keinem Sprachmittel. Und mit dem Tandem
Delphi/CBuilder wäre ich restlos glücklich, wenn da nicht der Wildwuchs im C/C++ Standard wäre, der
ständig neue C++ Compiler erforderlich macht.

Es gibt keinen C/C++-Standard!

C und C++ haben jeweils einen eigenen ISO-Standard.
Die regelmäßige ISO-Standardisierung verhindert auch Wildwuchs.
Es gibt keinen Wildwuchs im C-Standard.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 01:35 schrieb Wolfgang Allinger:

On 22 Sep 23 at group /de/sci/electronics in article 650D324B.1EC4A3D7@proton.me
carla_schn@proton.me> (Carla Schneider) wrote:

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!\".

[...]

Hab das ; weggelassen, da IMHO nicht relevant

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

Dunkel ist der Sinn Deiner Frage

Das \';\' zeigt (in C) das Ende von Anweisungen an.
In Shell-Skripten zeigen \';\' oder \'Newline\' das Ende von Kommandos an.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hartmut Kraus]

Am 23.09.23 um 14:05 schrieb Helmut Schellong:

Am 23.09.2023 um 01:35 schrieb Wolfgang Allinger:

On 22 Sep 23 at group /de/sci/electronics in article 650D324B.1EC4A3D7@proton.me
carla_schn@proton.me>  (Carla Schneider)  wrote:
Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Dunkel ist der Sinn Deiner Frage

Das \';\' zeigt (in C) das Ende von Anweisungen an.
In Shell-Skripten zeigen \';\' oder \'Newline\' das Ende von Kommandos an.

Du mögest den signifikanten Unterschied zwischen \"Anweisung\" und \"Kommando\" erläutern. Ach ich hab\' noch was: \"Befehl\" (neudeutsch: \"Statement\").

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

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

 

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Sat, 23 Sep 2023 13:39:57 +0200:

C und C++ haben jeweils einen eigenen ISO-Standard.
Die regelmäßige ISO-Standardisierung verhindert auch Wildwuchs.
Es gibt keinen Wildwuchs im C-Standard.

Richtig, es gibt doch schon ausreichend viele dieser Standards.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

Du schriebst am Sat, 23 Sep 2023 00:50:49 +0200:

[Pascal, Delphi]

danach nur noch Wildwuchs herrschte, mit zahlreichen Queranleihen
zwischen den Entwicklungslinien, aber keiner garantierten Portabilität.
Wenn der (englische) Wikipedia-Artikel stimmt, hat FreePascal selbst
heute noch keine vollständige Kompatibilität zu der o.g. Norm.... :-(

Welche Norm?

Het er doch geschrieben, IEEE/ANSI 770X3.160-1989 von 1989. Es gab aber
durchaus noch weitere Entwicklung auch im Standard-Bereich, wobei der
Standard des \"ISO Extended Pascal\", ISO/IEC 10206 (Ausgabedatum kann ich
grade nicht finden) recht interessant sein dürfte. Der hatte ein volles
Modul-Konzept, Exception-Handling und Ansätze zur objektorientierten
Programmierung. Ich hatte mir dazu einen Compiler (1994) geleistet, den
aber nicht allzu intensiv einsetzen können, lediglich für ein paar private
Anwendungen. Ein \"richtiges\" Projekt in Pascal kam erst später, mit FPC
(unter Linux) und - nicht Lazarus. Lazarus hatte da noch keinen brauchbaren
Stand erreicht, deshalb hatte ich mich nach einer Alternative umgesehen und
ein \"RAD\"-System namens \"mseide-msegui\" gefunden. Das hatte alle nötigen
Funktionen und - vor allem - war stabil, schon u der Zeit. Es war nur nicht
recht bekannt, wohl weil es eher eine \"one man show\" war, wenn auch mit
einer regen Mailing-Litse für die Anwender. Es gibt es immer noch, und es
wurde und wird weiterentwickelt, wenn auch nur von einer kleinen Mannschaft.

> Pascal war ein einfaches Lehrstück für den Compilerbau. Deshalb wurden

Ursprünglich, sogar in einem Buch dokumentiert: Algorithmen und
Datenstrukturen, Niklaus Wirth, Professor an der ETH Zürich.
Am Titel kann man erkennen, daß es dabei nicht primär darum ging, eine
Programmiersprache zu entwickeln.
Daß es über diverse Zwischenstufen trotdem zuz einer gewissen Verbreitung,
und anfangs sogar zu einer recht weiten Verbreitung (z.B. UCSD-Pascal)
kam, ist ja wohl eher größeren Problemen mit konkurrierenden Ansätzen
geschuldet. Daß dann später trotzdem die Programmiersprache mit dem größten
Fehlerpotential überhand nahm, liegt wohl eher daran, daß es sehr viel mehr
Usanier als Schweizer gibt und sehr viel mehr Manager als Professoren...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Hans-Peter Diettrich]

On 9/23/23 12:54 PM, Helmut Schellong wrote:

Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:54 AM, Stefan Ram wrote:

   In Python ist es auch möglich, Teile einer Bibliothek oder
   eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.

sagt der, der von Delphi nachweislich keine Ahnung hat :-(

Und wie soll ein Assembler schnelleren binären Code erzeugen als der
Programmierer in Mnemocodes hingeschrieben hat?

DoDi

 

[Hans-Peter Diettrich]

On 9/23/23 12:49 PM, Helmut Schellong wrote:

Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:07 AM, Stefan Ram wrote:
Carla Schneider <carla_schn@proton.me> writes:
Der Preprozessor ist auch kein Teil von C

   Die Programmiersprache C wird durch die ISO/IEC 9899
   beschrieben. Und diese Beschreibung umfaßt auch den
   Präprozessor:

Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax
haben, also unterschiedliche formale Sprachen darstellen.

Nein, beispielsweise
   # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ist C.

Es gibt keine separate Präprozessor-Sprache.
Der C-Standard beschreibt _nur_ die Sprache C.

Ich schicke Dir mal ein paar von den Zeichen, die zwischen C und
Präprozessor Syntax umschalten:
# # # # # # # #

DoDi

 

[Hans-Peter Diettrich]

On 9/23/23 1:39 PM, Helmut Schellong wrote:

Es gibt keinen C/C++-Standard!

C und C++ haben jeweils einen eigenen ISO-Standard.

Seltsam, die ISO Drafts, die frei erhältlich sind, enthalten immer alle
drei Sprachen gemeinsam: Präprozessor, C und C++.

DoDi

 

[Hans-Peter Diettrich]

On 9/23/23 1:29 PM, Helmut Schellong wrote:

Am 23.09.2023 um 00:50 schrieb Hans-Peter Diettrich:
On 9/22/23 11:12 AM, Helmut Schellong wrote:

Du offenbarst immer mehr Deine Unkenntnis von Delphi. Da stellt sich
praktisch jeder Deiner Kritikpunkte an Delphi als tatsächlicher
Vorteil heraus! Mach nur weiter so ;-)

Falsche Adresse!
Der Kollege Tarek, neben mir sitzend, erzählte mir das alles!
Verstehst Du kein Deutsch?, der einleitende Absatz oben ist doch
eindeutig formuliert.

Ach so, Du lernst Sprachen indem Du irgendwelchen Leuten zuhörst, die
auch nur wenig Ahnung haben? Dann wundert mich allerdings nichts mehr.


> Siehe oben.

dto.

> Pascal habe ich mal als 5-fach langsamer als C gemessen.

Ich kenne C Compiler die noch viel langsameren Code erzeugen.
Insbesondere wenn die Benchmarks von Leuten geschrieben werden, welche
die zu testenden Sprachen und Compiler nur vom Hörensagen her kennen.

Solche kann ich in C explizit und ausgesucht implementieren.
In C gibt es assert(), abort(), longjmp().

Nun ja, wenn Du die immer an allen Stellen hinschreibst?

Von SEH hast Du möglicherweise auch noch nichts gehört?

DoDi

 

[Helmut Schellong]

Am 23.09.2023 um 20:41 schrieb Sieghard Schicktanz:

Hallo Helmut,

Du schriebst am Sat, 23 Sep 2023 13:39:57 +0200:

C und C++ haben jeweils einen eigenen ISO-Standard.
Die regelmäßige ISO-Standardisierung verhindert auch Wildwuchs.
Es gibt keinen Wildwuchs im C-Standard.

Richtig, es gibt doch schon ausreichend viele dieser Standards.

Nein, es gibt immer nur einen C-Standard.
Jeder neue Standard ersetzt seinen Vorgänger.
Der Vorgänger ist dadurch ungültig.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 21:54 schrieb Hans-Peter Diettrich:

On 9/23/23 12:54 PM, Helmut Schellong wrote:
Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:54 AM, Stefan Ram wrote:

   In Python ist es auch möglich, Teile einer Bibliothek oder
   eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.

sagt der, der von Delphi nachweislich keine Ahnung hat :-(

Was hat Delphi mit dem gequoteten Text oben zu tun?
Nichts!
Ich habe selbst gesagt, daß ich von Delphi keine Ahnung habe.

Python soll doch durch Zuhilfenahme von C beschleunigt werden.
So steht es oben.
Das geht auch erfolgreich mit C, weil C zum schnellsten Maschinen-Code generiert wird.
Für andere 3GL-Sprachen gilt dies jedoch nicht.

Und wie soll ein Assembler schnelleren binären Code erzeugen als der Programmierer in Mnemocodes
hingeschrieben hat?

Ein wirrer Satz.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 22:05 schrieb Hartmut Kraus:

Am 23.09.23 um 14:05 schrieb Helmut Schellong:
Am 23.09.2023 um 01:35 schrieb Wolfgang Allinger:

On 22 Sep 23 at group /de/sci/electronics in article 650D324B.1EC4A3D7@proton.me
carla_schn@proton.me>  (Carla Schneider)  wrote:
Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Dunkel ist der Sinn Deiner Frage

Das \';\' zeigt (in C) das Ende von Anweisungen an.
In Shell-Skripten zeigen \';\' oder \'Newline\' das Ende von Kommandos an.

Du mögest den signifikanten Unterschied zwischen \"Anweisung\" und \"Kommando\" erläutern. Ach ich
hab\' noch was: \"Befehl\" (neudeutsch: \"Statement\").

Shell-Skripte enthalten eine Kommando-Programmiersprache.
Für C-Quellen gilt dies nicht.
Kommando lautet übersetzt command, jedoch nicht statement.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 9/23/23 9:11 PM, Sieghard Schicktanz wrote:

ein \"RAD\"-System namens \"mseide-msegui\" gefunden. Das hatte alle nötigen
Funktionen und - vor allem - war stabil, schon u der Zeit. Es war nur nicht
recht bekannt,

Ich habe mich selbst auch dafür interessiert, aber ein Blick in den
Quelltext hat bei mir fast Augenkrebs verursacht, domit konnte ich
nichts anfangen. Vielleicht ging es noch mehr Leuten so, so daß

wohl weil es eher eine \"one man show\" war, wenn auch mit
einer regen Mailing-Litse für die Anwender. Es gibt es immer noch, und es
wurde und wird weiterentwickelt, wenn auch nur von einer kleinen Mannschaft.

Daß dann später trotzdem die Programmiersprache mit dem größten
Fehlerpotential überhand nahm, liegt wohl eher daran, daß es sehr viel mehr
Usanier als Schweizer gibt und sehr viel mehr Manager als Professoren...

Böse Zungen behaupten, daß es hauptsächlich um die Stellensicherug aller
Beteiligten ging, bis hin zu Bjarne Stroustrup, die deshalb eine
möglichst komplizierte und kryptische Sprache favorisierten. Wie bei
COBOL seinerzeit kommt es nur drauf an, wie man den Leuten am Geldhahn
etwas schmackhaft machen kann. Bis hin zu \"Millionen Fliegen können
nicht irren...\".

DoDi

 

[Helmut Schellong]

Am 23.09.2023 um 22:08 schrieb Hans-Peter Diettrich:

On 9/23/23 12:49 PM, Helmut Schellong wrote:
Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:07 AM, Stefan Ram wrote:
Carla Schneider <carla_schn@proton.me> writes:
Der Preprozessor ist auch kein Teil von C

   Die Programmiersprache C wird durch die ISO/IEC 9899
   beschrieben. Und diese Beschreibung umfaßt auch den
   Präprozessor:

Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax haben, also unterschiedliche
formale Sprachen darstellen.

Nein, beispielsweise
    # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ist C.

Es gibt keine separate Präprozessor-Sprache.
Der C-Standard beschreibt _nur_ die Sprache C.

Ich schicke Dir mal ein paar von den Zeichen, die zwischen C und Präprozessor Syntax umschalten:
 # # # # # # # #

Dieses Zeichen ist syntaktischer Bestandteil der Sprache C.
# und ## gehören zu den Punktuatoren der Sprache C.
Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

--
Mit freundlichen Grüßen
Helmut Schellong