Wirkungsgrad von 100 m RG213U...

[Helmut Schellong]

Am 23.09.2023 um 22:11 schrieb 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++.

Nein.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 9/23/23 11:00 PM, Helmut Schellong wrote:

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?

Du mußtest den Bezug ja unbedingt löschen, um Deine Schande nicht
zugeben zu müssen.

Nichts!
Ich habe selbst gesagt, daß ich von Delphi keine Ahnung habe.

Aber Du schreibst gerne über alles, von dem Du wenig bis keine Ahnung hast.

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.

Sagt der, der diese \"anderen\" Sprachen zugegebenermaßen nicht kennt.

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

Ein wirrer Satz.

Immer noch klarer als der, den Du - oh Wunder - wieder einmal nicht
zitiert hast. Zur Erinnerung, Du hast geschrieben:
>>
Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.
<<

DoDi

 

[Hans-Peter Diettrich]

On 9/23/23 10:46 PM, Helmut Schellong wrote:

Am 23.09.2023 um 20:41 schrieb Sieghard Schicktanz:

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.

Was geht mich mein saudummes Geschwätz von gestern an?

SCNR

DoDi

 

[Helmut Schellong]

Am 23.09.2023 um 22:19 schrieb 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.

Ich lerne Sprachen, indem ich ein gutes Buch zu der jeweiligen Sprache komplett lese.

Kannst Du kein Deutsch?
Ich habe doch selbst gesagt, daß ich von Delphi keine Ahnung habe.
Folglich habe ich Delphi auch nicht von dem Kollegen Tarek gelernt.

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?

Warum sollte ich das tun?
Ich würde mir selbst doch dadurch widersprechen!
Steht 7 Zeilen zuvor.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 23:26 schrieb Hans-Peter Diettrich:

On 9/23/23 11:00 PM, Helmut Schellong wrote:
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?

Du mußtest den Bezug ja unbedingt löschen, um Deine Schande nicht zugeben zu müssen.

Was mit Bezug habe ich denn aus dem Nachfolgenden gelöscht?:

|Man kann es schlecht genau in Prozent messen, aber die
|Standardimplementationen von Java oder Python (Compiler
|beziehungsweise Interpretierer und Laufzeitumgebungen) sind in
|C oder C++ geschrieben, genauso wie führende Betriebssysteme,
}Browser, Datenbanken oder Office-Pakete.

|In diesem Sinne beruht die Infrastruktur auf C oder C++.
|Darauf aufbauend werden dann sicher auch andere Programmiersprachen
|verwendet.

|In Python ist es auch möglich, Teile einer Bibliothek oder ***
|eines Programms zur Beschleunigung in C zu schreiben, und ***
|verschiedene Python-Software macht davon Gebrauch. Daher
|müßte man Software, die als \"Python-Software\" bekannt ist
|eigentlich \"Python/C-Software\" nennen.

Nichts!
Ich habe selbst gesagt, daß ich von Delphi keine Ahnung habe.

Aber Du schreibst gerne über alles, von dem Du wenig bis keine Ahnung hast.

Was ist das denn alles?

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.

Sagt der, der diese \"anderen\" Sprachen zugegebenermaßen nicht kennt.

Das ist einfach gelogen.
Ich habe bereits geschrieben, daß ich etwa 20 Sprachen _beherrsche_.
C wird zum schnellsten und kleinsten Maschinen-Code generiert, unter den 3GL-Sprachen.
Das ist einfach so - unwiderlegbar.

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

Ein wirrer Satz.

Immer noch klarer als der, den Du - oh Wunder - wieder einmal nicht zitiert hast. Zur Erinnerung,
Du hast geschrieben:

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

Du hast hier den Bezug gelöscht, nicht ich.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.09.2023 um 23:30 schrieb Hans-Peter Diettrich:

On 9/23/23 10:46 PM, Helmut Schellong wrote:
Am 23.09.2023 um 20:41 schrieb Sieghard Schicktanz:

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.

Was geht mich mein saudummes Geschwätz von gestern an?

Keine Ahnung; ist mir zudem egal.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 9/23/23 11:27 PM, Helmut Schellong wrote:

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

Was meint ein C Compiler dann z.B. zu:
>>
#
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
<<


> # und ##   gehören zu den Punktuatoren der Sprache C.

Mit welcher Wirkung?

Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++,
außerhalb einer Präprozessor-Direktive?

> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und
C++ Sprachen.

DoDi

 

[Helmut Schellong]

Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:

On 9/23/23 11:27 PM, Helmut Schellong wrote:

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

Was meint ein C Compiler dann z.B. zu:

#
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4

C verlangt, daß der Code mit defined... hinter einem # steht.
Der Code
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ohne # davor ist daher ungültig.

\'if\' ohne Klammern dahinter [if (expr)] ist bereits falsch.

# und ##   gehören zu den Punktuatoren der Sprache C.

Mit welcher Wirkung?

Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben.

Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer
Präprozessor-Direktive?

Ja, viele sogar.
\'#\' ist keine Präprozessor-Direktive, sondern ein C-Punktuator und PP-Token!

\'if\', \'else\' und \'define\' sind solche PP-Direktiven.
Diese dürfen jeweils nur nach dem Punktuator \'#\' vorkommen.

\'if defined\' entspricht \'ifdef\',
\'if !defined\' entspricht \'ifndef\'.

Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen.

Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst.
Es kann sein, daß Du den C-Standard gar nicht vorliegen hast.
Ich habe jedenfalls mehrere C-Standards von ANSI gekauft.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 24.09.2023 um 01:19 schrieb Helmut Schellong:

Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:
On 9/23/23 11:27 PM, Helmut Schellong wrote:

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

Was meint ein C Compiler dann z.B. zu:
 
#
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4


C verlangt, daß der Code mit defined... hinter einem # steht.
Der Code
   if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ohne # davor ist daher ungültig.

\'if\' ohne Klammern dahinter [if (expr)] ist bereits falsch.

# und ##   gehören zu den Punktuatoren der Sprache C.

Mit welcher Wirkung?

Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben.

|A punctuator is a symbol that has independent syntactic and semantic significance.
|Depending on context, it may specify an operation to be performed
|(which in turn may yield a value or a function designator, produce a side effect, or
|some combination thereof) in which case it is known as an
|operator (other forms of operator also exist in some contexts).
|An operand is an entity on which an operator acts.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hartmut Kraus]

Am 23.09.23 um 23:05 schrieb 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.

Das habe ich auch nicht behauptet. S. Kontext.

--
\"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/24/23 1:19 AM, Helmut Schellong wrote:

Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:
On 9/23/23 11:27 PM, Helmut Schellong wrote:

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

Was meint ein C Compiler dann z.B. zu:
 
#
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4


C verlangt, daß der Code mit defined... hinter einem # steht.

Tut er doch?

Und das verlangt nicht C, sondern der Präprozessor.

Der Code
   if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ohne # davor ist daher ungültig.

Ist kein C, weder syntaktisch noch semantisch, sowas versteht nur der
Präprozessor.

\'if\' ohne Klammern dahinter [if (expr)] ist bereits falsch.

Sag ich doch.

# und ##   gehören zu den Punktuatoren der Sprache C.

Mit welcher Wirkung?

Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben.

Jetzt bin ich aber gespannt:

Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder
C++, außerhalb einer Präprozessor-Direktive?

Ja, viele sogar.

Eines zu ## in C würde mir reichen.

>>> Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

Hast Du schon mal einen Parser für C98 geschrieben?

Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und
C++ Sprachen.

Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst.
Es kann sein, daß Du den C-Standard gar nicht vorliegen hast.
Ich habe jedenfalls mehrere C-Standards von ANSI gekauft.

Dann kannst Du sicher darin finden, welche Wirkung *speziell* der
Punktuator ## *außerhalb* einer Präprozessor-Direktive hat. Ich konnte
dazu nichts finden. Und wenn Du dazu auch nichts finden kannst, dann
erkläre ich diese Diskussion für beendet.

DoDi

 

[Helmut Schellong]

Am 24.09.2023 um 18:30 schrieb Hartmut Kraus:

Am 23.09.23 um 23:05 schrieb 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.

Das habe ich auch nicht behauptet. S. Kontext.

Kommando, Befehl, Befehlsgewalt, kommandieren, befehligen, befehlen.
|\"Befehl\" (neudeutsch: \"Statement\")| stimmt nicht.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 24.09.2023 um 19:51 schrieb Hans-Peter Diettrich:

On 9/24/23 1:19 AM, Helmut Schellong wrote:
Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:
On 9/23/23 11:27 PM, Helmut Schellong wrote:

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

Was meint ein C Compiler dann z.B. zu:
 
#
if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4


C verlangt, daß der Code mit defined... hinter einem # steht.

Tut er doch?

Nein, eine gültige Zeile für den Präprozessor ist nicht auf zwei Zeilen verteilt.

> Und das verlangt nicht C, sondern der Präprozessor.

Nein, der C-Standard verlangt das.

Der Code
    if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4
ohne # davor ist daher ungültig.

Ist kein C, weder syntaktisch noch semantisch, sowas versteht nur der Präprozessor.

Da das Zeichen # nicht den Code anführt, ist es keine Zeile für den Präprozessor.
Ohne das anführende Zeichen # handelt es sich um ungültigen Code.

\'if\' ohne Klammern dahinter [if (expr)] ist bereits falsch.

Sag ich doch.

Ich auch; Der Code ist ungültig.

# und ##   gehören zu den Punktuatoren der Sprache C.

Mit welcher Wirkung?

Die Wirkungen hierzu sind im C-Standard beschrieben, und teilweise oben.

Jetzt bin ich aber gespannt:


Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer
Präprozessor-Direktive?

Ja, viele sogar.

Eines zu ## in C würde mir reichen.

Es kommt darauf an, wie der C-Standard eine PP-Direktive genau definiert.
\'define\' ist jedenfalls ein Direktiven-Name.
\'defined\' ist kein Direktiven-Name.
Weitere Details genau hierzu habe ich nicht im Kopf.

Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

Hast Du schon mal einen Parser für C98 geschrieben?

ISO-C-Standards sind bisher C90, C99, C11, C17, und wahrscheinlich C23 in der Zukunft.
C17 ist vernachlässigbar, da Minor.

Einen direkten C-Parser habe ich bisher nicht geschrieben.
Aber einen C-Parser für Syntax-Highlighting habe ich begonnen.
Die Kommandos findccc und findcs in meiner bish-Shell sind Vorarbeiten zu diesem Projekt.

Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen.

Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst.
Es kann sein, daß Du den C-Standard gar nicht vorliegen hast.
Ich habe jedenfalls mehrere C-Standards von ANSI gekauft.

Dann kannst Du sicher darin finden, welche Wirkung *speziell* der Punktuator ## *außerhalb* einer
Präprozessor-Direktive hat. Ich konnte dazu nichts finden. Und wenn Du dazu auch nichts finden
kannst, dann erkläre ich diese Diskussion für beendet.

Ich schaue mal gründlich nach.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

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

[\"mseide-msegui\"]

Ich habe mich selbst auch dafür interessiert, aber ein Blick in den
Quelltext hat bei mir fast Augenkrebs verursacht, domit konnte ich

Naja, besonderen Wert auf eine lesefreundliche Schreibweise für _andere_
als sich selber hat der Entwickler wahrlich nicht gelegt. Man könnte
meinen, seine Tastatur hatte eine defekte Großschreibetaste...
Aber der Code hat damals sauber funktioniert, war stabil und _wesentlich_
vollständiger als Lazarus. Lazarus hat noch ein paar Jahre und viele
Mitentwickler gebraucht, um soweit zu kommen wie \"mseide-msegui\" schon
sehr früh. Und einiges an Lazarus ist immer noch recht hanebüchen,
lediglich die Dokumentation ist (relativ) exzellent.
Aber niemand muß ein bestimmtes System benutzen, und wenn er das doch will,
ihm aber der Stil nicht gefällt, dann kann er den ja mit einem \"Beautifier\"
nach Gusto anpassen - hast Du solche nicht auch schon geschrieben?

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

 

[Helmut Schellong]

Am 24.09.2023 um 21:03 schrieb Sieghard Schicktanz:

Hallo Hans-Peter,

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

[\"mseide-msegui\"]
Ich habe mich selbst auch dafür interessiert, aber ein Blick in den
Quelltext hat bei mir fast Augenkrebs verursacht, domit konnte ich

Naja, besonderen Wert auf eine lesefreundliche Schreibweise für _andere_
als sich selber hat der Entwickler wahrlich nicht gelegt. Man könnte
meinen, seine Tastatur hatte eine defekte Großschreibetaste...
Aber der Code hat damals sauber funktioniert, war stabil und _wesentlich_
vollständiger als Lazarus. Lazarus hat noch ein paar Jahre und viele
Mitentwickler gebraucht, um soweit zu kommen wie \"mseide-msegui\" schon
sehr früh. Und einiges an Lazarus ist immer noch recht hanebüchen,
lediglich die Dokumentation ist (relativ) exzellent.
Aber niemand muß ein bestimmtes System benutzen, und wenn er das doch will,
ihm aber der Stil nicht gefällt, dann kann er den ja mit einem \"Beautifier\"
nach Gusto anpassen - hast Du solche nicht auch schon geschrieben?

Das erstaunt mich seit den 1980er Jahren.
An der Hochschule 1982 gab es einen Beautifier für PEARL.
Später unter SCO-Unix gab es \'cb\' - C-Beautifier.
Noch später u.a. bei GNU gibt es Beautifier.

Es war schon immer egal, wie /schlecht/ jemandes Code-Stil (angeblich) ist.
Nur Sekunden dauert es, dies zu reparieren, nach eigenem Geschmack.

Es wird aber so getan, als gäbe es diese Möglichkeit nicht.
Man schimpft, wenn jemand es wagt, einen anderen Code-Stil zu haben, als man selbst.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 24.09.2023 um 21:37 schrieb Helmut Schellong:

Am 24.09.2023 um 19:51 schrieb Hans-Peter Diettrich:
On 9/24/23 1:19 AM, Helmut Schellong wrote:
Am 24.09.2023 um 00:10 schrieb Hans-Peter Diettrich:
On 9/23/23 11:27 PM, Helmut Schellong wrote:[...]
Hast Du vielleicht ein Beispiel für die Benutzung von ## in C oder C++, außerhalb einer
Präprozessor-Direktive?

Ja, viele sogar.

Eines zu ## in C würde mir reichen.

Es kommt darauf an, wie der C-Standard eine PP-Direktive genau definiert.
\'define\'  ist jedenfalls ein Direktiven-Name.
\'defined\' ist kein Direktiven-Name.
Weitere Details genau hierzu habe ich nicht im Kopf.

Du scheinst die Semantiken innerhalb eines Standards nicht zu verstehen.

Hast Du schon mal einen Parser für C98 geschrieben?

ISO-C-Standards sind bisher C90, C99, C11, C17, und wahrscheinlich C23 in der Zukunft.
C17 ist vernachlässigbar, da Minor.

Einen direkten C-Parser habe ich bisher nicht geschrieben.
Aber einen C-Parser für Syntax-Highlighting habe ich begonnen.
Die Kommandos findccc und findcs in meiner bish-Shell sind Vorarbeiten zu diesem Projekt.

Sag ich doch: der Standard ist ein Konglomerat aus Präprozessor, C und C++ Sprachen.

Ist er nicht, Du denkst das nur, weil Du Standards nicht richtig verstehst.
Es kann sein, daß Du den C-Standard gar nicht vorliegen hast.
Ich habe jedenfalls mehrere C-Standards von ANSI gekauft.

Dann kannst Du sicher darin finden, welche Wirkung *speziell* der Punktuator ## *außerhalb* einer
Präprozessor-Direktive hat. Ich konnte dazu nichts finden. Und wenn Du dazu auch nichts finden
kannst, dann erkläre ich diese Diskussion für beendet.

Ich schaue mal gründlich nach.

==============================================================================================
A preprocessing directive consists of a sequence of preprocessing tokens that satisfies
the following constraints:
The first token in the sequence is a # preprocessing token that (at the start of translation
phase 4) is either the first character in the source file
(optionally after white space containing no new-line characters)
or that follows white space containing at least one new-line character.
The last token in the sequence is the first new-line character
that follows the first token in the sequence.
==============================================================================================

Vorstehend wird die Angelegenheit klargestellt.
Viele andere Texte befinden sich (scheinbar) im Widerspruch zum Vorstehenden.
Eine PP-Direktive besteht folglich aus der gesamten PP-Zeile, von # bis zur NL.
Das war mir nicht klar.
Ich dachte, beispielsweise \'# define\' sei eine PP-Direktive.
Das ist jedoch nur der Direktiven-Name.

Obwohl ich hier irrte, bedeutet dies nicht, daß der C-Standard ein Konglomerat
aus den Sprachen \'Präprozessor\', \'C\' und \'C++\' ist.

.. Programming languages — C
This document specifies the form and establishes the interpretation of programs
.. expressed in the programming language C.

Vorstehender Text ist eindeutig.
Es werden keine weiteren Sprachen im C-Standard beschrieben.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Sun, 24 Sep 2023 22:49:24 +0200:

[\"Beautifier\"].

Es war schon immer egal, wie /schlecht/ jemandes Code-Stil (angeblich)
ist. Nur Sekunden dauert es, dies zu reparieren, nach eigenem Geschmack.

Es wird aber so getan, als gäbe es diese Möglichkeit nicht.
Man schimpft, wenn jemand es wagt, einen anderen Code-Stil zu haben, als
man selbst.

Und zu recht: Es besteht dabei halt _immer_ die Gefahr, daß ein solcher
\"Beautifier\" neben der Umformatierung noch anderes am Code ändert. Anderes,
das zwar nicht beabsichtigt war, aber u.U. den Code so ändert, daß er nicht
mehr tut, was er sollte. Z.B. ein alleinstehendes \"if (...)\" mit einem \";\"
\"sauber\" abzuschließen...

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

 

[Hartmut Kraus]

Am 24.09.23 um 20:40 schrieb Helmut Schellong:

Am 24.09.2023 um 18:30 schrieb Hartmut Kraus:
Am 23.09.23 um 23:05 schrieb 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.

Das habe ich auch nicht behauptet. S. Kontext.

Kommando, Befehl, Befehlsgewalt, kommandieren, befehligen, befehlen.
|\"Befehl\" (neudeutsch: \"Statement\")|    stimmt nicht.

Schon mal geirrt?

Statement, das: Anweisung, Befehl (für den Computer)

https://www.dwds.de/wb/Statement

Und wenn du jetzt im Dreieck springst, das ändert nichts daran, dass \"Anweisung\", \"Kommando\", \"Befehl\", \"Statement\" in /allen/ Programmiersprachen ein und dasselbe bedeutet. EOD, du Krümelkacker.

--
\"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/25/23 12:30 AM, Helmut Schellong wrote:

Am 24.09.2023 um 21:37 schrieb Helmut Schellong:

==============================================================================================

A preprocessing directive consists of a sequence of preprocessing tokens
that satisfies
the following constraints:
The first token in the sequence is a # preprocessing token that (at the
start of translation
phase 4) is either the first character in the source file
(optionally after white space containing no new-line characters)
or that follows white space containing at least one new-line character.
The last token in the sequence is the first new-line character
that follows the first token in the sequence.
==============================================================================================


Vorstehend wird die Angelegenheit klargestellt.
Viele andere Texte befinden sich (scheinbar) im Widerspruch zum
Vorstehenden.
Texte außerhalb des Standards sind nun mal unverbindlich.

Eine PP-Direktive besteht folglich aus der gesamten PP-Zeile, von # bis
zur NL.
Das war mir nicht klar.
Ich dachte, beispielsweise \'# define\' sei eine PP-Direktive.

Die Direktive ist die ganze Zeile, ggf. mit Fortsetzungszeilen.
In anderem Kontext hast Du das auch schon als Kommando bezeichnet.

> Das ist jedoch nur der Direktiven-Name.

Es ist (hier) ein die erste Präprozessor-Anweisung innerhalb der Direktive.

Obwohl ich hier irrte, bedeutet dies nicht, daß der C-Standard ein
Konglomerat
aus den Sprachen \'Präprozessor\', \'C\' und \'C++\' ist.

.                      Programming languages — C
This document specifies the form and establishes the interpretation of
programs
.                expressed in the programming language C.

Vorstehender Text ist eindeutig.
Es werden keine weiteren Sprachen im C-Standard beschrieben.

Mein ANSI C98 Draft beginnt mit
>>
This document specifies [...] expressed in the programming language C++.
<<

In den Drafts und Standards, die ich kenne, wird der Präprozessor, C und
C++ gemeinsam beschrieben. In einem Quelltext kann zwischen diesen
Sprachen kontrolliert umgeschaltet werden:
# --> C oder C++ nach Präprozessor
extern \"C\" --> C++ nach C

Wenn Du einen C Standard ohne C++ gefunden hast, dann ist das für mich
ein Zeichen von Wildwuchs, zumindest bei C++. Wie soll ein C++ Compiler
auf C umschalten können, ohne daß die Sprache C ausreichend spezifiziert
ist?


Was ich bezüglich des Konglomerats von Sprachen schon lange hätte sagen
sollen:
We agree to disagree.
Das ist nunmal Ansichtssache, egal was die Standards von sich behaupten
oder in sie hineininterpretiert werden kann.

DoDi

 

[Hans-Peter Diettrich]

On 9/24/23 9:03 PM, Sieghard Schicktanz wrote:

Hallo Hans-Peter,

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

[\"mseide-msegui\"]
Ich habe mich selbst auch dafür interessiert, aber ein Blick in den
Quelltext hat bei mir fast Augenkrebs verursacht, domit konnte ich

Naja, besonderen Wert auf eine lesefreundliche Schreibweise für _andere_
als sich selber hat der Entwickler wahrlich nicht gelegt. Man könnte
meinen, seine Tastatur hatte eine defekte Großschreibetaste...
[...]
Aber niemand muß ein bestimmtes System benutzen, und wenn er das doch will,
ihm aber der Stil nicht gefällt, dann kann er den ja mit einem \"Beautifier\"
nach Gusto anpassen - hast Du solche nicht auch schon geschrieben?

Ich habe mir das damals überlegt, bin dann aber davon abgekommen. Es ist
nun mal eine Sysiphus-Arbeit, wenn man zu jeder neuen Version den
Beautifier anpassen und über alle Quelltexte drüberlaufen lassen muß,
und damit den Zusammenhang zwischen der alten Version, eigenen Updates
und der neuen offiziellen Version verliert.

In BASIC war das aufgrund der internen Token-Struktur einfacher. Ich
habe da schon einmal einen Homecomputer gefunden (Laser?), auf dem der
Benutzer ein eigenes Wörterbuch für die Anzeige und Eingabe der
Schlüsselworte erstellen konnte.

DoDi