Wirkungsgrad von 100 m RG213U

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

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

Beides ist fehlerhaft, was ein guter Compiler sogar meldet!

Bitte zeige einen fehlerfrei compilierbaren Quelltext.

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

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.

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

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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!" | ^~~~~ =================================================================================================================

Helmut Schellong schrieb:

In der Schweiz gibt es sogar einen Touring-Club.

Am 05.10.2023 um 21:10 schrieb Rolf Bombach:

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

Der Typ heißt Alan Turing.

Rolf Bombach schrieb:

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

Christoph Müller schrieb:

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.

Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

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

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.

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.

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

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.

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)

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

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.

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.

Hat nicht funktioniert.

Kann man damit auch editieren?

Am 11.10.2023 um 11:54 schrieb Helmut Schellong:

Wirklich nur EINE Lösung vorstellbar?

Danke für den Tipp. Muss mal etwas in mich gehen.

Am 11.10.2023 um 17:56 schrieb Christoph Müller:

Ich habe Deine Schilderungen hierzu gelesen. Wenn Du nur die VB-Quellen hast, und sonst gar nichts, fällt mir nur ein Quellen-Übersetzer ein.

C ist die feinkörnigste universelle Hochsprache. Daher bestens geeignet für Solches.

Helmut Schellong schrieb:

Bei C müsstest du aber wissen, was der Compiler draus macht. Und bei Numerik wird auf Libraries zurückgegriffen. Teste mal, ob x = a^2 etwa 50x langsamer ist als x = a * a falls ja, ist dein Compiler doof und/oder unbekannt, was er so treibt. Es ging Jahre bis Jahrzehnte, bis C so schnell wie Fortran war, und im Supercomputing wüsste ich jetzt nicht, was da genommen wird. Fortran war von Anfang an auf Optimierung ausgelegt. Die Überlegung war ja gerade, dass die Sprache nur Erfolg haben wird, wenn sie nicht langsamer als Assembler ist.

Christoph Müller schrieb:

Ich verstehe die Frage nicht. VB6 ist doch eine Entwicklungsumgebung.

Am 11.10.2023 um 23:17 schrieb Rolf Bombach:

Das weiß ich gut bei clang, gcc und embarcadero_clang (Windows).

Zu Nachfolgendem muß ich aber die Deklaration der Variablen kennen. In C ist x = a^2 beispielsweise unbekannt. Einen Potenzier-Operator gibt es nicht.

Microsoft ist mit seinen Versuchen, VB zu compilieren, fürchterlich auf die Schnauze geflogen. Ich habe mir den von VB.NET aus VB6 erzeugten Quelltext angeschaut und war ziemlich enttäuscht, was da hinter den Kulissen alles emuliert werden muß.

Ich würde mal im Internet nach VB6 CDs suchen, könnte ganz günstig zu haben sein. Im Prinzip genügen sogar Kopien, wenn nur der Schlüssel noch bekannt ist.

DoDi