Wirkungsgrad von 100 m RG213U...

Am 25.09.2023 um 21:35 schrieb 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...

Ich habe für meine C-Bücher vom Verlag Springer-Vieweg mehrere Beautifier getestet
und Testcode in meinen Büchern konkret dargestellt.
Fehlerhafte Umwandlungen, wie Du sie vorstehend schilderst, sind mir gänzlich unbekannt.

Beautifier, die ihren Namen verdienen, parsen C-Quellen und zerlegen sie in Token, die
anschließend anders als zuvor mit sie umgebenden \'White space\' versehen werden.
Da können solche Fehler, wie Du es schilderst, gar nicht vorkommen.
Ein solches Programm darf doch keine Token (;) hinzufügen, die zuvor gar nicht existierten!

https://www.gnu.org/software/indent/manual/indent.pdf


Ich habe soeben .\\indent -orig function.c (Win-.exe) aufgerufen:

===============================================================================================
#if defined(F_memset8) && !defined(DF_memset8) && !defined(memset8)
# define DF_memset8
fSTATIC void *memset8(void *d0, int v0, size_t n0)
{
byte *d, *de;
if (n0) { d=d0;
if (n0>=16) { uint64_t v; size_t n;
n= 8-((uintptr_t)d&7);
if (n<8) { de=d+n; n0-=n;
do *d= (byte)v0; while (++d<de);
}
v=(byte)v0; v|= v<<8; v|= v<<16; v|= v<<32;
de= d+(n0&~(size_t)7);
do *(uint64_t*)d= v; while (d+=8, d<de);
if (n=n0&7, n) { de=d+n;
do *d= (byte)v0; while (++d<de);
}
}
else { de=d+n0;
do *d= (byte)v0; while (++d<de);
}
}
return d0;
}
#endif
===============================================================================================
#if defined(F_memset8) && !defined(DF_memset8) && !defined(memset8)
# define DF_memset8
fSTATIC void *
memset8(void *d0, int v0, size_t n0)
{
byte *d,
*de;
if (n0) {
d = d0;
if (n0 >= 16) {
uint64_t v;
size_t n;
n = 8 - ((uintptr_t) d & 7);
if (n < 8) {
de = d + n;
n0 -= n;
do
*d = (byte) v0;
while (++d < de);
}
v = (byte) v0;
v |= v << 8;
v |= v << 16;
v |= v << 32;
de = d + (n0 & ~(size_t) 7);
do
*(uint64_t *) d = v;
while (d += 8, d < de);
if (n = n0 & 7, n) {
de = d + n;
do
*d = (byte) v0;
while (++d < de);
}
} else {
de = d + n0;
do
*d = (byte) v0;
while (++d < de);
}
}
return d0;
}
#endif
===============================================================================================


--
Mit freundlichen Grüßen
Helmut Schellong
 
Am 23.09.2023 um 13:29 schrieb 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.

Dann hat der Kollege nicht aufgepaßt, Cardinal ist vorzeichenlos mit 32
Bit Breite.

Vielleicht hat der Kollege mit einem Programm zu tun gehabt, wo ein
eigener Typ \"Kardinal\" definiert war mit einer geringeren Bitbreite.
Sowas kann man in Delphi auch machen.

Holger
 
Am 25.09.2023 um 22:59 schrieb 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.

Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar) widersprüchlich sind.
Du wußtest, daß ich Texte innerhalb des C-Standards meine.

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.

|5.1.1.2 Translation phases
|1. Physical source file multibyte characters are mapped, ...
|2. Each instance of a backslash character (\\) immediately followed by a new-line character
| is deleted, splicing physical source lines to form logical source lines
|...
|8. ...

Die Fortsetzungszeilen (per \\NL) werden also ganz früh zu einer Zeile umgeformt.

> In anderem Kontext hast Du das auch schon als Kommando bezeichnet.

Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.

Das ist jedoch nur der Direktiven-Name.

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

Der C-Standard erwähnt konkret Direktiven-Namen:
|When in a group that is skipped (6.10.1), the directive syntax is relaxed to allow any sequence of
|preprocessing tokens to occur between the _directive name_ and the following new-line character.

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++.

https://www.open-std.org/jtc1/sc22/wg14/www/projects.html

Besorge Dir dort mal /richtige/ Drafts:
|ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
|N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x

Programming languages — C
1. Scope
1 This International Standard specifies the form and establishes the interpretation of
programs written in the C programming language.1) It specifies
— the representation of C programs;
— the syntax and constraints of the C language;
— the semantic rules for interpreting C programs;
— the representation of input data to be processed by C programs;
— the representation of output data produced by C programs;
— the restrictions and limits imposed by a conforming implementation of C.

2 This International Standard does not specify
— the mechanism by which C programs are transformed for use by a data-processing system;
— the mechanism by which C programs are invoked for use by a data-processing system;
— the mechanism by which input data are transformed for use by a C program;
— the mechanism by which output data are transformed after being produced by a C program;
— the size or complexity of a program and its data that will exceed the capacity of any
specific data-processing system or the capacity of a particular processor;
— all minimal requirements of a data-processing system that is capable of supporting a
conforming implementation

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?

https://www.open-std.org/jtc1/sc22/wg14/www/projects.html

Du mußt halt die offiziellen Drafts benutzen (zuvor auf einer dänischen Seite: ...dkuug.dk).
Ich schrieb bereits zuvor, daß es C98 nicht gab/gibt.

Du tust aber etwa so, als sei Dein ungültiger Kram das Echte, meine
offiziellen Dokumente jedoch nicht.

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.

Einfach offizielle, gültige Dokumente verwenden.


--
Mit freundlichen Grüßen
Helmut Schellong
 
Am 26.09.2023 um 12:31 schrieb Holger Schieferdecker:
Am 23.09.2023 um 13:29 schrieb 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.

Dann hat der Kollege nicht aufgepaßt, Cardinal ist vorzeichenlos mit 32 Bit Breite.

Vielleicht hat der Kollege mit einem Programm zu tun gehabt, wo ein eigener Typ \"Kardinal\"
definiert war mit einer geringeren Bitbreite. Sowas kann man in Delphi auch machen.

Wer weiß.
Jedenfalls haben später andere Kollegen von mir indirekt dafür gesorgt, daß
der Kollege Tarek entlassen wurde - der war offenbar heftig inkompetent.

Ich selbst hatte da Fujitsu-uC - natürlich in C - programmiert.


--
Mit freundlichen Grüßen
Helmut Schellong
 
Am 25.09.2023 um 22:32 schrieb 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?

Ja, vor kurzem hier: 25.09.2023, 00:30 - kommt eher selten vor.

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. ;)

Wer schon lange Zeit mit Programmiersprachen zu tun hat, weiß, daß die vorstehende Aussage
ungefähr zur Hälfte falsch ist.

Im C-Standard, der etwa 730 Seiten hat, kommt das Wort \'command\' nur 6-mal vor.
\'statement\' kommt jedoch 246-mal vor.
\'command\' kommt im Zusammenhang mit einem externen \'command processor\' vor, einem Shell-Programm.
Bei Programmiersprachen wird das Wort \'statement\' fleißig verwendet, \'command\' praktisch nicht.

\'statement\' bedeutet im Deutschen \'Anweisung\', aber nur im Computerbereich.
Von Lehrern hörte ich stets \'Anweisung\', nie \'Kommando\' oder \'Befehl\'.
\'command\' bedeutet auch \'instruction\', jedoch nicht \'statement\'.
Von Lehrern hörte ich im Zusammenhang mit Assemblern \'Befehl\', wegen \'Instruktion\'.

Ich habe oben durchaus die richtige Trennung vorgetragen.
Kommando und Befehl werden von Anweisung und statement getrennt.
Im Deutschen und im Englischen.


--
Mit freundlichen Grüßen
Helmut Schellong
 
On 9/26/23 2:09 PM, Helmut Schellong wrote:
Am 25.09.2023 um 22:59 schrieb 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.

Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar)
widersprüchlich sind.

Du meinst Passagen im Stadard?

> Du wußtest, daß ich Texte innerhalb des C-Standards meine.

Nein, so konnte ich das nicht verstehen. Für mich ist der C-Standard 1 Text.


Die Fortsetzungszeilen (per \\NL) werden also ganz früh zu einer Zeile
umgeformt.

Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin
sichtbar bleiben.


In anderem Kontext hast Du das auch schon als Kommando bezeichnet.

Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.

Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt
nur den Quelltext um. Als eigenständiges Programm kann er jeden Text
überarbeiten.


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


https://www.open-std.org/jtc1/sc22/wg14/www/projects.html

Besorge Dir dort mal /richtige/ Drafts:
|ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
|N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x

Da scheinen ANSI und ISO getrennte Wege zu gehen?

Wenn ich mich schon mit ungeliebten Sprachen beschäftigen muß, dann
bitte gleich richtig (C++, enthält C) und nicht nur ein Teilchen davon.

DoDi
 
On 9/22/23 1:50 PM, Carla Schneider wrote:

Alles was in Pascal geht, geht auch in C, aber man kann in C Dinge machen die
in Pascal nicht gehen.

In Delphi (OPL) ist ein Garbage-Collektor eingebaut, den es so für C/C++
nicht gibt und (wegen Kompatibilitätsproblemen) nicht geben wird.

DoDi
 
Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich:
On 9/26/23 2:09 PM, Helmut Schellong wrote:
Am 25.09.2023 um 22:59 schrieb 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.

Ich meine andere Texte _innerhalb_ des C-Standards, die (scheinbar) widersprüchlich sind.

Du meinst Passagen im Stadard?

Ja, natürlich.
Ein Bezug auf andere Texte außerhalb des Standards wäre ja Unfug.

Du wußtest, daß ich Texte innerhalb des C-Standards meine.

Nein, so konnte ich das nicht verstehen. Für mich ist der C-Standard 1 Text.

Ein Text kann auch beliebig in Texte (Textteile, Textstellen) aufgeteilt werden.
Prolog, Epilog und Kapitel können auch als verschiedene Texte innerhalb eines Romans gelten.
Den vollen Text ...
Teil oder Ganzes eines Textes ...
Einen Text aus der Bibel ...; Das kann auch nur ein Satz sein.

Die Fortsetzungszeilen (per \\NL) werden also ganz früh zu einer Zeile umgeformt.

Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben.

Für Fortsetzungszeilen gilt das nicht:
|Each instance of a backslash character (\\) immediately followed by a new-line character is
|deleted, splicing physical source lines to form logical source lines.

Vorstehenden Satz hast Du gelöscht.
Die gelöschten Zeichenfolgen \'\\NL\' sind für den Compiler weiterhin _nicht_ sichtbar.

In anderem Kontext hast Du das auch schon als Kommando bezeichnet.

Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.

Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als
eigenständiges Programm kann er jeden Text überarbeiten.

Der Präprozessor ist kein Kommando, sondern nur \'cc\' oder \'clang\' sind hier Kommandos.
Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten.

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


https://www.open-std.org/jtc1/sc22/wg14/www/projects.html

Besorge Dir dort mal /richtige/ Drafts:
|ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
|N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x

Da scheinen ANSI und ISO getrennte Wege zu gehen?

Nein, gar nicht.
ISO und IEC sind internationale Organisationen.
ANSI ist eine US-amerikanische Organisation, die ISO-Standards übernimmt, so wie auch DIN.

Wenn ich mich schon mit ungeliebten Sprachen beschäftigen muß, dann bitte gleich richtig (C++,
enthält C) und nicht nur ein Teilchen davon.

C++ wird von der WG21 bearbeitet, einer anderen Workgroup.

https://www.open-std.org/jtc1/sc22/wg21/docs/standards


--
Mit freundlichen Grüßen
Helmut Schellong
 
On 9/27/23 9:39 AM, Helmut Schellong wrote:
Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich:

Die Fortsetzungszeilen (per \\NL) werden also ganz früh zu einer Zeile
umgeformt.

Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin
sichtbar bleiben.

Für Fortsetzungszeilen gilt das nicht:
|Each instance of a backslash character (\\) immediately followed by a
new-line character is
|deleted, splicing physical source lines to form logical source lines.

Das Entfernen von \\NL ist erst nach Entfernen von // Kommentaren
möglich, und diese Entfernung muß \\NL beibehalten. Mir ist nicht ganz
klar, wie sich dieses Entfernen z.B. auf String-Literale auswirkt, die
sich über mehrere Zeilen erstrecken. Vielleicht gibt es noch mehr
Stellen, an denen Zeilenenden weiterhin bedeutsam sein können.


Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.

Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt
nur den Quelltext um. Als eigenständiges Programm kann er jeden Text
überarbeiten.

Der Präprozessor ist kein Kommando, sondern nur \'cc\' oder \'clang\' sind
hier Kommandos.
Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten.

Das gilt nur für den Präprozessor als Teil eines Compilers, *nicht* für
einen *selbständigen* Präprozessor. Der ursprünglich selbständige
Präprozessor konnte und kann weiterhin zur Bearbeitung beliebiger Texte
verwendet werden. Seitdem hat es aber im C/C++ Parser Änderungen
gegeben, die eine unabhängige Vorbereitung solcher Quellen nicht mehr
zuläßt.

DoDi
 
Am 27.09.2023 um 11:54 schrieb Hans-Peter Diettrich:
On 9/27/23 9:39 AM, Helmut Schellong wrote:
Am 27.09.2023 um 01:39 schrieb Hans-Peter Diettrich:


Die Fortsetzungszeilen (per \\NL) werden also ganz früh zu einer Zeile umgeformt.

Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben.

Für Fortsetzungszeilen gilt das nicht:
|Each instance of a backslash character (\\) immediately followed by a new-line character is
|deleted, splicing physical source lines to form logical source lines.

Das Entfernen von \\NL ist erst nach Entfernen von // Kommentaren möglich, und diese Entfernung muß
\\NL beibehalten. Mir ist nicht ganz klar, wie sich dieses Entfernen z.B. auf String-Literale
auswirkt, die sich über mehrere Zeilen erstrecken. Vielleicht gibt es noch mehr Stellen, an denen
Zeilenenden weiterhin bedeutsam sein können.

Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile geschrieben.
Sondern nur /*...*/.
Noch nie habe ich /*...*/ über Zeilenverlängerungen \\NL hinweg geschrieben.
Das wäre auch nie sinnvoll gewesen.

Zeichenfolgen \'\\NL\' werden in Translation phase 2 gelöscht.
Kommentare werden in Translation phase 3 gelöscht.
Phase 2 hat folglich Vorrang.
Das weiß ich schon lange.
Auch \"...//...\" (\") hat Vorrang durch Maskierung.

Als ich von einer Kommando-Programmiersprache (Shell-Skript) schrieb.

Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als
eigenständiges Programm kann er jeden Text überarbeiten.

Der Präprozessor ist kein Kommando, sondern nur \'cc\' oder \'clang\' sind hier Kommandos.
Der Präprozessor kann nur Texte in gültigem C (eine C-Quelle) bearbeiten.

Das gilt nur für den Präprozessor als Teil eines Compilers, *nicht* für einen *selbständigen*
Präprozessor. Der ursprünglich selbständige Präprozessor konnte und kann weiterhin zur Bearbeitung

Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich unbekannt.
Es sei denn, es handelt sich um Unix-Kommandos wie \'tr\' und ähnlich.

beliebiger Texte verwendet werden. Seitdem hat es aber im C/C++ Parser Änderungen gegeben, die eine
unabhängige Vorbereitung solcher Quellen nicht mehr zuläßt.

Beispielsweise werden Kommentare durch ein Leerzeichen ersetzt.
Damit nicht neue Tokens unkontrolliert entstehen.

#if 0
rreiuegkööekwq ea ä
#endif

\"rreiuegkööekwq ea ä\"
\"rreiuegk\\224\\224ekwq ea \\204\"

Ich hatte in den beiden vorstehenden Fällen schon ERROR erlebt.
Bei alten Compilern, die non-ASCII nirgendwo in der Quelle akzeptierten.


--
Mit freundlichen Grüßen
Helmut Schellong
 
Hallo Helmut,

Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200:

Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile
geschrieben. Sondern nur /*...*/.
Noch nie habe ich /*...*/ über Zeilenverlängerungen \\NL hinweg
geschrieben. Das wäre auch nie sinnvoll gewesen.

Geht aber alles. Du kannst auch beliebige Kommentare in Makro-Defintionen
einbauen, sauber formatiert mit \"\\NL\" (wie Du das schreibst).

....
Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich
unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie \'tr\' und
ähnlich.

Du hast den \"cc\" selber genannt.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
 
Am 27.09.2023 um 21:23 schrieb Sieghard Schicktanz:
Hallo Helmut,

Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200:

Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile
geschrieben. Sondern nur /*...*/.
Noch nie habe ich /*...*/ über Zeilenverlängerungen \\NL hinweg
geschrieben. Das wäre auch nie sinnvoll gewesen.

Geht aber alles. Du kannst auch beliebige Kommentare in Makro-Defintionen
einbauen, sauber formatiert mit \"\\NL\" (wie Du das schreibst).

Vorher:
# define HKL cccccccccccccccc \\
ddd //kkkkkkkkkk \\
eeeeeeeeeeeeeeee

Nachher 1:
# define HKL cccccccccccccccc ddd //kkkkkkkkkk eeeeeeeeeeeeeeee

Nachher 2:
# define HKL cccccccccccccccc ddd

Das ist aber in die Hose gegangen.
Es fehlt nun \'eeeeeeeeeeeeeeee\'.

Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich
unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie \'tr\' und
ähnlich.

Du hast den \"cc\" selber genannt.

Das ist aber kein vom Compiler unabhängig aufrufbarer Präprozessor, sondern
\'cc\' IST der Compiler.

--
Mit freundlichen Grüßen
Helmut Schellong
 
On 2023-09-27, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
> Du hast den \"cc\" selber genannt.

Das ist das Compiler-Frontend, das cpp/cc/... aufruft.

Du meinst \"cpp\".

cu
Michael
--
Some people have no respect of age unless it is bottled.
 
Am 28.09.2023 um 13:45 schrieb Michael Schwingen:
On 2023-09-27, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
Du hast den \"cc\" selber genannt.

Das ist das Compiler-Frontend, das cpp/cc/... aufruft.

Du meinst \"cpp\".

Die Realität ist seit vielen Jahren anders:
----------------------------------------------------------------------------------------------
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/clang
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/cc
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/clang-cpp
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/cpp
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/clang++
-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/c++

142] cc -### /u/bsh/bsh.c
\"/usr/bin/cc\" \"-cc1\" \"bsh.c\" \"-o\" \"/tmp/bsh-2a6c29.o\" \"-x\" \"c\" \"/u/bsh/bsh.c\"
\"/usr/bin/ld\" \"-o\" \"a.out\" \"/usr/lib/crt1.o\" \"/usr/lib/crti.o\" \"/usr/lib/crtbegin.o\"
\"-L/usr/lib\" \"/tmp/bsh-2a6c29.o\" \"-lc\" \"/usr/lib/crtend.o\" \"/usr/lib/crtn.o\"

143] cc -### -S /u/bsh/bsh.c
\"/usr/bin/cc\" \"-cc1\" \"-S\" \"bsh.c\" \"-o\" \"bsh.s\" \"-x\" \"c\" \"/u/bsh/bsh.c\"
----------------------------------------------------------------------------------------------

Oben ist die eine Executable 6-fach verlinkt (Hardlinks).
/usr/bin liegt im PATH.
\'cpp\' bedeutet \'cplusplus\'.
Extern existiert nur der Linker \'ld\'.
Präprozessor und Assembler existieren nicht extern, sondern
nur in der einen großen Executable (95 MB).

Ich schrieb bereits, daß es dem C-Standard egal ist, wie die Sprache C implementiert ist.
Der Standard definiert den gültigen Inhalt einer C-Quelle, bis ins feinste Detail, und
die C-Libraries.
Es dürften auch alle Header-Dateien: z.B. <stdio.h>, in der einen großen Exe enthalten sein.

Die Compiler-Option -### bewirkt einen cold-run, der _alle_ aufgerufenen Kommandos zeigt.



=====================================================================================================
142] cc -### /u/bsh/bsh.c
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
Target: x86_64-unknown-freebsd13.2
Thread model: posix
InstalledDir: /usr/bin
\"/usr/bin/cc\" \"-cc1\" \"-triple\" \"x86_64-unknown-freebsd13.2\" \"-emit-obj\" \"-mrelax-all\"
\"--mrelax-relocations\" \"-disable-free\" \"-clear-ast-before-backend\" \"-disable-llvm-verifier\"
\"-discard-value-names\" \"-main-file-name\" \"bsh.c\" \"-mrelocation-model\" \"static\"
\"-mframe-pointer=all\" \"-ffp-contract=on\" \"-fno-rounding-math\" \"-mconstructor-aliases\"
\"-funwind-tables=2\" \"-target-cpu\" \"x86-64\" \"-tune-cpu\" \"generic\" \"-mllvm\"
\"-treat-scalable-fixed-error-as-warning\" \"-debugger-tuning=gdb\" \"-fcoverage-compilation-dir=/u\"
\"-resource-dir\" \"/usr/lib/clang/14.0.5\" \"-fdebug-compilation-dir=/u\" \"-ferror-limit\" \"19\"
\"-fgnuc-version=4.2.1\" \"-faddrsig\" \"-D__GCC_HAVE_DWARF2_CFI_ASM=1\" \"-o\" \"/tmp/bsh-2a6c29.o\" \"-x\"
\"c\" \"/u/bsh/bsh.c\"
\"/usr/bin/ld\" \"--eh-frame-hdr\" \"-dynamic-linker\" \"/libexec/ld-elf.so.1\" \"--hash-style=both\"
\"--enable-new-dtags\" \"-o\" \"a.out\" \"/usr/lib/crt1.o\" \"/usr/lib/crti.o\" \"/usr/lib/crtbegin.o\"
\"-L/usr/lib\" \"/tmp/bsh-2a6c29.o\" \"-lgcc\" \"--as-needed\" \"-lgcc_s\" \"--no-as-needed\" \"-lc\" \"-lgcc\"
\"--as-needed\" \"-lgcc_s\" \"--no-as-needed\" \"/usr/lib/crtend.o\" \"/usr/lib/crtn.o\"

143] cc -### -S /u/bsh/bsh.c
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
Target: x86_64-unknown-freebsd13.2
Thread model: posix
InstalledDir: /usr/bin
(in-process)
\"/usr/bin/cc\" \"-cc1\" \"-triple\" \"x86_64-unknown-freebsd13.2\" \"-S\" \"-disable-free\"
\"-clear-ast-before-backend\" \"-disable-llvm-verifier\" \"-discard-value-names\" \"-main-file-name\"
\"bsh.c\" \"-mrelocation-model\" \"static\" \"-mframe-pointer=all\" \"-ffp-contract=on\" \"-fno-rounding-math\"
\"-mconstructor-aliases\" \"-funwind-tables=2\" \"-target-cpu\" \"x86-64\" \"-tune-cpu\" \"generic\" \"-mllvm\"
\"-treat-scalable-fixed-error-as-warning\" \"-debugger-tuning=gdb\" \"-fcoverage-compilation-dir=/u\"
\"-resource-dir\" \"/usr/lib/clang/14.0.5\" \"-fdebug-compilation-dir=/u\" \"-ferror-limit\" \"19\"
\"-fgnuc-version=4.2.1\" \"-faddrsig\" \"-D__GCC_HAVE_DWARF2_CFI_ASM=1\" \"-o\" \"bsh.s\" \"-x\" \"c\" \"/u/bsh/bsh.c\"
=====================================================================================================


--
Mit freundlichen Grüßen
Helmut Schellong
 
On 2023-09-28, Helmut Schellong <var@schellong.biz> wrote:
Am 28.09.2023 um 13:45 schrieb Michael Schwingen:
On 2023-09-27, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
Du hast den \"cc\" selber genannt.

Das ist das Compiler-Frontend, das cpp/cc/... aufruft.

Du meinst \"cpp\".

-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/cpp
\'cpp\' bedeutet \'cplusplus\'.

Hier nicht.

lrwxrwxrwx 1 root root 6 Jan 11 2021 /usr/bin/cpp -> cpp-10
lrwxrwxrwx 1 root root 23 Jan 10 2021 /usr/bin/cpp-10 -> x86_64-linux-gnu-cpp-10

$ dpkg -S /usr/bin/cpp-10 /usr/bin/cpp
cpp-10: /usr/bin/cpp-10
cpp: /usr/bin/cpp

Package: cpp-10
Description-en: GNU C preprocessor
A macro processor that is used automatically by the GNU C compiler
to transform programs before actual compilation.
.
This package has been separated from gcc for the benefit of those who
require the preprocessor but not the compiler.

Der GNU c++-Compiler heisst \"c++\", nicht \"cpp\".

cu
Michael
--
Some people have no respect of age unless it is bottled.
 
Holger Schieferdecker schrieb:
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.

Bjarne Stroustrups Ergänzung für C++:
“In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.”

--
mfg Rolf Bombach
 
Helmut Schellong schrieb:
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.

Jou. Und alle drei Jahre einen neuen C++-Standard.
Haste schon C++23/26?

--
mfg Rolf Bombach
 
Hallo Helmut,

Du schriebst am Thu, 28 Sep 2023 08:51:33 +0200:

Am 27.09.2023 um 21:23 schrieb Sieghard Schicktanz:
Hallo Helmut,

Du schriebst am Wed, 27 Sep 2023 16:51:49 +0200:

Ich habe noch nie Zeilenkommentare //... innerhalb einer PP-Zeile
geschrieben. Sondern nur /*...*/.
Noch nie habe ich /*...*/ über Zeilenverlängerungen \\NL hinweg
geschrieben. Das wäre auch nie sinnvoll gewesen.

Geht aber alles. Du kannst auch beliebige Kommentare in
Makro-Defintionen einbauen, sauber formatiert mit \"\\NL\" (wie Du das
schreibst).

Vorher:
# define HKL cccccccccccccccc \\
ddd //kkkkkkkkkk \\
eeeeeeeeeeeeeeee

Nachher 1:
# define HKL cccccccccccccccc ddd //kkkkkkkkkk
eeeeeeeeeeeeeeee

Nachher 2:
# define HKL cccccccccccccccc ddd

Das ist aber in die Hose gegangen.
Es fehlt nun \'eeeeeeeeeeeeeeee\'.

Nee, warum? Der Kommentar hinter \"//\" bis zum Ende der Gesamtzeile fehlt
doch durchaus ordnungsgemäß. Aber was soll Dein \"Nachher 1\" sein? _Das_ ist
eine Zwischenaktion des Präprozessors, die nicht nach außen sichtbar ist.
Ansonsten schaut die Ausgabe des Präprozessors (hier: cpp) so aus:

$ cpp cct.c
# 0 \"cct.c\"
# 0 \"<built-in>\"
# 0 \"<command-line>\"
# 1 \"/usr/include/stdc-predef.h\" 1 3 4
# 0 \"<command-line>\" 2
# 1 \"cct.c\"



Jawoisserdenn? Wo ist denn der Makro-Text geblieben? Da gibt\'s nur leere
Zeilen, wo die Definition gestanden haben könnte, und sonst nischt?
Vielleich hilft ein Makro-Aufruf dahinter... So:

$ cpp cct.c
# 0 \"cct.c\"
# 0 \"<built-in>\"
# 0 \"<command-line>\"
# 1 \"/usr/include/stdc-predef.h\" 1 3 4
# 0 \"<command-line>\" 2
# 1 \"cct.c\"



cccccccccccccccc ddd

Ja, daisserja! Die Zeile mit dem Makro-Text kommt also _nur dann_, wenn das
Makro auch ausgeführt wird und seinen Inhalt in das Ausgabe-File ergießt.

Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich
unbekannt. Es sei denn, es handelt sich um Unix-Kommandos wie \'tr\' und
ähnlich.

Du hast den \"cc\" selber genannt.

Das ist aber kein vom Compiler unabhängig aufrufbarer Präprozessor,
sondern \'cc\' IST der Compiler.

Nein, das ist auch nicht der Compiler, das ist der \"Compiler Controller\".
Aber Du hast insofern recht, als der Präprozessor den Namen \"cpp\" hat, so
wie ich ihn oben auch aufgerufen habe. Ein \"cc -E\" wäre auch gegangen, dann
wird gleich nach dem Präprozessor-Aufruf aufgehört und dessen Ausgabe
landet auf dem Bildschirm.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
 
Am 28.09.2023 um 20:49 schrieb Rolf Bombach:
Helmut Schellong schrieb:
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.

Jou. Und alle drei Jahre einen neuen C++-Standard.
Haste schon C++23/26?

Ich habe den Draft C++20, und ein sehr dickes Buch von Stroustrup.

Major-C-Standards gab es bisher nur: C89:C90, C99, C11.
C23 wird höchstwahrscheinlich 2023 kommen.
C-Standards gibt es folglich nur alle 10..12 Jahre.

https://magentacloud.de/s/Ei3bPnq3BnF9dpN

Vorstehend das Deckblatt eines gekauften C-Standards C11.
Die haben meinen Namen mit Lizenz auf jede Seite unten gedruckt.


--
Mit freundlichen Grüßen
Helmut Schellong
 
Am 28.09.2023 um 19:07 schrieb Michael Schwingen:
On 2023-09-28, Helmut Schellong <var@schellong.biz> wrote:
Am 28.09.2023 um 13:45 schrieb Michael Schwingen:
On 2023-09-27, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
Du hast den \"cc\" selber genannt.

Das ist das Compiler-Frontend, das cpp/cc/... aufruft.

Du meinst \"cpp\".

-r-xr-xr-x 6 root wheel 95122720 Apr 7 06:25 /usr/bin/cpp
\'cpp\' bedeutet \'cplusplus\'.

Hier nicht.

lrwxrwxrwx 1 root root 6 Jan 11 2021 /usr/bin/cpp -> cpp-10
lrwxrwxrwx 1 root root 23 Jan 10 2021 /usr/bin/cpp-10 -> x86_64-linux-gnu-cpp-10

$ dpkg -S /usr/bin/cpp-10 /usr/bin/cpp
cpp-10: /usr/bin/cpp-10
cpp: /usr/bin/cpp

Package: cpp-10
Description-en: GNU C preprocessor
A macro processor that is used automatically by the GNU C compiler
to transform programs before actual compilation.
.
This package has been separated from gcc for the benefit of those who
require the preprocessor but not the compiler.

Der GNU c++-Compiler heisst \"c++\", nicht \"cpp\".

Ich habe unter FreeBSD (clang) auch den gcc12 als PKG installiert.
Der hat separat \'/usr/local/bin/cpp\' (Preprocessor).
/usr/bin/cpp ist der offizielle System-Compiler clang-c++.


--
Mit freundlichen Grüßen
Helmut Schellong
 

Welcome to EDABoard.com

Sponsor

Back
Top