Ursache fuer Defekt...

  • Thread starter Hans-Juergen Schneider
  • Start date
Gerhard Hoffmann schrieb:
Und ja, UCSD-Pascal auf dem 68000 oder einer umprogrammierten
LSI-11  ( aka Western Digital p-code machine) war schon geil.

Das waren auch Prozessoren und nicht Intel-Quark.

--
mfg Rolf Bombach
 
Gerhard Hoffmann schrieb:
Und ja, UCSD-Pascal auf dem 68000 oder einer umprogrammierten
LSI-11  ( aka Western Digital p-code machine) war schon geil.

Das waren auch Prozessoren und nicht Intel-Quark.

--
mfg Rolf Bombach
 
Hallo Helmut,

Du schriebst am Tue, 12 May 2020 15:09:41 +0200:

Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.

Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".

In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):

int F1 (int p; bool c)
{
int lokal; ...

bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}

Geht nicht? Gibt\'s doch nicht!

Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

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

Du schriebst am Tue, 12 May 2020 15:09:41 +0200:

Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.

Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".

In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):

int F1 (int p; bool c)
{
int lokal; ...

bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}

Geht nicht? Gibt\'s doch nicht!

Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
 
On 05/12/2020 23:59, Sieghard Schicktanz wrote:
Hallo Helmut,

Du schriebst am Tue, 12 May 2020 15:09:41 +0200:

Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

Eben.
Bei Übersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muß einen Grund haben.

In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.

Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".

Manche Programmierer machen Unsinniges in C - manche, nicht alle.

In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
[Quelltext]
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
 
On 05/12/2020 23:59, Sieghard Schicktanz wrote:
Hallo Helmut,

Du schriebst am Tue, 12 May 2020 15:09:41 +0200:

Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

Eben.
Bei Übersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muß einen Grund haben.

In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.

Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".

Manche Programmierer machen Unsinniges in C - manche, nicht alle.

In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
[Quelltext]
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
 
Am 12.05.20 um 23:59 schrieb Sieghard Schicktanz:
Hallo Helmut,

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):

int F1 (int p; bool c)
{
int lokal; ...

bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}

Geht nicht? Gibt\'s doch nicht!

Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.


Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.

Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.

Gerhard
 
Am 12.05.20 um 23:59 schrieb Sieghard Schicktanz:
Hallo Helmut,

Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):

int F1 (int p; bool c)
{
int lokal; ...

bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}

Geht nicht? Gibt\'s doch nicht!

Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.

Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.


Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.

Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.

Gerhard
 
Am 12.05.2020 um 21:00 schrieb Rolf Bombach:
Gerhard Hoffmann schrieb:

Und ja, UCSD-Pascal auf dem 68000 oder einer umprogrammierten
LSI-11  ( aka Western Digital p-code machine) war schon geil.

Das waren auch Prozessoren und nicht Intel-Quark.

Klar, da konnte man beim Programmieren und Prozessieren nebenher noch
Blumen pflücken gehen. Meistens sass der gesamte Fachbereich in der
Cafeteria und wartete.

--

Roland Franzius
 
Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:

Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:

google \"echte programmierer meiden Pascal\".

hing schon 1983 an meinem Gymnasium im Computerraum.

Die Lesbarkeit von C-Programmen ist wirklich vorbildlich, die
Übertragung nach Pascal ist mir leider nicht gelungen!

Thema verfehlt.


Wieso? Echte Programmierer meiden Pascal, weil man sowas nicht in
Pascal schreiben kann.
Passt doch.

https://www.mikrocontroller.net/topic/53447

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
 
Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:

Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:

google \"echte programmierer meiden Pascal\".

hing schon 1983 an meinem Gymnasium im Computerraum.

Die Lesbarkeit von C-Programmen ist wirklich vorbildlich, die
Übertragung nach Pascal ist mir leider nicht gelungen!

Thema verfehlt.


Wieso? Echte Programmierer meiden Pascal, weil man sowas nicht in
Pascal schreiben kann.
Passt doch.

https://www.mikrocontroller.net/topic/53447

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
 
Rolf Bombach schrieb:

Kurt schrieb:

Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.

Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?

Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.

CU,
Christian
 
Rolf Bombach schrieb:

Kurt schrieb:

Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.

Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?

Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.

CU,
Christian
 
On 05/14/2020 09:33, Christian Treffler wrote:
Rolf Bombach schrieb:

Kurt schrieb:

Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.

Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?

Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.

Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.

In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.



--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
 
On 05/14/2020 09:33, Christian Treffler wrote:
Rolf Bombach schrieb:

Kurt schrieb:

Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.

Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?

Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.

Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.

In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.



--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
 
On 05/13/2020 23:12, Sieghard Schicktanz wrote:
Hallo Helmut,

Du schriebst am Wed, 13 May 2020 00:32:18 +0200:

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

Eben.
Bei Übersetzung in C entfällt das (und Anderes).

Natürlich. Bei Übersetzung eines C-Programms in C entfällt fast alles,
was nach Arbeit aussieht. Jedenfalls dann, wenn der Compiler ein Kompilat
produziert.

Die Diskussion schweift ab.

Es ging darum, andere Sprachen in C zu übersetzen.
Das geht fast immer einfach und direkt.

Mit anderen Übersetzungs-Zielsprachen ist das nur schwer möglich.
Direkte Übersetzung meist unmöglich.

C hat auf (fast) jede Konstruktion einer anderen Sprache eine Antwort.
Meistens eine direkte Antwort.
Für fast alle anderen Sprachen gilt das nicht.

C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.

Ja, der ist ein eigenes Höllenloch.

Der ist extrem sinnvoll und nützlich.

Die immense Verbreitung von C muß einen Grund haben.

Sicher: die Verbreitung von C.

Die Hauptgründe für die immense Verbreitung von C sind andere.
Habe ich bereits beschrieben.

Vor allem problematische und unsichere Konstrukte können sehr direkt in
C programmiert werden, darauf beruhen fast alle \"Exploits\".

Manche Programmierer machen Unsinniges in C - manche, nicht alle.

Umgedreht: Manche Programmierer machen Sinnvolles in C - manche, nicht alle.

Du bist ein C-Feind.
Es ist daher reichlich sinnlos, sich mit Dir darüber zu unterhalten.

Mindestens 99% (eher 99,9%) aller C-Programmierer programmieren sinnvoll.
Diejenigen, die in C Quark programmieren, sind keine Profi-Programmierer,
sondern Quatschköppe, die mit anderen Absichten die Foren bevölkern.

> Du kennst halt nix anderes außer ein bisserl C.

Ich beherrsche etwa 15 Programmiersprachen unterschiedlich gut.
Und ich habe drei C-Bücher geschrieben.
http://www.amazon.de/exec/obidos/ISBN=3642544363

Klar kann Pascal _auch_
Rekursion, es ist schließlich ebenfalls Turing-vollständig.
(PEARL kenn\' ich dahingehend nicht, nur dem Namen nach.)

Es stimmt, daß Pascal rekursive Funktionen kann.
Aber PEARL m.W. nicht.

Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.

Abersicherdochjedenfalls. So unwichtig, daß einer der verbreitetsten
C-Compiler, der gcc, das als eine Erweiterung ebenfalls implementiert
gekriegt hat.
Und mit jeder neuen Version findet man wieder weitere Übernahmen aus den
alten Sprachen der Algol-Familie, von Syntaxerweiterungen über Typprüfungen
bis hin zu Bereichsprüfungen. Inzwischen fangen sie schon zum übertreiben
an und mosern auch über \"falsche\" Quellentext-Formatierung.

Das ist alles vollkommen irrelevant.
Denn es gilt jeweils immer nur der aktuelle C-Standard.

Ich wußte nicht, daß gcc verschachtelte Funktionsdefinitionen kann.
Dieses Merkmal ist unwichtig und es ist kein Bestandteil von C, sondern
ein nicht standard-konformer C-Dialekt.
Auf meinem System (FreeBSD) ist clang der C-Compiler.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
 
Helmut Schellong schrieb:
Generell steigt die Fehlerwahrscheinlichkeit
mit jeder vorhandenen Lötstelle.
Redundante Lötstellen und reine Befestigungslötungen sind nicht gemeint.
Deshalb ist ein IC mit 8 Pins sicherer als dessen Innenschaltung
diskret aufgebaut mit 350 Lötstellen.
Desweiteren ist ein IC nur 1 Bauelement.

In den USA war wohl der Entscheid der Militärs (oder JAN(N)AF, habs
vergessen) \"if possible use IC\" massgeblich für den Durchstart
der IC-Schaltungen. Das waren am Anfang lächerlich einfache IC
wie CA3028, und der scheint schon eine Verbesserung der Zuverlässigkeit
gebracht zu haben.

--
mfg Rolf Bombach
 
Am 12.05.2020 um 23:59 schrieb Sieghard Schicktanz:
Hallo Helmut,

Du schriebst am Tue, 12 May 2020 15:09:41 +0200:

Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.

Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muß nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.

Manche Dinge gehen kaum, wie \"interrupt\" für die low-level
Programmierung und Tricks, die man ohne Preprozessor nicht von Hand
hinbekommt.

Aber mit \"alle\" Sprachen geht sowas nicht, probiere mal FORTH oder Lisp
in eine andere Sprachfamilie zu übersetzen.

In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.

Das gilt nur für Algorithmen (Syntax), nicht für Attribute.

Z.B. sind in Delphi die subranges sehr hilfreich, bei denen man den
zulässigen Wertebereich exakt vorgeben kann. Und dann kann man jede
Zuweisung zur Laufzeit überwachen lassen, und per Compilerswitch die
Überwachung ein- und ausschalten. Solche extrem hilfreichen Konstrukte
findet man in anderen Programmiersprachen eher nicht, und sie lassen
sich auch in C/C++ kaum bis garnicht nachbilden.

Auch Garbage Collection ist so eine Sache, die läuft in Delphi mit
Reference Counting sauber nebenbei, in anderen Sprachen geht nur
mark-sweep, mit Raten und zwangsläufiger Unterbrechung des Programms.

Das sind so Dinge, die mir keine andere Programmierumgebung bietet, egal
für welche Sprache.

DoDi
 

Welcome to EDABoard.com

Sponsor

Back
Top