Wirkungsgrad von 100 m RG213U...

[Helmut Schellong]

Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:

On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in 3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Leo Baumann]

Am 22.09.2023 um 08:56 schrieb Helmut Schellong:

Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:
On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in
3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu
übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

Ich hasse das C-Gestammel. Das ist keine lesbare Hochsprache noch Assembler.

Ich habe letztens mit Delphi-Pascal gearbeitet und alles zeitintensive
in Assembler geschrieben.

Ich bin alergisch gegen C.

Grüße

 

[Helmut Schellong]

Am 22.09.2023 um 09:01 schrieb Leo Baumann:

Am 22.09.2023 um 08:56 schrieb Helmut Schellong:
Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:
On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in 3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

Ich hasse das C-Gestammel. Das ist keine lesbare Hochsprache noch Assembler.

Ich habe letztens mit Delphi-Pascal gearbeitet und alles zeitintensive in Assembler geschrieben.

Ich bin alergisch gegen C. ;allergisch, das Zeitintensive

Das merkt man deutlich.
Deshalb stellst Du auch die Behauptung auf, C sei keine lesbare Hochsprache.
Du bist der Einzige, den ich kenne, der Assembler besser findet.
Damit stehst Du aber ziemlich allein auf weiter Flur.

Ich hatte bereits vor längerer Zeit mitgeteilt, daß ich etwa 20 Programmiersprachen
mehr oder weniger gut beherrsche.
C ist darunter diejenige Sprache, die mir am stärksten entgegen kommt.
Gefolgt von PEARL und Ada.
(Mit Ada habe ich noch nicht konkret gearbeitet.)


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Leo Baumann]

Am 22.09.2023 um 09:43 schrieb Helmut Schellong:

Am 22.09.2023 um 09:01 schrieb Leo Baumann:
Am 22.09.2023 um 08:56 schrieb Helmut Schellong:
Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:
On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in
3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu
übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

Ich hasse das C-Gestammel. Das ist keine lesbare Hochsprache noch
Assembler.

Ich habe letztens mit Delphi-Pascal gearbeitet und alles zeitintensive
in Assembler geschrieben.

Ich bin alergisch gegen C.         ;allergisch, das Zeitintensive

Das merkt man deutlich.
Deshalb stellst Du auch die Behauptung auf, C sei keine lesbare
Hochsprache.
Du bist der Einzige, den ich kenne, der Assembler besser findet.
Damit stehst Du aber ziemlich allein auf weiter Flur.

Ich hatte bereits vor längerer Zeit mitgeteilt, daß ich etwa 20
Programmiersprachen
mehr oder weniger gut beherrsche.
C ist darunter diejenige Sprache, die mir am stärksten entgegen kommt.
Gefolgt von PEARL und Ada.
(Mit Ada habe ich noch nicht konkret gearbeitet.)

Ich habe das Optimum für mich gefunden. Programmoberfläche in
Delphi-Pascal, Routinen in Assembler.

Wenn man in Übung ist, kann man Assembler herunterschreiben wie BASIC.

 

[Stefan Ram]

Carla Schneider <carla_schn@proton.me> writes:
>Der Preprozessor ist auch kein Teil von C

Die Programmiersprache C wird durch die ISO/IEC 9899
beschrieben. Und diese Beschreibung umfaßt auch den
Präprozessor:

|5.1 Conceptual models
|
|5.1.1 Translation environment
|
|5.1.1.1 Program structure
|
|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]

Marte Schwarz <marte.schwarz@gmx.de> writes:

All diese Ebenen in einen Topf zu werfen und dann zu behaupten, 95 %
aller Programme seien C/C++ ist einfach Unsinn, zumal die Basis nicht
definiert wurde. Was sollen denn 100 % sein? Anzahl der geschriebenen
Codezeilen, ausgelieferte Stück Hardware, im zeitlichen Mittel laufender
Code ... ?

Man kann es schlecht genau in Prozent messen, aber die
Standardimplementationen von Java oder Python (Compiler
beziehungsweise Interpretierer und Laufzeitumgebungen) sind in
C oder C++ geschrieben, genauso wie führende Betriebssysteme,
Browser, Datenbanken oder Office-Pakete.

In diesem Sinne beruht die Infrastruktur auf C oder C++.
Darauf aufbauend werden dann sicher auch andere Programmiersprachen
verwendet.

In Python ist es auch möglich, Teile einer Bibliothek oder
eines Programms zur Beschleunigung in C zu schreiben, und
verschiedene Python-Software macht davon Gebrauch. Daher
müßte man Software, die als \"Python-Software\" bekannt ist
eigentlich \"Python/C-Software\" nennen.

 

[Hergen Lehmann]

Am 22.09.23 um 00:23 schrieb Wolfgang Allinger:

On 21 Sep 23 at group /de/sci/electronics in article 4eqttj-u7rc3.ln1@hergen.spdns.de
hlehmann.expires.12-22@snafu.de> (Hergen Lehmann) wrote >> Ich arbeite heute zwar überwiegend mit C++, aber auch zu C-Zeiten habe
ich nie ein Programm von Hand compiliert.

Damit war gemeint, dass der C-Programmierer im Kopf haben muss, was der
Compiler veranstaltet.

Ein C-Programmierer sollte verstanden haben, was ein Zeiger ist, das ist
aber auch alles.

Mehr Lowlevel-Kenntnisse sind nur erforderlich, wenn man tatsächlich
hardwarenah programmiert. Dann ist es aber gerade ein Vorteil, das der
Zusammenhang zwischen Quellcode und Maschinencode nachvollziehbar bleibt.

Wenn mich meine Erinnerung nicht täuscht, \"compiliert\" FORTH lediglich
in eine Art Zwischencode, welcher auf 99.9998% der verfügbaren Hardware
anschließend interpretiert wird.
Es gab zwar mal auf FORTH optimierte Hardware, aber das war eine Nische
in der Nische in der Nische.

Nein, Du irrst. FORTH schaltet zwischen Interpreter und Compiler ständig
hin und her. Kommt drauf an, was da gerade im Eingabestrom gefunden wird.

Und wenn er compiliert, compiliert er in echten Maschinencode?
Wie soll das gehen, bei einer Stack-orientierten Spracharchitektur und
Mikrocontrollern, deren Hardware-Stack teilweise auf eine handvoll
Ebenen beschränkt ist?

Aber er hat was vorzuweisen. Typischerweise ist ein Forth Programmierer
2-30! mal produktiver, als ein C-Programmierer.

Ja, für Rapid Prototyping kleiner Sachen hat eine Interpreter- oder
JIT-Sprache Vorteile. Nicht umsonst hat Python in den vergangenen Jahren
einen Siegeszug hingelegt.

Das ändert sich aber schnell, wenn die Projekte umfangreicher werden,
wenn auf Performance optimiert werden soll, oder wenn in kommerziellen
Projekten eine Weitergabe des Quellcode ausdrücklich unerwünscht ist.

Ich hab etliche Projekte als Rapid-Prototyping gemacht, die dann
anschließend in eine andere Programmiersprache umgesetzt worden

Also scheinbar nicht so wirklich Produktions-tauglich?

 

[Hergen Lehmann]

Am 22.09.23 um 00:45 schrieb Hans-Peter Diettrich:

On 9/21/23 5:24 PM, Hergen Lehmann wrote:
[Delphi]
Vor allem aber ist es hochgradig proprietär. Man ist auf Gedeih und
Verderb einem einzelnen Lieferanten und dessen (Lizenz-)Kapriolen
ausgeliefert.

Es gibt noch FreePascal/Lazarus, damit lassen sich auch µC
programmieren.

Das ist dann aber kein Delphi mehr, sondern ein weiterer Dialekt...

Das Blöde an Pascal ist, das die offizielle Entwicklung der Sprache Ende
der 80er Jahre (IEEE/ANSI 770X3.160-1989) stehen geblieben ist und
danach nur noch Wildwuchs herrschte, mit zahlreichen Queranleihen
zwischen den Entwicklungslinien, aber keiner garantierten Portabilität.
Wenn der (englische) Wikipedia-Artikel stimmt, hat FreePascal selbst
heute noch keine vollständige Kompatibilität zu der o.g. Norm... :-(


Die Architektur ist unerreicht was Projekt-Management,

turn-around Zeiten und Fehlersuche betrifft. Aber wer nur C kennt, der
weiß nicht, was ihm in dieser Hinsicht alles entgeht.

Hey, Pascal war meine erste höhere Programmiersprache! Ich habe während
Schule, Studium (Nebenjobs) und in den ersten Berufsjahren viel in Turbo
Pascal und auch ein wenig Delphi gemacht.

Ich war dann aber ehrlich gesagt froh, davon weg zu kommen, habe
allerdings C nur gekratzt (für einige uC-Projekte) und für die dicken
Projekte gleich mit C++ weiter gemacht. Wenn ich mir den aktuellen
C-Standard ansehe, ist da aber inzwischen viel zurück geflossen und
einige Dinge sind sogar schöner gelöst als in C++.

Beide Sprachen leben, was man von Pascal, FORTH, etc. nicht behaupten
kann.

 

[Helmut Schellong]

Am 22.09.2023 um 09:58 schrieb Leo Baumann:

Am 22.09.2023 um 09:43 schrieb Helmut Schellong:
Am 22.09.2023 um 09:01 schrieb Leo Baumann:
Am 22.09.2023 um 08:56 schrieb Helmut Schellong:
Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:
On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in 3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

Ich hasse das C-Gestammel. Das ist keine lesbare Hochsprache noch Assembler.

Ich habe letztens mit Delphi-Pascal gearbeitet und alles zeitintensive in Assembler geschrieben.

Ich bin alergisch gegen C.         ;allergisch, das Zeitintensive

Das merkt man deutlich.
Deshalb stellst Du auch die Behauptung auf, C sei keine lesbare Hochsprache.
Du bist der Einzige, den ich kenne, der Assembler besser findet.
Damit stehst Du aber ziemlich allein auf weiter Flur.

Ich hatte bereits vor längerer Zeit mitgeteilt, daß ich etwa 20 Programmiersprachen
mehr oder weniger gut beherrsche.
C ist darunter diejenige Sprache, die mir am stärksten entgegen kommt.
Gefolgt von PEARL und Ada.
(Mit Ada habe ich noch nicht konkret gearbeitet.)

Ich habe das Optimum für mich gefunden. Programmoberfläche in Delphi-Pascal, Routinen in Assembler.

Du mußt Delphi durch Assembler ergänzen.
Ich nicht, weil C seit etwa 20 Jahren so gut kompiliert, daß ASM nicht mehr notwendig ist.

Ich habe in jedem C-Projekt-Verzeichnis eine Assembler-Datei datei.s.
Diejenige zur bish ist etwa 2,5 MB groß.
Ich kontrolliere damit sporadisch die Arbeit des verwendeten Compilers.

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.
Da gab es den Typ Kardinal, 29 Bit breit oder so - Hää?!
Ja, Delphi macht Tests zur Runtime.
Man merkt das deutlich!
Brauche ich nicht, ich sorge selbst für Vorabsicherheit, plausible Werte, etc.

> Wenn man in Übung ist, kann man Assembler herunterschreiben wie BASIC.

Kann ich auch, seit den 1980ern:

http://www.schellong.de/htm/math87.htm
http://www.schellong.de/cgi/get.cgi?0.181:..%2ftxt%2fasm87c.c


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 22.09.2023 um 10:07 schrieb Stefan Ram:

Carla Schneider <carla_schn@proton.me> writes:
Der Preprozessor ist auch kein Teil von C

Die Programmiersprache C wird durch die ISO/IEC 9899
beschrieben. Und diese Beschreibung umfaßt auch den
Präprozessor:

|5.1 Conceptual models
|
|5.1.1 Translation environment
|
|5.1.1.1 Program structure
|
|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.
...

Ja, C ist eine Two-Pass-Angelegenheit, wie ich in 21.09.2023 17:21 schrieb.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Stefan Ram]

\"Wolfgang Allinger\" <all2001@spambog.com> writes:
>(*) C ist zB: (*(void(*)())0)()

Dort wird der Wert eines Ausdruck \"(void(*)())0\" dereferenziert
und aufgerufen. Dieser Wert ist 0 und der Typ des Ausdrucks
ist \"Adresse einer Funktion, die keinen Wert liefert\".

Da in C praktisch nicht zwischen Funktionen und Funktionsadressen
unterschieden wird, ist die Dereferenzierung mit dem ersten
Sternchen unnötig, \"((void(*)())0)()\" wäre also dasselbe.

Der Aufruf einer Funktion an der Adresse 0 (wo gar keine
Funktion ist) sollte allerdings undefiniertes Verhalten haben,
so daß es nicht ganz klar ist, wofür dieser Code gut sein soll.

 

[Helmut Schellong]

Am 22.09.2023 um 10:54 schrieb Stefan Ram:

Marte Schwarz <marte.schwarz@gmx.de> writes:
All diese Ebenen in einen Topf zu werfen und dann zu behaupten, 95 %
aller Programme seien C/C++ ist einfach Unsinn, zumal die Basis nicht
definiert wurde. Was sollen denn 100 % sein? Anzahl der geschriebenen
Codezeilen, ausgelieferte Stück Hardware, im zeitlichen Mittel laufender
Code ... ?

Man kann es schlecht genau in Prozent messen, aber die
Standardimplementationen von Java oder Python (Compiler
beziehungsweise Interpretierer und Laufzeitumgebungen) sind in
C oder C++ geschrieben, genauso wie führende Betriebssysteme,
Browser, Datenbanken oder Office-Pakete.

In diesem Sinne beruht die Infrastruktur auf C oder C++.
Darauf aufbauend werden dann sicher auch andere Programmiersprachen
verwendet.

In Python ist es auch möglich, Teile einer Bibliothek oder
eines Programms zur Beschleunigung in C zu schreiben, und
verschiedene Python-Software macht davon Gebrauch. Daher
müßte man Software, die als \"Python-Software\" bekannt ist
eigentlich \"Python/C-Software\" nennen.

Beispiel:
===================================================================================
/*
X - B R A I N S O F T W A R E Strukturgenerator Vers. 2.0 12. 8.1999
COPYRIGHT (c) 1993 by Fa. Besel und Gruener D-86159 Augsburg ALL RIGHTS RESERVED
*/
typedef struct
{
DELFL delfl; /* 0 2.0 C-TREE internal */
PKEY ident[2]; /* 4 8.0 Interner */
double menge; /* 12 9.2 ab */
double mrabsz; /* 20 5.2 Rabatt */
double _ddummy1; /* 28 2.0 Dummy */
double _ddummy2; /* 36 2.0 Dummy */
double _ddummy3; /* 44 2.0 Dummy */
MONEY vkpreis; /* 52 12.4 Preis/E */
MONEY _mdummy1; /* 60 2.0 Dummy */
MONEY _mdummy2; /* 68 2.0 Dummy */
MONEY _mdummy3; /* 76 2.0 Dummy */
long _ldummy1; /* 84 2.0 Dummy */
long _ldummy2; /* 88 2.0 Dummy */
long _ldummy3; /* 92 2.0 Dummy */
DATE datum; /* 96 8.0 gltig */
DATE _datdummy1; /* 100 8.0 Dummy */
DATE _datdummy2; /* 104 8.0 Dummy */
DATE _datdummy3; /* 108 8.0 Dummy */
KW _kwdummy1; /* 112 6.0 Dummy */
KW _kwdummy2; /* 116 6.0 Dummy */
KW _kwdummy3; /* 120 6.0 Dummy */
short preisgr; /* 124 3.0 Preisgr. */
short _shdummy1; /* 126 2.0 Dummy */
short _shdummy2; /* 128 2.0 Dummy */
short _shdummy3; /* 130 2.0 Dummy */
STRING euroyn[2]; /* 132 1.0 Euro-J/N */
STRING _stdummy1[32]; /* 134 2.0 Dummy */
STRING _stdummy2[32]; /* 166 2.0 Dummy */
STRING _stdummy3[32]; /* 198 2.0 Dummy */
STRING filler[2]; /* 230 1.0 Strukturfueller */
} ARVK; /* 232 */

typedef ARVK* PARVK;
===================================================================================


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 22.09.2023 um 11:18 schrieb Stefan Ram:

\"Wolfgang Allinger\" <all2001@spambog.com> writes:
(*) C ist zB: (*(void(*)())0)()

Dort wird der Wert eines Ausdruck \"(void(*)())0\" dereferenziert
und aufgerufen. Dieser Wert ist 0 und der Typ des Ausdrucks
ist \"Adresse einer Funktion, die keinen Wert liefert\".

Da in C praktisch nicht zwischen Funktionen und Funktionsadressen
unterschieden wird, ist die Dereferenzierung mit dem ersten
Sternchen unnötig, \"((void(*)())0)()\" wäre also dasselbe.

Der Aufruf einer Funktion an der Adresse 0 (wo gar keine
Funktion ist) sollte allerdings undefiniertes Verhalten haben,
so daß es nicht ganz klar ist, wofür dieser Code gut sein soll.

Ja, wie ich es in 21.09.2023 16:30 schrieb.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Stefan Ram]

Carla Schneider <carla_schn@proton.me> writes:

Wolfgang Allinger wrote:
Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion
aufgerufen die an Adresse Null liegt.
Hab das ; weggelassen, da IMHO nicht relevant
Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Normalerweise wird ein Semikolon in C nicht für den Aufruf
einer Funktion benötigt, wie das folgende Programm zeigt,
welche die Funktion \"O\" in \"main\" ohne Semikolon aufruft.

main.c

#include <stdio.h>

int O( void ){ puts( \"O wurde aufgerufen.\" ); return 0; }

int main( void ){ if(((*(int(*)())O)())){} }

Protokoll des Laufs

O wurde aufgerufen.

Dem Aufruf einer void-Funktion wird aber in der Regel ein Semikolon
folgen. Wenn man sagt, daß das Semikolon \"fehlt\", dann müßte man
allerdings sagen, daß noch mehr fehlt, denn \"(*(void(*)())0)();\"
ist ja immer noch kein vollständiges lauffähiges Programm ...

 

[Carla Schneider]

Leo Baumann wrote:

Am 22.09.2023 um 08:56 schrieb Helmut Schellong:
Am 22.09.2023 um 00:20 schrieb Hans-Peter Diettrich:
On 9/21/23 6:18 PM, Helmut Schellong wrote:

Ein größeres C-Projekt von mir - 50 Dateien, 1,2 MB - compiliert in
3,7s.

Beim zweiten Mal vielleicht, wenn nur noch geänderte Dateien neu
übersetzt werden müssen.

Nein, ich verwende kein make-Kommando.
Es werden immer alle Dateien neu übersetzt.
Da das in wenigen Sekunden geht, schreibe ich auch kein MakeFile.

Ich hasse das C-Gestammel. Das ist keine lesbare Hochsprache noch Assembler.

So etwa um 1988 bin ich von Pascal auf C umgestiegen, weil sie am Institut einen
Unix-Vektorrechner angeschafft hatten, auf dem gab es nur FORTRAN und C.
Wenn ich mich recht erinnere waren die Sprachen sehr aehnlich, aber C braucht
weniger Zeichen, allein schon weil \"begin\" und \"end\" durch {} ersetzt wurden.
Es gab zudem einen \"Pascal to C translator\" fuer bestehende Programme.

Ich habe letztens mit Delphi-Pascal gearbeitet und alles zeitintensive
in Assembler geschrieben.


Ich bin alergisch gegen C.

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

 

[Stefan Ram]

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Der Aufruf einer Funktion an der Adresse 0 (wo gar keine
Funktion ist) sollte allerdings undefiniertes Verhalten haben,
so daß es nicht ganz klar ist, wofür dieser Code gut sein soll.

C garantiert sogar, daß die Wandlung von 0 in einen Zeigertyp
nicht auf eine Funktion zeigt:

|If a null pointer constant is converted to a pointer type,
|the resulting pointer, called a null pointer, is guaranteed
|to compare unequal to a pointer to any object or function.

. Aber selbst, wenn statt dessen ein Zeiger auf eine
Funktion verwendet wird, muß der Typ der aufgerufenen
Funktion auch mit dem Typ des Zeigers verträglich sein:

|If a converted pointer is used to call a function whose type
|is not compatible with the referenced type, the behavior is
|undefined.

.

 

[Volker Bartheld]

On Fri, 2023-09-22 at 10:49 +0200, Hergen Lehmann wrote:

Ein C-Programmierer sollte verstanden haben, was ein Zeiger ist, das ist
aber auch alles.

Für denjenigen, der irgendwann in seinem Leben

LD IX,1234
LD (IX+6),7

benutzt hat, wirklich keine allzu große Transferleistung.

Volker

 

[Stefan Ram]

Volker Bartheld <news2023@bartheld.net> writes:

Für denjenigen, der irgendwann in seinem Leben
LD IX,1234
LD (IX+6),7
benutzt hat, wirklich keine allzu große Transferleistung.

Ein wichtiger Unterschied zwischen Maschinenadressen und Zeigern
besteht darin, daß ein Zeiger einen Typ hat, und die Addition einer 1
zu einem Objektzeiger in C in Abhängigkeit vom Typ des Zeigers einer
Addition einer größeren Zahl in Maschinensprache entsprechen kann.

Dann sind Zeiger in C stärker eingeschränkt als Maschinenadressen,
um bestimmte Fehler zu vermeiden und portabler zu sein. So
können in der Regel nur Zeiger auf \"größer\" verglichen werden,
welche in dieselbe Reihung zeigen, ein Zeiger darf nur auf
bestimmte Funktionen/Objekte oder Stellen in einer Reihung zeigen
und nur unter bestimmten Bedingungen dereferenziert werden.

 

[Helmut Schellong]

Am 22.09.2023 um 11:34 schrieb Stefan Ram:

Carla Schneider <carla_schn@proton.me> writes:
Wolfgang Allinger wrote:
Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion
aufgerufen die an Adresse Null liegt.
Hab das ; weggelassen, da IMHO nicht relevant
Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Normalerweise wird ein Semikolon in C nicht für den Aufruf
einer Funktion benötigt, wie das folgende Programm zeigt,
welche die Funktion \"O\" in \"main\" ohne Semikolon aufruft.

main.c

#include <stdio.h

int O( void ){ puts( \"O wurde aufgerufen.\" ); return 0; }

int main( void ){ if(((*(int(*)())O)())){} }

if (a>k+1) foo(3), bar(a), --a;

Vorstehend Aufrufe auch ohne Semikolon.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Leo Baumann]

Am 22.09.2023 um 13:50 schrieb Carla Schneider:

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

In der Kombination Pascal-Assembler geht alles!