Nein, so konnte ich das nicht verstehen. Für mich ist der C-Standard 1 Text.
Nicht so ganz, die Zeilenenden müssen für den Compiler weiterhin sichtbar bleiben.
Das ist beim Präprozessor nicht anders. Der übersetzt nichts, wandelt nur den Quelltext um. Als eigenständiges Programm kann er jeden Text überarbeiten.
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.
Ja, natürlich. Ein Bezug auf andere Texte außerhalb des Standards wäre ja Unfug.
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.
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.
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.
Nein, gar nicht. ISO und IEC sind internationale Organisationen. ANSI ist eine US-amerikanische Organisation, die ISO-Standards übernimmt, so wie auch DIN.
C++ wird von der WG21 bearbeitet, einer anderen Workgroup.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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++.
Am 28.09.2023 um 20:55 schrieb Sieghard Schicktanz:
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.
[...]
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. >>>
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.
Kenne ich seit den 1980ern. Die 5 verschieden umfangreichen Aufgaben eines C-Compilers habe ich in meinen C-Büchern erklärt.
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.
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.
Nein, da "verschwidet" nichts.
Ja, falsch.
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...
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.
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.
Das ist die identische Funktion, halt indirekt über das Steuerprogramm.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.