Ursache fuer Defekt

Gerhard Hoffmann schrieb:

das ist doch nicht hirnlos, da hat jemand sein Hirn sehr angestrengt,

Thema verfehlt.

--

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

Marc Haber schrieb:

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

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

In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden. (Inklusive Rekursion.) In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen

MfG hjs

Thomas Prufer

Hier ein Programm:

Thomas Prufer

Gerhard Hoffmann schrieb:

Das waren auch Prozessoren und nicht Intel-Quark.

Hallo Helmut,

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

ht

sinnvolle Bearbeitung umarbeiten.

n C programmiert werden, darauf beruhen fast alle "Exploits".

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.

Eben.

C ist sehr wohl etwas Besonderes.

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

Das ist doch keine Argument.

Bei C ist es umgekehrt. Verschachtelte Funktions-Definitionen sind reichlich unwichtig im Vergleich zur Rekursion.

Am 12.05.20 um 23:59 schrieb Sieghard Schicktanz:

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.

immer noch nicht beherrscht.

und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-

Gerhard

Am 12.05.2020 um 23:59 schrieb Sieghard Schicktanz:

, geht

en in

Programmierung und Tricks, die man ohne Preprozessor nicht von Hand hinbekommt.

Aber mit "alle" Sprachen geht sowas nicht, probiere mal FORTH oder Lisp

Z.B. sind in Delphi die subranges sehr hilfreich, bei denen man den

te findet man in anderen Programmiersprachen eher nicht, und sie lassen sich auch in C/C++ kaum bis garnicht nachbilden.

Reference Counting sauber nebenbei, in anderen Sprachen geht nur

Das sind so Dinge, die mir keine andere Programmierumgebung bietet, egal

DoDi

Hallo Helmut,

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

, geht

en in

ast alles, was nach Arbeit aussieht. Jedenfalls dann, wenn der Compiler ein Kompilat produziert.

Sicher: die Verbreitung von C.

...

kt in

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

...

...

ion.

(PEARL kenn' ich dahingehend nicht, nur dem Namen nach.)

C-Compiler, der gcc, das als eine Erweiterung ebenfalls implementiert gekriegt hat.

en

rtreiben

Rolf Bombach schrieb:

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.

CU, Christian

mit Fremdatomen versehen. Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit an den Schnittstellen durch Temperaturwechsel.

Die Diskussion schweift ab.

Das geht fast immer einfach und direkt.

C hat auf (fast) jede Konstruktion einer anderen Sprache eine Antwort. Meistens eine direkte Antwort.

Habe ich bereits beschrieben.

Du bist ein C-Feind.

Mindestens 99% (eher 99,9%) aller C-Programmierer programmieren sinnvoll. Diejenigen, die in C Quark programmieren, sind keine Profi-Programmierer,

Ich beherrsche etwa 15 Programmiersprachen unterschiedlich gut.

Aber PEARL m.W. nicht.

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

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.

Marc Haber schrieb: