Wirkungsgrad von 100 m RG213U

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

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

Mit welcher Wirkung?

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

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

DoDi

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.

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

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

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.

Am 24.09.2023 um 01:19 schrieb Helmut Schellong:

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

Am 23.09.23 um 23:05 schrieb Helmut Schellong:

Das habe ich auch nicht behauptet. S. Kontext. ;)

Tut er doch?

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

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

Sag ich doch.

Jetzt bin ich aber gespannt:

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

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

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

Am 24.09.2023 um 18:30 schrieb Hartmut Kraus:

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

Hallo Hans-Peter,

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

["mseide-msegui"]

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?

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

Nein, der C-Standard verlangt das.

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.

Ich auch; Der Code ist ungültig.

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.

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.

Ich schaue mal gründlich nach.

Am 24.09.2023 um 21:03 schrieb Sieghard Schicktanz:

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.

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

Hallo Helmut,

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

["Beautifier"].

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

Am 24.09.23 um 20:40 schrieb Helmut Schellong:

Schon mal geirrt?

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

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

Texte außerhalb des Standards sind nun mal unverbindlich.

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

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

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

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

Am 25.09.2023 um 21:35 schrieb Sieghard Schicktanz:

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!

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 ===============================================================================================

Am 23.09.2023 um 13:29 schrieb Helmut Schellong:

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

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

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

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

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.

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

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.

Einfach offizielle, gültige Dokumente verwenden.

Am 26.09.2023 um 12:31 schrieb Holger Schieferdecker:

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.

Am 25.09.2023 um 22:32 schrieb Hartmut Kraus:

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

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.