Wirkungsgrad von 100 m RG213U...

[Helmut Schellong]

Am 28.09.2023 um 20:55 schrieb Sieghard Schicktanz:

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.

Vorher:
# define HKL ccccc \\
ddd //kkkkk \\
eeeee

Nachher 1:
# define HKL ccccc ddd //kkkkk eeeee

Nachher 2:
# define HKL ccccc ddd

\'Nachher 1\' ist der Zustand nach translation phase 2: Löschen von \\NL.
Dadurch rutscht eeeee unbeabsichtigt in den Kommentar hinein und verschwindet in phase 3.
Zeilenkommentare funktionieren folglich nicht innerhalb von Zeilenverlängerungen.

Das ist doch der geltende Kontext.
Habe ich in vorhergehenden Postings erklärt.

[...]

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

Du konterkarierst durch Deine Argumentation:

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.

Aber Du hast insofern recht, als der Präprozessor den Namen \"cpp\" hat, so
wie ich ihn oben auch aufgerufen habe.

Der cpp interessiert mich einfach gar nicht.
Der Compiler (inklusive PP) wird _grundsätzlich_ über sein Frontend aufgerufen.
G R U N D S Ä T Z L I C H !!!
Ich werde niemals einen externen PP verwenden.
Ich wüßte gar nicht, warum überhaupt!
Ich habe die man-page zu \'cpp\' gelesen und lasse den externen cpp fallen
wie eine heiße Kartoffel!
Der paßt ja gar nicht richtig! Dessen Verwendung ist risikoreich!
\'cc -E\' ist der einzig richtige Weg.

Ein \"cc -E\" wäre auch gegangen, dann
wird gleich nach dem Präprozessor-Aufruf aufgehört und dessen Ausgabe
landet auf dem Bildschirm.

Kenne ich seit den 1980ern.
Die 5 verschieden umfangreichen Aufgaben eines C-Compilers
habe ich in meinen C-Büchern erklärt.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

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

Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir gänzlich
unbekannt.

Na dann Tschüss!

DoDi

 

[Volker Bartheld]

On Thu, 2023-09-28 at 20:49 +0200, Rolf Bombach wrote:

Helmut Schellong schrieb:
Es gibt keinen C/C++-Standard!
C und C++ haben jeweils einen eigenen ISO-Standard.
u. Und alle drei Jahre einen neuen C++-Standard.
Haste schon C++23/26?

Ist das so wie bei MS, daß man da ständig (zwangs)updaten muß, oder darf man
noch eine Weile C++ 20 weiterprogrammieren?

SCNR,
Volker

 

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Thu, 28 Sep 2023 23:57:51 +0200:

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.

Vorher:
# define HKL ccccc \\
ddd //kkkkk \\
eeeee

Nachher 1:
# define HKL ccccc ddd //kkkkk eeeee

Nachher 2:
# define HKL ccccc ddd

\'Nachher 1\' ist der Zustand nach translation phase 2: Löschen von \\NL.

Den Zustand gibt es nur innerhalb des Präprozessors als Zwischenschritt zur
Vorbereitung der Verarbeitung, und in dem Fall sogar noch vor der
_Definition_ des Makros.

> Dadurch rutscht eeeee unbeabsichtigt in den Kommentar hinein und

Nein, tut er nicht - dieser Teil _war_ schon _von Anfang an_ \"im
Kommentar\", bzw. ein Teil davon. Die Sequenz \"\\NL\" (ich bleib\' mal bei
dieser Schreibweise) ist _nicht_ Teil des Programmtextes. Folglich ist die
gesamte Makro-Definition genau _eine_ Zeile, wie das ja auch verlangt ist.

verschwindet in phase 3. Zeilenkommentare funktionieren folglich nicht
innerhalb von Zeilenverlängerungen.

Nein, da \"verschwidet\" nichts.

Das ist doch der geltende Kontext.
Habe ich in vorhergehenden Postings erklärt.

Ja, falsch.

[...]
Du konterkarierst durch Deine Argumentation:
Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir
gänzlich unbekannt. Es sei denn, es handelt sich um Unix-Kommandos
....
Aber Du hast insofern recht, als der Präprozessor den Namen \"cpp\" hat,
so wie ich ihn oben auch aufgerufen habe.

Eigentlich nicht - der \"cpp\" _ist_ e\"in vom Compiler unabhängig aufrufbarer
Präprozessor\". Na schön, bei Dir könnte ich mir schon vorstellen, daß der
Dir bis dato \"gänzlich unbekannt\" war...

Der cpp interessiert mich einfach gar nicht.
Der Compiler (inklusive PP) wird _grundsätzlich_ über sein Frontend
aufgerufen. G R U N D S Ä T Z L I C H !!!

Kannsr Du so halten, und das ist im Normalfall auch durchaus sinnvoll, weil
sich dann der Compiler-Controller (Steuerprogramm für die Kompilation) um
alles für die Programmerstellung nötige kümmert.

Ich werde niemals einen externen PP verwenden.
Ich wüßte gar nicht, warum überhaupt!

Es verlangt ja auch niemand von Dir. Aber manchmal ist es halt _dich_
nützlich, das Ergebnis dess Präprozessor zu sehen, z.B. wenn man fremde
Makros benutzt (was durchaus vorkommt...) und sich nicht sicher ist, ob die
im \"#include\"-Wust auch richtig umgesetzt werden, insbesondere wenn da
viele symbolesteuerte bedingte Makro-Expansionen drinstecken.

Ich habe die man-page zu \'cpp\' gelesen und lasse den externen cpp fallen
wie eine heiße Kartoffel!
Der paßt ja gar nicht richtig! Dessen Verwendung ist risikoreich!
\'cc -E\' ist der einzig richtige Weg.

Das ist die identische Funktion, halt indirekt über das Steuerprogramm.

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

 

[Helmut Schellong]

Am 29.09.2023 um 14:52 schrieb Volker Bartheld:

On Thu, 2023-09-28 at 20:49 +0200, Rolf Bombach wrote:
Helmut Schellong schrieb:
Es gibt keinen C/C++-Standard!
C und C++ haben jeweils einen eigenen ISO-Standard.
u. Und alle drei Jahre einen neuen C++-Standard.
Haste schon C++23/26?

Ist das so wie bei MS, daß man da ständig (zwangs)updaten muß, oder darf man
noch eine Weile C++ 20 weiterprogrammieren?

Nein, Du kannst den C-Standard und auch den C++-Standard komplett ignorieren
und einen Compiler Deiner Wahl in beliebiger Weise verwenden.
Bis zu Deinem Lebensende.

Es kann natürlich sein, daß ein Arbeitgeber bestimmte Verhaltensweisen vom Programmierer verlangt.
Kunden eines Arbeitgebers können auch bestimmte Vorgänge bei diesem Arbeitgeber verlangen.
Beispielsweise kann verlangt werden, daß mindestens der Standard C99 als umfassende
Arbeitsbasis verwendet wird, und daß bestimmte Testverfahren verwendet werden.

Ich halte von allem diesem eigentlich nichts.
Programmierer sollen einfach talentiert, bestens geeignet und angemessen entlohnt sein.
Davon hängt alles ab.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 29.09.2023 um 20:17 schrieb Sieghard Schicktanz:

Hallo Helmut,

Du schriebst am Thu, 28 Sep 2023 23:57:51 +0200:

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.

Vorher:
# define HKL ccccc \\
ddd //kkkkk \\
eeeee

Nachher 1:
# define HKL ccccc ddd //kkkkk eeeee

Nachher 2:
# define HKL ccccc ddd

\'Nachher 1\' ist der Zustand nach translation phase 2: Löschen von \\NL.

Den Zustand gibt es nur innerhalb des Präprozessors als Zwischenschritt zur
Vorbereitung der Verarbeitung, und in dem Fall sogar noch vor der
_Definition_ des Makros.

Es gibt 8 translation phases, 7 davon sind nach Deinem Gusto Zwischenschritte.
Der Standard definiert alle diese Phasen - ganz normal.

Dadurch rutscht eeeee unbeabsichtigt in den Kommentar hinein und

Nein, tut er nicht - dieser Teil _war_ schon _von Anfang an_ \"im
Kommentar\", bzw. ein Teil davon. Die Sequenz \"\\NL\" (ich bleib\' mal bei
dieser Schreibweise) ist _nicht_ Teil des Programmtextes. Folglich ist die
gesamte Makro-Definition genau _eine_ Zeile, wie das ja auch verlangt ist.

Es kommt darauf an, von welcher Warte aus die Betrachtung erfolgt.
Der Standard definiert steif nacheinander.

6.4.9 Comments
1 Except within a character constant, a string literal, or a comment, the characters /*
introduce a comment.
The contents of such a comment are examined only to identify multibyte characters and
to find the characters */ that terminate it.

2 Except within a character constant, a string literal, or a comment, the characters //
introduce a comment that includes all multibyte characters up to, but not including,
the next new-line character.
The contents of such a comment are examined only to identify multibyte characters
and to find the terminating new-line character.

Ein NL gehört übrigens _nicht_ zum Zeilenkommentar.
Ich meine, das hat hier jemand mal gegenteilig erzählt.

Die Definitionen der Kommentare enthalten keinerlei Hinweise auf eine Betrachtungsebene.
Bezug ist folglich die sichtbare C-Quelle (read-only).

EXAMPLE
//\\
i(); // part of a two-line comment
/\\
/ j(); // part of a two-line comment

Der Standard bezieht seine Definitionen offenbar einerseits auf die sichtbare
C-Quelle, andererseits auf zeitlich spätere Zustände durch den PP.
Die translation phases 2 und 3 werden /blind/ und unabhängig verarbeitet.
In Phase 2 existieren folglich gar keine Kommentare.
Phase 2 generiert potentiell Kommentare, ohne dies zu wissen [1].
Phase 3 sucht danach nach Kommentaren, um sie alle durch ein Leerzeichen zu ersetzen.
[1] Deshalb verhalte ich mich bei Zeilenverlängerungen mit Kommentaren wie zuvor beschrieben.
Wie unschwer zu sehen, sind verteilte Kommentare dort Unfug.

verschwindet in phase 3. Zeilenkommentare funktionieren folglich nicht
innerhalb von Zeilenverlängerungen.

Nein, da \"verschwidet\" nichts.

Kommentare werden gelöscht.
Ich meine, das kann als ein Verschwinden bezeichnet werden.

Das ist doch der geltende Kontext.
Habe ich in vorhergehenden Postings erklärt.

Ja, falsch.

Sieht nicht danach aus.

[...]
Du konterkarierst durch Deine Argumentation:
Ein vom Compiler unabhängig aufrufbarer Präprozessor ist mir
gänzlich unbekannt. Es sei denn, es handelt sich um Unix-Kommandos
...
Aber Du hast insofern recht, als der Präprozessor den Namen \"cpp\" hat,
so wie ich ihn oben auch aufgerufen habe.

Eigentlich nicht - der \"cpp\" _ist_ e\"in vom Compiler unabhängig aufrufbarer
Präprozessor\". Na schön, bei Dir könnte ich mir schon vorstellen, daß der
Dir bis dato \"gänzlich unbekannt\" war...

Ich habe doch berichtet, daß ich gcc12 habe, und daß mit dem ein externer /usr/local/bin/cpp kam.
Externe cpp hatte ich schon in den 1980ern gesehen.
Allerdings ohne eigene man-Page, sondern in /privaten/ Compiler-Verzeichnissen.
Ich weiß nicht, was ich mit einem ausgegliederten cpp mit man-Page anfangen soll,
wo ich doch stets einen genau passenden PP in jedem cc habe.

Der cpp interessiert mich einfach gar nicht.
Der Compiler (inklusive PP) wird _grundsätzlich_ über sein Frontend
aufgerufen. G R U N D S Ä T Z L I C H !!!

Kannsr Du so halten, und das ist im Normalfall auch durchaus sinnvoll, weil
sich dann der Compiler-Controller (Steuerprogramm für die Kompilation) um
alles für die Programmerstellung nötige kümmert.

Ja, das weiß ich seit bald 40 Jahren.
Insbesondere muß ich dann keine 7 Zeilen langen Listen aus Argumenten für den Compiler handhaben.

Ich werde niemals einen externen PP verwenden.
Ich wüßte gar nicht, warum überhaupt!

Es verlangt ja auch niemand von Dir. Aber manchmal ist es halt _dich_
nützlich, das Ergebnis dess Präprozessor zu sehen, z.B. wenn man fremde
Makros benutzt (was durchaus vorkommt...) und sich nicht sicher ist, ob die
im \"#include\"-Wust auch richtig umgesetzt werden, insbesondere wenn da
viele symbolesteuerte bedingte Makro-Expansionen drinstecken.

Dann verwende ich \'cc -E\'.
Ich habe schon vor Jahrzehnten Compiler benutzt, die PP-Ausgaben
in Dateien mit Endung .i geschrieben hatten.

Ich habe die man-page zu \'cpp\' gelesen und lasse den externen cpp fallen
wie eine heiße Kartoffel!
Der paßt ja gar nicht richtig! Dessen Verwendung ist risikoreich!
\'cc -E\' ist der einzig richtige Weg.

Das ist die identische Funktion, halt indirekt über das Steuerprogramm.

Nein, ist es nicht.
Lies die man-Page eines externen cpp.
Ein externer cpp kann beliebig unpassend zum internen System-Compiler-cpp sein.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 10/2/23 2:05 AM, Helmut Schellong wrote:

Am 29.09.2023 um 20:17 schrieb Sieghard Schicktanz:

6.4.9 Comments
1 Except within a character constant, a string literal, or a comment,
the characters /*
  introduce a comment.
  The contents of such a comment are examined only to identify
multibyte characters and
  to find the characters */ that terminate it.

2 Except within a character constant, a string literal, or a comment,
the characters //
  introduce a comment that includes all multibyte characters up to, but
not including,
  the next new-line character.
  The contents of such a comment are examined only to identify
multibyte characters
  and to find the terminating new-line character.

Ein NL gehört übrigens _nicht_ zum Zeilenkommentar.
Ich meine, das hat hier jemand mal gegenteilig erzählt.

Von einem \\NL bleibt aber nur NL übrig, nicht das Fortsetzungszeichen
innerhalb einer Makro-Definition.

Die Definitionen der Kommentare enthalten keinerlei Hinweise auf eine
Betrachtungsebene.
Bezug ist folglich die sichtbare C-Quelle (read-only).

\"Read only\" bedeutet garnichts wenn der Quelltext vom Präprozessor
geändert wird.

EXAMPLE
//\\
i();             // part of a two-line comment
/\\
/ j();           // part of a two-line comment

Beides ist fehlerhaft, was ein guter Compiler sogar meldet!

Bitte zeige einen fehlerfrei compilierbaren Quelltext.

Lies die man-Page eines externen cpp.
Ein externer cpp kann beliebig unpassend zum internen
System-Compiler-cpp sein.

Und wieso gibt es dann eine man page zum cpp?
Richtig, weil er völlig unabhängig von einem Compiler für beliebige
Texte verwendet werden kann. Früher ging das sogar für C Quelltexte,
aber das war wohl noch vor Deiner Zeit ;-)

DoDi

 

[Helmut Schellong]

Am 03.10.2023 um 14:55 schrieb Hans-Peter Diettrich:

On 10/2/23 2:05 AM, Helmut Schellong wrote:
Am 29.09.2023 um 20:17 schrieb Sieghard Schicktanz:

6.4.9 Comments
1 Except within a character constant, a string literal, or a comment, the characters /*
   introduce a comment.
   The contents of such a comment are examined only to identify multibyte characters and
   to find the characters */ that terminate it.

2 Except within a character constant, a string literal, or a comment, the characters //
   introduce a comment that includes all multibyte characters up to, but not including,
   the next new-line character.
   The contents of such a comment are examined only to identify multibyte characters
   and to find the terminating new-line character.

Ein NL gehört übrigens _nicht_ zum Zeilenkommentar.
Ich meine, das hat hier jemand mal gegenteilig erzählt.

Von einem \\NL bleibt aber nur NL übrig, nicht das Fortsetzungszeichen innerhalb einer
Makro-Definition.

Das ist irrelevant, weil in translation phase 2 die Zeichenfolgen \\NL _blind_
und _vor_ phase 3 (Kommentare) gelöscht werden.

Ich beziehe mich oben nur auf Absatz 2 aus dem Standard-Draft: Zeilenkommentar.
Also auch auf Kommentare außerhalb von Zeilenverlängerungen und außerhalb von PP-Texten.

In meinem bish-Interpreter habe ich ebenfalls Zeilenkommentare implementiert:
echo kkk #kommentar
echo sss
\'NL\' und \';\' sind in der \'bish\' Kommando-Ende-Markierungen.
NL wird vom Kommentar stehen gelassen, so daß \'echo kkk\' durch NL ausgeführt wird.

Die Definitionen der Kommentare enthalten keinerlei Hinweise auf eine Betrachtungsebene.
Bezug ist folglich die sichtbare C-Quelle (read-only).

\"Read only\" bedeutet garnichts wenn der Quelltext vom Präprozessor geändert wird.

\"Bezug ist folglich die sichtbare C-Quelle (read-only).\"
Vorstehender Satz bleibt unverändert bestehen.

Der Quelltext wird durch _gar nichts_ geändert, nicht mal die Metadaten der Datei.
Die Quelle wird strikt open(read-only) behandelt.
Entstehende Translations-Dateien werden in /tmp/... (Unix) gespeichert.

Der User sieht ja nur seine Quellen.
Folglich muß ein Standard seine Definitionen darauf beziehen.

|A C program need not all be translated at the same time.
|The text of the program is kept in units called source files, (or preprocessing files)
|in this document.
|A source file together with all the headers and source files included via the
|preprocessing directive #include is known as a preprocessing translation unit.
|After preprocessing, a preprocessing translation unit is called a translation unit.

Stefan Ram hatte das bereits gepostet, wenn ich nicht irre.
1) source files == preprocessing files (read-only)
2) preprocessing translation unit
3) translation unit

EXAMPLE
//\\
i();             // part of a two-line comment
/\\
/ j();           // part of a two-line comment

Beides ist fehlerhaft, was ein guter Compiler sogar meldet!

Nein, alles das ist korrektes C.
Andernfalls hätte der Standard es als fehlerhaft gekennzeichnet - hat er aber nicht.
Der Standard hat das als unausgesprochene Warnung in sein EXAMPLE aufgenommen.

> Bitte zeige einen fehlerfrei compilierbaren Quelltext.

\"a//b\" // four-character string literal
#include \"//e\" // undefined behavior
// */ // comment, not syntax error
f = g/**//h; // equivalent to f = g / h;
//\\
i(); // part of a two-line comment
/\\
/ j(); // part of a two-line comment
#define glue(x,y) x##y
glue(/,/) k(); // syntax error, not comment
/*//*/ l(); // equivalent to l();
m = n//**/o
+ p; // equivalent to m = n + p;

Vorstehend ist alles, wo nicht steht: undefined behavior, syntax error,
fehlerfrei kompilierbar.
Ein \'warning\' ist etwas anderes als ein \'error\'!

Allerdings würde ich niemals selbst irgendetwas von den Beispielen oben programmieren.
Mit Ausnahme der ersten Zeile.
Ich programmiere nämlich professionell, und nicht wie ein albernes Spielkind.

27.09.2023, 16:51 :
|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.

Das mache ich pauschal so wie vorstehend, um niemals in eine Bredouille zu geraten.

Lies die man-Page eines externen cpp.
Ein externer cpp kann beliebig unpassend zum internen System-Compiler-cpp sein.

Und wieso gibt es dann eine man page zum cpp?

Um darin zu warnen, daß dieser cpp beliebig unpassend zum internen System-Compiler-cpp sein kann.

Richtig, weil er völlig unabhängig von einem Compiler für beliebige Texte verwendet werden kann.
Früher ging das sogar für C Quelltexte, aber das war wohl noch vor Deiner Zeit ;-)

Ich befasse und befaßte mich halt nicht mit solch einem Scheiß, wo man
die Kompatibilität selbst herstellen muß.
Beim cc-internen PP muß man das nicht - ergo...


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 10/3/23 6:50 PM, Helmut Schellong wrote:

Am 03.10.2023 um 14:55 schrieb Hans-Peter Diettrich:

Ein \'warning\' ist etwas anderes als ein \'error\'!

Dann sind unsere Compiler anscheinend unterschiedlicher Ansicht.
Jetzt sagen die auch schon \"we agree to disagree\" :-(

Und wieso gibt es dann eine man page zum cpp?

Um darin zu warnen, daß dieser cpp beliebig unpassend zum internen
System-Compiler-cpp sein kann.

Richtig, weil er völlig unabhängig von einem Compiler für beliebige
Texte verwendet werden kann. Früher ging das sogar für C Quelltexte,
aber das war wohl noch vor Deiner Zeit ;-)

Ich befasse und befaßte mich halt nicht mit solch einem Scheiß, wo man
die Kompatibilität selbst herstellen muß.

Welche Kompatibilität? Probleme entstehen nur in Verbindung mit dem
C/C++ Standard, der eine Scheiß Integration eines guten Tools
vorgeschrieben hat, so daß dessen unabhängige Benutzung plötzlich nicht
mehr möglich war - aber eben nur für C/C++ Programmierer. Alle anderen
Benutzer sind von dieser Verirrung nicht betroffen.

Es hat Microsoft übrigens auch einige Zeit gekostet, bis ihr MSVC
Compiler auf den neuen Standard umgestellt war, und sie ihre Windows
Header angepasst hatten. Daran sieht man, was für Inkompatibilitäten mit
vorhergehenden Versionen so eine unbedachte Änderung eines Standards mit
sich bringen kann :-(

DoDi

 

[Hergen Lehmann]

Am 04.10.23 um 10:52 schrieb Hans-Peter Diettrich:

Es hat Microsoft übrigens auch einige Zeit gekostet, bis ihr MSVC
Compiler auf den neuen Standard umgestellt war, und sie ihre Windows
Header angepasst hatten.

Es hat Microsoft vor allem viele Jahre gekostet, sich überhaupt erst mal
irgend einem Standard anzunähern. Es ist in den letzten paar
MSVC-Versionen stetig besser geworden, aber ganz ohne \"#ifdef _MSC_VER\"
kommt man in der Cross-Platform-Entwicklung immer noch nicht aus...

Daran sieht man, was für Inkompatibilitäten mit
vorhergehenden Versionen so eine unbedachte Änderung eines Standards mit
sich bringen kann :-(

Nein, daran sieht man, was für Ärger man sich einhandelt, wenn man den
Standardisierungsprozess jahrzehntelang komplett ignoriert und eigene
Wege geht.

Bei \"sauberem\" C/C++-Code muss man nach einem Wechsel des Sprachstandard
zwar hier und da mal Kleinigkeiten nachbessern, aber in der Regel werden
veraltete Sprachelemente erst mal als \"deprecated\" markiert (=>Warning),
bevor sie Jahre später ganz entfallen, so das man für die Migration
reichlich Zeit hat.

 

[Helmut Schellong]

Am 04.10.2023 um 10:52 schrieb Hans-Peter Diettrich:

On 10/3/23 6:50 PM, Helmut Schellong wrote:
Am 03.10.2023 um 14:55 schrieb Hans-Peter Diettrich:

Ein \'warning\' ist etwas anderes als ein \'error\'!

Dann sind unsere Compiler anscheinend unterschiedlicher Ansicht.
Jetzt sagen die auch schon \"we agree to disagree\" :-(

Die Aufrufe der Compiler lauten für nachfolgende Tests:
clang -fsyntax-only bsh.c
gcc12 -fsyntax-only -funsigned-char bsh.c

EXAMPLE
//\\
i(); // part of a two-line comment

Vorstehendes kommentiert gcc12 gar nicht.
clang gibt eine Warnung: \'two-line // comment\', also
das, was vorstehend der Standard mitteilt.

EXAMPLE
/\\
/ j(); // part of a two-line comment

Hier geben beide Compiler einen Error (/): \'expression expected\'.
clang gibt auch für die zweite Zeile diesen Error (/).

|A conforming implementation shall produce at least one diagnostic message
|(identified in an implementation-defined manner)
|if a preprocessing translation unit or translation unit contains a violation of any
|syntax rule or constraint, even if the behavior is also explicitly specified
|as undefined or implementation-defined.
|Diagnostic messages need not be produced in other circumstances.9)
|9)
|An implementation is encouraged to identify the nature of, and where possible localize,
|each violation.
|Of course, an implementation is free to produce any number of diagnostic messages,
|often referred to as warnings, as long as a valid program is still correctly translated.
|It can also successfully translate an invalid program.
|Annex I lists a few of the more common warnings.

Der Standard läßt vorstehend einer Implementation eines C-Compilers große Freiheiten.
Insbesondere kann ein Compiler vor und/oder nach den 8 translation phases prüfen.
Siehe auch [1].

Und wieso gibt es dann eine man page zum cpp?

Um darin zu warnen, daß dieser cpp beliebig unpassend zum internen System-Compiler-cpp sein kann.

Richtig, weil er völlig unabhängig von einem Compiler für beliebige Texte verwendet werden kann.
Früher ging das sogar für C Quelltexte, aber das war wohl noch vor Deiner Zeit ;-)

Ich befasse und befaßte mich halt nicht mit solch einem Scheiß, wo man
die Kompatibilität selbst herstellen muß.

Welche Kompatibilität?

Steht in der man-Page des cpp-Kommandos.
Schrieb ich schon vor eine Reihe von Postings (/usr/local/bin/cpp [gcc12]).

Probleme entstehen nur in Verbindung mit dem C/C++ Standard, der eine Scheiß
Integration eines guten Tools vorgeschrieben hat, so daß dessen unabhängige Benutzung plötzlich
nicht mehr möglich war - aber eben nur für C/C++ Programmierer. Alle anderen Benutzer sind von
dieser Verirrung nicht betroffen.

Der C-Standard hat mit diesem externen cpp gar nichts zu tun.
Das ist /für ihn/ irgendein unbekanntes Kommando unter irgendeinem unbekannten BS.


[1]
=================================================================================================================
clang
------------
../mod/function.c:2046:23: warning: misleading indentation; statement is not part of the previous
\'if\' [-Wmisleading-indentation]
goto SUB19u;
^
../mod/function.c:2045:4: note: previous statement is here
if (u< 900) goto SUB18u;
^
../mod/function.c:2068:23: warning: misleading indentation; statement is not part of the previous
\'if\' [-Wmisleading-indentation]
goto SUB09u;
^
../mod/function.c:2067:4: note: previous statement is here
if (u< 90) goto SUB08u;
^
bsh.c:1611:38: warning: misleading indentation; statement is not part of the previous \'if\'
[-Wmisleading-indentation]
G.cap.a0=spt; ++a,--C;
^
bsh.c:1610:8: note: previous statement is here
if (cp!=NULL) Y=3, CatSn(sizeof(spt),spt,cp,NULL),
^
bsh.c:4252:26: warning: variable \'bmode\' set but not used [-Wunused-but-set-variable]
register int fdf, om, bmode=0;
^
bsh.c:7609:22: warning: misleading indentation; statement is not part of the previous \'if\'
[-Wmisleading-indentation]
return mbltoa((byte*)A, s.base?s.base:dkkBase, v.i);
^
bsh.c:7608:8: note: previous statement is here
if (v.fi==2) return aldtoa((byte*)A, v.f);
^
33 warnings generated.


gcc12
------------
bsh.c:161:3: error: #error \"Option -funsigned-char (o.vglb.) fehlt!\"
161 | # error \"Option -funsigned-char (o.vglb.) fehlt!\"
| ^~~~~
In file included from bsh.c:1020:
mod/function.c:38:3: error: #error \"Option -funsigned-char (o.vglb.) fehlt!\"
38 | # error \"Option -funsigned-char (o.vglb.) fehlt!\"
| ^~~~~
In file included from bsh.c:1042:
mod/autor.c:13:3: error: #error \"Option -funsigned-char (o.vglb.) fehlt!\"
13 | # error \"Option -funsigned-char (o.vglb.) fehlt!\"
| ^~~~~
=================================================================================================================


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Helmut Schellong schrieb:

> C ist eine Touring-vollständige Programmiersprache 3GL.

In der Schweiz gibt es sogar einen Touring-Club.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 05.10.2023 um 21:10 schrieb Rolf Bombach:

Helmut Schellong schrieb:

C ist eine Touring-vollständige Programmiersprache 3GL.

In der Schweiz gibt es sogar einen Touring-Club.

Nur, was versteht der Club unter Touring-vollständig?

Der Typ heißt Alan Turing.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Andreas Bockelmann]

Rolf Bombach schrieb:

Helmut Schellong schrieb:

C ist eine Touring-vollständige Programmiersprache 3GL.

In der Schweiz gibt es sogar einen Touring-Club.

Das Jura ist viel kleiner als die Alpenregion. Dennoch gibt es weltweit mehr
Juristen als Alpinisten.

--
Mit freundlichen Grüßen
Andreas Bockelmann

 

[Rolf Bombach]

Christoph Müller schrieb:

Am 18.09.2023 um 23:43 schrieb Carla Schneider:

Der Vorteil der hoeheren Programmiersprachen ist
dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.

Habe ein paar Programme in VB6 (Visual Basic) geschrieben. Die Original CDs sind verschollen. Wie kriegt man nun die Programme mit möglichst wenig Aufwand in gängigere Hochsprachen? Auf Win10 kriege
ich sie jedenfalls nur teilweise zum Laufen. Deshalb steht der alte Computer noch immer in meinem Büro.

VB6 installiert sich problemarm unter Win10 und Win11, jedenfalls besser
als unter Win7. Die \"alten\" Programme sollten eigentlich laufen, ich
hab da noch einige und sehe keine Probleme.
Ich halte es allerdings eh für risky, auf so proprietären Sprachen
was geplant langlebiges zu entwickeln. VisualStudio ist ja ganz
nett, aber das Zeuch wird dermassen schnell umgestaltet, dass
man da nicht vernünftig was langlebiges planen kann. Dazu
kommt genereller bloat.

--
mfg Rolf Bombach

 

[Christoph Müller]

Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

Christoph Müller schrieb:
Am 18.09.2023 um 23:43 schrieb Carla Schneider:

Der Vorteil der hoeheren Programmiersprachen ist dass man die
Programme beim Wechsel auf andere Hardware weiter verwenden
kann.

Habe ein paar Programme in VB6 (Visual Basic) geschrieben. Die
Original CDs sind verschollen. Wie kriegt man nun die Programme mit
möglichst wenig Aufwand in gängigere Hochsprachen? Auf Win10
kriege ich sie jedenfalls nur teilweise zum Laufen. Deshalb steht
der alte Computer noch immer in meinem Büro.

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

jedenfalls besser als unter Win7. Die \"alten\" Programme sollten
eigentlich laufen, ich hab da noch einige und sehe keine Probleme.

Laufen alleine reicht nicht. In einem Programm gibt es einen Bereich,
der ganz bewusst zu editieren ist. Dort kommen bisher unbekannte
physikalische Erkenntnisse und Bewertungen für konkrete
Aufgabenstellungen rein. Also brauche ich auch einen Editor dazu. Auf
Maschinenebene mag ich nicht programmieren. Ich bevorzuge Komfortableres.

Ich halte es allerdings eh für risky, auf so proprietären Sprachen
was geplant langlebiges zu entwickeln.

Das hättest du mir in den 90er Jahren sagen müssen. Wenn ich mich recht
entsinne, war\'s damals noch Quick-Basic oder was in der Art.

VisualStudio ist ja ganz nett, aber das Zeuch wird dermassen schnell
umgestaltet, dass man da nicht vernünftig was langlebiges planen
kann.

Tja - hinterher ist man immer schlauer. Leider hilft mir diese
Erkenntnis nicht weiter.

> Dazu kommt genereller bloat.

Damit lässt sich leben, wenn der Programmieraufwand nicht Tagesgeschäft
ist. Meine selbst geschriebenen Programme benutze ich mehr als dass ich
sie programmiere. So manche Fehler bleiben auch drin, weil die Gefahr
besteht, dass man im Rahmen der Fehlerbeseitigung noch viel schlimmere
Fehler einbaut und das erst spät bemerkt. So aber weiß ich um den Fehler
und kann ihn manuell mit wenig Aufwand aus der produzierten Textdatei
korrigieren. So lange ich der einzige Benutzer der Software bin - ich
kann damit leben.

--
Servus
Christoph Müller
www.astrail.de

 

[Hans-Peter Diettrich]

On 10/11/23 8:31 AM, Christoph Müller wrote:

Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

Das ist natürlich schlecht. Sonst hätte eine virtuelle Maschine mit
einem passenden Windows gereicht, um VB6 in seiner gewohnten Umgebung
weiter benutzen zu können.

Notfalls könnte aus der Maschine, auf der VB6 noch läuft, eine virtuelle
Maschine erzeugt werden. Hab\'s allerdings noch nie selbst gemacht...

Ansonsten könnte VB6 auch noch von VB.NET verdaut werden. Auch noch nie
probiert.

DoDi (AKA VBDis)

 

[Helmut Schellong]

Am 11.10.2023 um 08:31 schrieb Christoph Müller:

Am 10.10.2023 um 23:48 schrieb Rolf Bombach:
Christoph Müller schrieb:
Am 18.09.2023 um 23:43 schrieb Carla Schneider:

Der Vorteil der hoeheren Programmiersprachen ist dass man die
Programme beim Wechsel auf andere Hardware weiter verwenden
kann.

Habe ein paar Programme in VB6 (Visual Basic) geschrieben. Die Original CDs sind verschollen.
Wie kriegt man nun die Programme mit
 möglichst wenig Aufwand in gängigere Hochsprachen? Auf Win10
kriege ich sie jedenfalls nur teilweise zum Laufen. Deshalb steht
der alte Computer noch immer in meinem Büro.

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

[...]

Ich halte es allerdings eh für risky, auf so proprietären Sprachen was geplant langlebiges zu
entwickeln.

Das hättest du mir in den 90er Jahren sagen müssen. Wenn ich mich recht
entsinne, war\'s damals noch Quick-Basic oder was in der Art.

Meine erste Hochsprache ist PEARL, an der Fachhochschule.
Zu der Zeit wurde aber an der FHS schon positiv über C geredet.
Deshalb kaufte ich 1982 das Buch K&R1, und später K&R2 (ANSI-C).
So kam ich zu C, und wegen der diversen Unix-Systeme, die ja alle ein C-Entw.system haben.

Ich hatte früh erkannt, daß ich mit PEARL in der privaten Praxis leider nichts machen kann.

Tja - hinterher ist man immer schlauer. Leider hilft mir diese
Erkenntnis nicht weiter.

Mittlerweile beherrsche ich etwa 20 Programmiersprachen mehr oder weniger gut.
Auch das Ur-Basic mit den Nummern links und VB.

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C programmiert wird.
C eignet sich besonders gut für solche Aufgaben.
C++ wurde in den ersten Jahren übrigens zu einer C-Quelle übersetzt, die dann
einem C-Compiler übergeben wurde.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Christoph Müller]

Am 11.10.2023 um 11:15 schrieb Hans-Peter Diettrich:

On 10/11/23 8:31 AM, Christoph Müller wrote:
Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

Das ist natürlich schlecht. Sonst hätte eine virtuelle Maschine mit
einem passenden Windows gereicht, um VB6 in seiner gewohnten Umgebung
weiter benutzen zu können.

Notfalls könnte aus der Maschine, auf der VB6 noch läuft, eine virtuelle
Maschine erzeugt werden. Hab\'s allerdings noch nie selbst gemacht...

Hat nicht funktioniert.

Ansonsten könnte VB6 auch noch von VB.NET verdaut werden. Auch noch nie
probiert.

Kann man damit auch editieren?

--
Servus
Christoph Müller
www.astrail.de

 

[Christoph Müller]

Am 11.10.2023 um 11:54 schrieb Helmut Schellong:

Am 11.10.2023 um 08:31 schrieb Christoph Müller:

Tja - hinterher ist man immer schlauer. Leider hilft mir diese
Erkenntnis nicht weiter.

Mittlerweile beherrsche ich etwa 20 Programmiersprachen mehr oder
weniger gut.
Auch das Ur-Basic mit den Nummern links und VB.

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C
programmiert wird.

Wirklich nur EINE Lösung vorstellbar?

C eignet sich besonders gut für solche Aufgaben.
C++ wurde in den ersten Jahren übrigens zu einer C-Quelle übersetzt, die
dann einem C-Compiler übergeben wurde.
Danke für den Tipp. Muss mal etwas in mich gehen.

--
Servus
Christoph Müller
www.astrail.de