Forum: PC-Programmierung Lazarus Pascal / Delphi /FreePascal aktiver als viele denken? EADS, Sony etc


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

W.S. schrieb:
> aber wenn ich den Jörg hier jammern sehe, daß der AD in seiner
> virtuellen Box über mangelndes DirectX klagt,

Ich denke, dass sie da nur irgendwas falsch gemacht haben. Erstens ist 
es keine Virtualbox, zweitens lief es auch bislang (einschließlich allen 
3Ds) schon in VMware, drittens gab/gibt es andere (hier im Forum), die 
auch mit der aktuellen AD-Version in VMware kein Problem haben. Wenn sie 
mir aber erzählen, dass sie angeblich DirectX 10 brauchen, und das 
Microsoft-Tool sagt mir, dass die vorhandene Version 12 oder 13 ist, 
dann ist da irgendwas im Argen, und sie sollten sich als Hersteller 
einfach mal drehen, wenn sie mir das Zeug verkaufen wollen. Danach war 
aber nur Schweigen im Walde.

von Nop (Gast)


Lesenswert?

Karl K. schrieb:

> Das würde ich nicht unterschreiben. Feldadressierung in
> Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer
> verwendet werden, sondern die Adresse jedesmal explizit
> aus dem Index berechnet wird.

Das könnte der Compiler auch einfach mal besser optimieren, geht in C ja 
auch.

Jörg W. schrieb:

> und sie sollten sich als Hersteller
> einfach mal drehen, wenn sie mir das Zeug verkaufen wollen. Danach war
> aber nur Schweigen im Walde.

Natürlich. Ein nicht reproduzierbares Problem auf einem nicht offiziell 
unterstützten System zu finden, lohnt sich einfach nicht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Ein nicht reproduzierbares Problem auf einem nicht offiziell
> unterstützten System zu finden, lohnt sich einfach nicht.

Das Ganze läuft auf Windows 7, mit einer DirectX-Version, die höher als 
die vorausgesetzte ist. Dass das eine VM ist, braucht eine 
Anwendungssoftware erstmal nicht interessieren. Es würde mich nicht 
wundern, wenn der Bug genauso gut auch außerhalb einer VM auftreten 
kann. Was dann? Auch ignorieren, Kunde möge sich doch ein anderes System 
zulegen?

: Bearbeitet durch Moderator
von Nop (Gast)


Lesenswert?

Jörg W. schrieb:
> Dass das eine VM ist, braucht eine
> Anwendungssoftware erstmal nicht interessieren.

Sagst Du.

> Es würde mich nicht wundern, wenn der Bug genauso gut
> auch außerhalb einer VM auftreten kann.

Möglich ist vieles. Geld dafür auszugeben, das zu untersuchen, rechnet 
sich aber erst, wenn sich das bestätigt.

Bis dahin bist Du ein Kunde auf einem nicht offiziell unterstützten 
System, und solange Desktoplinux keine nennenswerte Verbreitung hat, ist 
es wirtschaftlicher, auf die paar Kunden einfach zu verzichten, bei 
denen es nicht läuft.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Bis dahin bist Du ein Kunde auf einem nicht offiziell unterstützten
> System

Wo steht das eigentlich, dass das nicht offiziell supportet wäre?

Irgendwo die Prerequisites eines Programmes zu dokumentieren, scheint 
unüblich zu sein – zumindest finde ich bei Altium nichts.

Ist aber auch egal, es zeigt ja nur, dass allein das Programmiersystem 
eben noch lange nicht darüber entscheidet, ob eine bestimmte damit 
verfasste Applikation am Ende wirklich portabel ist oder nicht.

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:

> Wo steht das eigentlich, dass das nicht offiziell supportet wäre?

Das sollte in den Systemanforderungen stehen, wo typischerweise neben 
der erforderlichen Mindesthardware auch irgendwas zu den unterstützten 
OS steht.

> Irgendwo die Prerequisites eines Programmes zu dokumentieren, scheint
> unüblich zu sein – zumindest finde ich bei Altium nichts.

Dann scheint Dein Google-Fu noch im Wochenend-Modus zu sein. Gib mal die 
Stichworte 'altium designer system requirements' bei Google ein. Ich 
sehe da nichts von "Windows in einer VM unter Linux".

von Karl K. (karl2go)


Lesenswert?

Jörg W. schrieb:
> Das Ganze läuft auf Windows 7, mit einer DirectX-Version, die höher als
> die vorausgesetzte ist.

Kann sein, dass AD hier auf einige Hardware DX Funktionen der 
Grafikkarte zugreifen will, die VMware so nicht bereitstellt. Oder die 
Windows zwar in Software emulieren kann, aber das Programm will halt 
Hardware.

Ich musste letztens auch lernen, dass DirectX11 vorhanden nicht heisst, 
dass ein Spiel was DirectX11 fordert damit auch läuft - wenn das Spiel 
auf einige DX Features der Grafikkarte zugreifen will, die diese halt 
nicht bietet weil zu alt. Pech.

Ob das zur Darstellung der Grafik notwendig wäre und nicht auch in 
Software emuliert genügen würde, ist dabei nichtmal die Frage. Wenn es 
so programmiert wurde, weil der Programmierer meint: Sollen sie halt ne 
bessere Grafikkarte kaufen - dann ist das so.

von Maxe (Gast)


Lesenswert?

Nop schrieb:
> und solange Desktoplinux keine nennenswerte Verbreitung hat, ist
> es wirtschaftlicher, auf die paar Kunden einfach zu verzichten, bei
> denen es nicht läuft.
Ist jetzt zwar etwas OT, aber man kann zur Beurteilung ob sich eine 
Linuxversion rechnet, nicht die Einnahmen durch Linuxkunden 1:1 mit den 
Entwicklungskosten vergleichen. Wenn ein Mitbewerber naemlich die Wahl 
anbietet, dann kann einen das letztlich auch Windowsnutzer kosten.

So Offtopic ist das eigentlich auch nicht, die unterstuetzten Platformen 
sind ja gerade die Staerke von FPC/Lazarus.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl K. schrieb:
> Kann sein, dass AD hier auf einige Hardware DX Funktionen der
> Grafikkarte zugreifen will,

Ist ja nicht so, dass da irgendwas falsch gezeichnet würde, sondern sie 
behaupten beim Start des PCB-Moduls (nur der braucht das überhaupt, aber 
das ist bei anderen PCB-Programmen wie Kicad oder Horizon nicht anders), 
dass sie nicht das nötige DirectX 10 hätten.

Nop schrieb:
> Dann scheint Dein Google-Fu noch im Wochenend-Modus zu sein. Gib mal die
> Stichworte 'altium designer system requirements' bei Google ein.

Ist aber K*cke, dass man das nur mit Google findet. Ich war über deren 
Webseite reingegangen und hatte es dort versucht zu finden.

> Ich
> sehe da nichts von "Windows in einer VM unter Linux".

Ich sehe auch nichts, was das explizit ausschließen würde. Alle dort 
aufgeführten Anforderungen werden von der VM erfüllt – selbst die aus 
den "Recommended", wenn man davon absieht, dass ich keine 3D-Maus habe 
(brauch' ich aber auch nicht, den 3D-View benutze ich nur, um mir das 
Resultat nochmal anzusehen, das geht auch mit einer herkömmlichen Maus 
gut genug).

Da man ihnen für eine doofe Demo-Version hinterher rennen muss, weil man 
ja schließlich vor Jahren schon einmal eine Demo bekommen hatte, kann 
ich jetzt auch nicht einfach ausprobieren, wie es sich in anderen 
Umgebungen verhalten würde (anderes Windows in gleicher VMware, oder 
andere VM – selbst in der VirtualBox sagt dxdiag, dass sie DirectX 11 
hat).

von Karl K. (karl2go)


Lesenswert?

Jörg W. schrieb:
> sondern sie
> behaupten beim Start des PCB-Moduls...
> dass sie nicht das nötige DirectX 10 hätten.

Ja, ging mir bei dem Spiel genauso: Systemanforderungen ausreichend, 
Downloader lädt problemlos runter, beim Start dann "DX Version wird 
nicht unterstützt". Irgendwo findet man dann, dass irgendwelche DX 
Features auf der Grafikkarte gefordert werden, die Windows halt auch 
nicht simulieren kann.

Ich behaupte jetzt nicht, dass das bei AD so ist, klingt aber ziemlich 
ähnlich.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl K. schrieb:
> Ich behaupte jetzt nicht, dass das bei AD so ist, klingt aber ziemlich
> ähnlich.

Kann sein. Wie gesagt, Gegentest kann ich nicht machen. Demoversion ist 
schon lange abgelaufen, ich bettele nicht nach einer weiteren.

Wenn das so speziell sein sollte, dann stehen die Chancen gut, dass es 
auch irgendwelche Grafikmodule ("Grafikkarte" trifft es ja oft genug 
nicht mehr) in freier Wildbahn gibt, die dann das entsprechende Feature 
auch nicht unterstützen. Dann wiederum würde es in die 
Systemanforderungen hin gehören.

von Zeno (Gast)


Lesenswert?

Jörg W. schrieb:
> Ist ja nicht so, dass da irgendwas falsch gezeichnet würde, sondern sie
> behaupten beim Start des PCB-Moduls (nur der braucht das überhaupt, aber
> das ist bei anderen PCB-Programmen wie Kicad oder Horizon nicht anders),
> dass sie nicht das nötige DirectX 10 hätten.

Hallo Jörg,

ich sehe das wie Karl, die Software will einfach eine passende Hardware 
haben und die findet sie in der virtuellen Umgebung nicht. Die 
Fehlermeldung muß ja nicht die wahre Fehlerursache aufzeigen. Ich kann 
mir durchaus vorstellen, das bei Grafikfehlern halt ne Fehlermeldung 
ausgegeben wird die ein falsches DirektX suggeriert.
Wir hatten mal ne Messsoftware für DOS gehabt, die wollte auch reale 
Hardware haben. Dort waren viele Zugriffe auf den Coprozessor und die 
Grafikkarte in Assembler programmiert mit direkten Zugriffen auf die 
Hardware. Deshalb lief diese Software auch nur auf echter Hardware. 
Selbst unter WinNT lief die Software nicht, da dieses System direkte 
Hardwarezugriffe nicht erlaubt.

von mh (Gast)


Lesenswert?

Zeno schrieb:
> ich sehe das wie Karl, die Software will einfach eine passende Hardware
> haben und die findet sie in der virtuellen Umgebung nicht.

Dann sollte die Software aber auch angeben, was sie genau an Hardware 
braucht.

Beitrag #6002586 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mh schrieb:
> Zeno schrieb:
>> ich sehe das wie Karl, die Software will einfach eine passende Hardware
>> haben und die findet sie in der virtuellen Umgebung nicht.
>
> Dann sollte die Software aber auch angeben, was sie genau an Hardware
> braucht.

Sehe ich auch so. Zumindest sollte es der Vertriebler, der einem die 
Software aufschwatzen möchte, dann mal so artikulieren, wenn man ihm die 
Fehlermeldung präsentiert.

Solange sie als Hardwarevoraussetzungen nur eine „hinreichend gute 
Grafik mit DirectX 10 oder höher“ angeben (und dann gerade mal zwei 
Beispiele nennen), dann müssen sie sich auch darauf festnageln lassen.

Mal ehrlich: so speziell ist das bisschen 3D-Zeichnerei nun im Jahr 
2019 ja auch nicht mehr, dass man als Hersteller da anfangen müsste, 
neben das dokumentierte API (nein, @W.S., DirectX ist keine 
Abstraktion, sondern ein API, wie OpenGL auch eins ist) zu greifen.

von Gegeg J. (Gast)


Lesenswert?

Fortsetzung meiner Liste der Programme die Pascal erfolgreich 
kommerziell einsetzen, mit CAO arbeite ich täglich
CAo Faktura
https://www.cao-faktura.de/

von Andreas W. (crazywolff)


Lesenswert?

Jörg W. schrieb:
> Solange sie als Hardwarevoraussetzungen nur eine „hinreichend gute
> Grafik mit DirectX 10 oder höher“ angeben (und dann gerade mal zwei
> Beispiele nennen), dann müssen sie sich auch darauf festnageln lassen.


Hi,

bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte 
braucht (alles mit DirectX), dann muss man das in der Maschine 
entsprechend konfigurieren. Macht man das nicht, dann gibt es die vorher 
beschriebenen Fehlermeldungen, da nur eine einfach 2D-Karte virtuell 
eingebunden wird:

https://docs.vmware.com/de/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-E03ED27D-E469-4115-80E1-435125D6168B.html

CU, Crazy

von Zeno (Gast)


Lesenswert?

Andreas W. schrieb:
> bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte
> braucht (alles mit DirectX), dann muss man das in der Maschine
> entsprechend konfigurieren.

Jein. Es gibt halt Software die die Hardware direkt abfragt und wenn da 
nichts Entsprechendes zurück kommt dann ist es halt Essig. Da kannst Du 
an der VM herumkonfigurieren soviel wie Du willst, es wird einfach nicht 
funktionieren.
Glaube mir, ich schrieb ja von einer Software die das so macht, und 
viele meiner Kunden wollten dann auch das ganze über eine virtuelle 
Maschine machen. Sie sind einfach nur kläglich gescheitert. Einige 
Kunden haben da nämlich wirklich ein massives Problem, weil an der 
Software noch eine Maschine im Wert von über 100k€ dran hängt. Die 
Software läuft auch nur bis Pentium IV (ab da haben sich die 
Coprozessorinstruktionen geändert) und als OS max. Win98SE. Wenn man das 
überhaupt auf einem modern Rechner installiert bekommt, dann scheitert 
es am Prozessor.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas W. schrieb:
> bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte
> braucht (alles mit DirectX), dann muss man das in der Maschine
> entsprechend konfigurieren.

Wenn man den Closedsource-Grafiktreiber des Hosts benutzt, schalten sie 
es automatisch an. Den Opensource-Treibern trauen sie nicht aufs Blaue 
übern Weg, da muss man explizit die Verantwortung selbst übernehmen.

Aber das habe ich natürlich gemacht, ansonsten würde ja auch AD16 nicht 
damit laufen (die offiziell DirectX 9 oder höher benötigen).

von (prx) A. K. (prx)


Lesenswert?

Egon D. schrieb:
> Das würde ich nicht unterschreiben. Feldadressierung in
> Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer
> verwendet werden, sondern die Adresse jedesmal explizit
> aus dem Index berechnet wird.

Gute Compiler können längst sowas wie
  for i := 1 to 100
      ... array[i] ...
auf der Zielmaschine selber effizient umsetzen. Beispielsweise über 
einen mitlaufenden Pointer, wenn sich das lohnt. Da kann es dann auch 
sein, das "i" komplett verschwindet und nur der Pointer bleibt.

Erfolgt das nicht, ist es heutzutage eine Schwäche des Compilers, nicht 
der Sprache. Die Zeiten, in denen man das von Hand optimiert, um den 
Compiler zu entlasten, sollten lange vorbei sein.

: Bearbeitet durch User
von Egon D. (Gast)


Lesenswert?

A. K. schrieb:

> Egon D. schrieb:
>> Das würde ich nicht unterschreiben. Feldadressierung
>> in Pascal ist i.d.R. langsam, weil keine mitlaufenden
>> Pointer verwendet werden, sondern die Adresse jedesmal
>> explizit aus dem Index berechnet wird.
>
> Gute Compiler können längst sowas wie
>   for i := 1 to 100
>       ... array[i] ...
> auf der Zielmaschine selber effizient umsetzen.
> Beispielsweise über einen mitlaufenden Pointer, wenn
> sich das lohnt. Da kann es dann auch sein, das "i"
> komplett verschwindet und nur der Pointer bleibt.

Du hast gerade einige sehr grundsätzliche Überlegungen
bestätigt, die ich mir zum Thema gemacht hatte.


> Erfolgt das nicht, ist es heutzutage eine Schwäche des
> Compilers, nicht der Sprache. Die Zeiten, in denen man
> das von Hand optimiert, um den Compiler zu entlasten,
> sollten lange vorbei sein.

Es geht weniger um Entlastung des Compilers, sondern mehr
um Klarheit im Ausdruck.

Allerdings habe ich wenig Bedürfnis, meine renitente
Außenseitermeinung hier zu diskutieren.

von Bernd K. (prof7bit)


Lesenswert?

Egon D. schrieb:
>> Erfolgt das nicht, ist es heutzutage eine Schwäche des
>> Compilers, nicht der Sprache. Die Zeiten, in denen man
>> das von Hand optimiert, um den Compiler zu entlasten,
>> sollten lange vorbei sein.
>
> Es geht weniger um Entlastung des Compilers, sondern mehr
> um Klarheit im Ausdruck.

In Deinem Post auf das Bezug genommen wurde geht es aber genau um das: 
Du hast unterstellt man wolle gerne von Hand mit Zeigern rumwurschteln 
um dem Compiler zu helfen weil es sonst angeblich Performanceprobleme 
gäbe. Und jetzt willst Du plötzlich das Gegenteil gesagt haben?

> Du hast gerade einige sehr grundsätzliche Überlegungen
> bestätigt, die ich mir zum Thema gemacht hatte.

Er hat sie widerlegt, nicht bestätigt! 180°-Wende?

: Bearbeitet durch User
von Scherzkeks (Gast)


Lesenswert?

https://www.golem.de/news/verschluesselung-gpg-muss-endlich-weg-2102-153820.html

hach ja....Pascal ist schon schön:-)
Viele neue Alternativen natürlich auch

von Scherzkeks (Gast)


Lesenswert?

https://news.ycombinator.com/item?id=22843140

auch hier sieht man das es lange noch nicht abgeschrieben ist.
NÉs unterstützt auch direkt Z80, AVR und STM32.
Der C64 Prozessor befindet sich in Vorbereitung bzw dessen Unterstützung

von Gerhard (Gast)


Lesenswert?

W.S. schrieb:
> Es wäre sehr wünschenswert, wenn es einen guten Pascal-Compiler für
> bare-metal-Anwendungen aktueller µC gäbe.

Nicht ganz das was du dir wünschst, aber immerhin bare-metal für den 
RasPi in FreePascal wenn ich das richtig interpretiere:
https://ultibo.org/faq/

Gerhard

von Scherzkeks (Gast)


Lesenswert?

Ja, gerade in dem Bereich wird überraschend wieder öfter Pascal genutzt
"Why not use a language like C, Python or PHP?
There are probably more programming languages available today than you 
could list on a single page, we decided on Free Pascal because it is 
powerful, flexible and offers the range of features needed to create 
Ultibo. If you’ve never tried Pascal give it a go, you might be 
surprised."

von Thomas (Gast)


Lesenswert?

Erklär doch mal bitte was Du mit Metaprogrammierung meinst. Vor einer 
Diskussion sollten Schlagworte klar definiert sein.

von Sheeva P. (sheevaplug)


Lesenswert?

Pandur S. schrieb:
> Wow, da geistern Zombies in der Daemmerung  herum. Und pruegeln sich mit
> Altsprachen wie C um die besten Plaetze in der Zombie Liga.

Tja... immerhin wird C immer noch aktiv für die meistverbreiteten 
Betriebssysteme genutzt, wie Windows oder Linux...

> Die moderne
> Welt will moderne Sprachen. Wie zB Python, wo ein Blank ueber sein oder
> nichtsein entscheidet. Ein Gross-Klein Tipp Fehler und eine neue
> Variable wird erzeugt, waehrend ich glaube es waere dieselbe.
> Schoene neue Debugwelt.

Entweder Du kannst coden, oder Du kannst es nicht. Nix neues insofern. 
;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Tobi P. schrieb:
> C für OS und embedded, Delphi für die Anwendungsseite ist imo eine super
> Kombi. Es gibt natürlich auch noch andere, keine Frage.

Klar, kann man nehmen, aber C++ für OS und Embedded und Python für UI 
ist auch fein. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Dr. Sommer schrieb:
> loeti2 schrieb:
>> Hust, IMHO ist das eine der größten Schwächen wo sich C++ hin entwickelt
>> hat.
>
> Wenn du Features als Schwäche siehst... viel andere
> Alleinstellungsmerkmale hat C++ nicht.

Doch, schon. Es ist extrem schnell, weit verbreitet, hervorragend 
dokumentiert und genauso ressourcensparend wie C, wenn man es will.

> Wo gibt es denn sonst "richtige" Metaprogrammierung mit statischer (!)
> Reflektion?

Naja, statische Reflektion... aber wenn Du Metaprogrammierung suchst, 
bist Du bei Python sicher an einer guten Adresse. ;-)

> test schrieb:
>> Braucht man so etwas zur normalen Anwendungsentwicklung?
>
> Man "braucht" nicht mehr als das was Brainfuck bietet. Aber hilfreich
> sind zusätzliche Hilfestellungen schon.

Was manche Fortschrittsfeinde gerne ignorieren, ist der ökonomische 
Aspekt von Softwareentwicklung. Und, um ehrlich zu sein: das ist 
zumindest im kommerziellen Bereich wesentlich wichtiger als ein 
kindisches Bestehen auf Typsicherheit und maximaler Performanz. ;-)

von aultasche (Gast)


Lesenswert?

noch so ein Pascal / delphi Programm:-)




                                12V
                                 |
                                 |
                         _   |/
                   PWM -|___|--|
                               |>
                                 |
                                 |
                                .-.
                                | | 1K
                                | |
                                '-' _
                                 |-|___|--------------- 0-6V
                                 |  20k  |
                                .-.      |
                                | |      | +
                                | | 1K  ###
                                '-'     ---
                                 |       |
                      GND o------o-------'
(created by AACircuit v1.28.7 beta 10/23/16 www.tech-chat.de)

von Turbo Pascal (Gast)


Lesenswert?

In Lazarus/Freepascal für anroid geschrieben
https://www.youtube.com/watch?v=gBS0AMrJ50s

von Turbo Pascal (Gast)


Lesenswert?


von Janosch K. (Gast)


Lesenswert?


von Janosch K. (Gast)


Lesenswert?

Delphi and Freepascal is different in more ways than one, but beyond 
language compatibility there is one aspect that is quintessential for 
them both; namely their role in the commercial sector. Where other 
languages, like C/C++ or (for example) JavaScript see a lot of 
open-source activity, especially with regards to Linux and Node.js – 
Delphi and Freepascal are predominantly used to write high-quality, 
commercial, closed source business applications. In other words, the 
vast majority of code produced by the millions of Object Pascal 
developers around the world – is never publicly committed to GitHub or 
BitBucket.

von W.S. (Gast)


Lesenswert?

Yalu X. schrieb:
> Wie in historischen C-Versionen (vor C99) kein boolean-Typ

Aus aktuellem Anlaß:

C hat auch jetzt keinen Boolean Typ. Das Einrichten eines 
Schlüsselwortes macht noch keinen Typ, sondern gibt dem Compiler 
lediglich die Möglichkeit, zusätzlichen Code zu erzeugen, der aus 42 
eben 1 macht. Mehr ist das Ganze nicht, der Boolean "Typ" ist bei C 
lediglich ein numerischer Untertyp, der nur von 0 bis 1 zählen kann, 
aber kein echter boolean Typ. Das hatte ich auch dem Jörg neulich zu 
erklären versucht, aber ich bin mir nicht sicher, daß er es verstanden 
hat.

Kurzum gesagt: Wenn es einen echten Boolean Typ gibt, dann sind alle 
Vereinbarungen a la 0 ist false, alles ungleich 0 ist true, komplett aus 
dem Verkehr zu ziehen, ebenso die Unterscheidung zwischen A&B versus 
A&&B, denn bei Vorhandensein eines boolean Typs ist die UND-Verknüpfung 
genau so wie auch die ODER-Verknüpfung typgerecht auf alle verknüpfbaren 
Typen anzuwenden, also logisch auf boolean Variablen und bitweise auf 
numerische Variablen.

Und ja, numerische Variablen haben gar keinen logischen Zustand, eben 
weil es Zahlen sind. Daß man mittels o.g. Regel (0=false, alles andere = 
true) die logischen Zustände auf die Zahlen 0 und 1 projiziert, ist nur 
eine erlassene Regel, ein 'ordre de mufti'.

Jörg meinte im Nebensatz, daß $0F und $F0 jeweils true seien, aber das 
ist C-Denkweise und hat mit Boolean nix zu tun. Also nochmal: Solange 
all diese genannten Regeln nicht offiziell aus C entfernt werden, gibt 
es in C keinen Boolean Typ.

W.S

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

W.S. schrieb:
> die UND-Verknüpfung genau so wie auch die ODER-Verknüpfung typgerecht
> auf alle verknüpfbaren Typen anzuwenden

"typgerecht" in Standard-Pascal heißt: ausschließlich auf Boolean.

Für etwas anderes sind diese Operatoren dort nicht definiert.

Dann stimme ich dir in folgender Aussage zu: "C hat keinen 'echten' 
Boolean-Typ, und Pascal hat keine bitweisen Operatoren."

Hilft einem natürlich in der Praxis rein gar nichts, denn die C-Variante 
funktioniert in der Praxis ausgezeichnet als reale Implementierung einer 
Wahrheitsentscheidung, und dass übliche Pascal-Implementierungen die 
Anwendungen von UND und ODER auf numerische Typen gestatten und dann als 
bitweise Operatoren betrachten, ist nun auch kein Geheimnis.

von W.S. (Gast)


Lesenswert?

Jörg W. schrieb:
> "typgerecht" in Standard-Pascal heißt: ausschließlich auf Boolean.
>
> Für etwas anderes sind diese Operatoren dort nicht definiert.

Du solltest wirklich mal wieder ein paar Programme mit sowas wie dem 
aktuellen Delphi oder mit Lazarus schreiben, dann würdest du dich für 
solche Worte wohin beißen und rot hinter den Ohren werden.

Nein, die besagten Operatoren tun ihren Dienst für alle dafür geeigneten 
Datentypen. Also für alle numerischen Typen, außer float und double, 
weil dort ja die Bits zweier Mantissen unterschiedliche Wertigkeiten 
haben, je nach der gerade vorliegenden Zahl. Das Ganze ist auch logisch: 
für eine Verknüpfung von boolean Variablen wird ein boolean Ergebnis 
erzeugt und für dasselbe mit zwei numerischen Variablen eben ein 
numerisches Ergebnis. Das alles hatte ich dir bereits vor einigen Tagen 
geschrieben, aber du hast nicht 'zugehört'.

Und rede dich nicht mit "Standard-Pascal" heraus. Das Ur-Pascal von 
Wirth war ein Anfang, aber mittlerweile sind die derzeitigen Fassungen 
von Embarcadero und Freepascal der Standard.

W.S.

von Maxe (Gast)


Lesenswert?

Jörg W. schrieb:
> und dass übliche Pascal-Implementierungen die
> Anwendungen von UND und ODER auf numerische Typen gestatten und dann als
> bitweise Operatoren betrachten, ist nun auch kein Geheimnis.

Man koennte es auch andersrum sehen, Pascal kennt nur bitweise 
Operationen. Bei Ein-Bit-Variablen (Boolean) ist die bitweise und 
logische Operation identisch.

von Nur_ein_Typ (Gast)


Lesenswert?

Bernd K. schrieb:
> Dr. Sommer schrieb:
>> Aber gut zu wissen
>> dass Delphi "Von Affen geschrieben" ist und Haarausfall bewirkt!
>
> Das mit den Affen ist eine böswillige Unterstellung und entspricht nicht
> der Wahrheit, aber daß es Haarausfall bewirkt kann als gesichert gelten,
> bei mir ist mittlerweile oben rum alles blank.

Mit C++ wäre das nicht passiert!

von Nur_ein_Typ (Gast)


Lesenswert?

Bernd K. schrieb:
> Joggel E. schrieb:
>> Ein Gross-Klein Tipp Fehler und eine neue
>> Variable wird erzeugt
>
> Diese Sprache von der Du sprichst heißt Lua und diesen kapitalen
> Designfehler gibts zum Glück in keiner anderen relevanten Sprache.

Jaein, Autovivikation gibt es auch in Python, Ruby, Perl und anderen, 
funktioniert dort aber nur bei Zuweisungen. Wer eine Variable zu lesen 
versucht, der vorher nie etwas zugewiesen wurde, bekommt seinen Unsinn 
(zurecht!) um die Ohren gehauen.

von Nur_ein_Typ (Gast)


Lesenswert?

Nop schrieb:
> Bernd K. schrieb:
>
>> Nein, wenn ich mich recht erinnere bekomme ich bei JS einen Fehler wenn
>> ich auf eine Variable zugreifen will die nicht existiert.
>
> Wenn Du einer Variable einen Wert zuweist, aber dabei deren
> Variablennamen verkehrt schreibst, wird die Variable nicht bloß
> automatisch neu angelegt anstatt einer Fehlermeldung, was an sich schon
> für viel Spaß beim Debuggen sorgt - sie wird obendrein als globale
> Variable angelegt, auch wenn Du das in einer Funktion tust.

Ist das in Lua so? 8-O

von Sludge Hammer (Gast)


Lesenswert?

EADS in einem Titel zu erwähnen, ist eine bodenlose Frechheit. Wer weiß, 
was sich hinter diesem Firmenkonstrukt verbirgt, weiß worum es geht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

W.S. schrieb:
> Du solltest wirklich mal wieder ein paar Programme mit sowas wie dem
> aktuellen Delphi oder mit Lazarus schreiben

Ich schrieb absichtlich von Standard-Pascal. Dass es bei Pascal offenbar 
nur Wildwuchs gibt (zwei Standards, an die sich keiner halten mag), ist 
ja nun eher kein positives Markenzeichen.

Maxe schrieb:
> Man koennte es auch andersrum sehen, Pascal kennt nur bitweise
> Operationen. Bei Ein-Bit-Variablen (Boolean) ist die bitweise und
> logische Operation identisch.

Wenn man in C in logischen Ausdrücken nur Ergebnisse von Vergleichen 
oder anderer "bool"-Ausdrücke (also 1-Bit-Ausdrücke) benutzt, braucht 
man auch nicht zwischen & und && zu unterscheiden, dann verhält es sich 
wie Pascal.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Sludge Hammer schrieb:
> EADS in einem Titel zu erwähnen, ist eine bodenlose Frechheit.

Das zu monieren, kommst du aber zwei Jahre zu spät. So alt ist die 
Threadleiche, die da wer ausgebuddelt hat.

von Nur_ein_Typ (Gast)


Lesenswert?

Guido B. schrieb:
> Jajaja, es geht schon, ich schrieb ja auch nur, dass es keinen
> Spaß macht. ;-)
>
> Der Zusatzaufwand ist schon groß, kein Wunder, dass Borland sein
> Projekt Kylix wieder eingestellt hat.

Das Problem war sicherlich nicht der Aufwand, sondern das Verhältnis vom 
Aufwand zum Ertrag. An sich war die Idee aber von vorneherein zum 
Scheitern verurteilt, um nicht zu sagen ein bisschen blöd: Kylix kam zu 
einer Zeit, als es unter Linux schon viele sehr leistungsfähige und 
kostenlose Sprachen und Entwicklungsumgebungen gab, und die 
Delphi-Entwickler waren meist ohnehin unter Windows sozialisiert.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> C hat auch jetzt keinen Boolean Typ.

Oh nein, nicht schon  wieder =8-[

> […] der Boolean "Typ" ist bei C lediglich ein numerischer Untertyp, […]

... und damit ein Typ, denn auch ein Untertyp ist ein Typ, wie der
zweite Teil des Kompositums erahnen lässt.

Übrigens wird auch in Pascal (zumindest in Free Pascal) ein boolean
genau wie in C intern als ein Byte mit einem Wertebereich von 0 bis 255
repräsentiert. Das (und die Folgen davon) zeigt dieses Beispiel hier:
1
var
2
  i: integer;
3
  pb: ^boolean;
4
  b1, b2: boolean;
5
6
begin
7
  i := 12345;
8
  pb := @i;
9
  b1 := pb^;
10
11
  i := 23456;
12
  pb := @i;
13
  b2 := pb^;
14
15
  writeln('b1 = ', b1);
16
  writeln('b2 = ', b2);
17
  if b1 = b2 then
18
    writeln('b1 und b2 sind gleich')
19
  else
20
    writeln('b1 und b2 sind verschieden')
21
end.

Ausgabe:
1
b1 = TRUE
2
b2 = TRUE
3
b1 und b2 sind verschieden

Häh?

Tatsächlich ist intern b1=57 und b2=160. Da beide Werte von 0
verschieden sind, werden sie – wie auch in C – als TRUE gewertet.

Der Unterschied zwischen boolean in Pascal und _Bool (aka bool) in C
besteht also einzig und allein darin, dass es in Pascal keine implizite
Konvertierung von boolean nach integer gibt. Aber obwohl ich dir das
schon im anderen Thread erklärt habe, verstehst du es offensichtlich
immer noch nicht (oder willst es nicht verstehen).


Im obigen Code ist die Art und Weise wie mit Zeigern umgegangen wird,
natürlich maximal böse, aber interessanterweise winkt das der Compiler
bei Verwendung der Defaultoptionen anstandslos durch. In C schmeißt
einem der GCC für diesen groben Unfug mindestens eine Warnung entgegen.

Wo ist denn die einst so vielgepriesene Typsicherheit von Pascal
geblieben?

von Klaus W. (mfgkw)


Lesenswert?

Ist aber doch viel lesbarer als in C!

von Maxe (Gast)


Lesenswert?

Yalu X. schrieb:
> Im obigen Code ist die Art und Weise wie mit Zeigern umgegangen wird,
> natürlich maximal böse, aber interessanterweise winkt das der Compiler
> bei Verwendung der Defaultoptionen anstandslos durch.
> [...]
> Wo ist denn die einst so vielgepriesene Typsicherheit von Pascal
> geblieben?

Durch die konstanten 12345 in deinem Beispiel könnte der Compiler zwar 
den ungültigen Wertebereich erkennen, aber bei praktischen 
Problemstellungen wäre das erst zur Laufzeit möglich. Was zusätzlichen 
Code, d.h. Performanceverlust bedeuten würde.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Maxe schrieb:
> Durch die konstanten 12345 in deinem Beispiel könnte der Compiler zwar
> den ungültigen Wertebereich erkennen

Ich meinte nicht den Wertebereich, sondern die Datentypen, mit denen
hier Schindluder getrieben wird, und zwar in den Zeilen 8 und 12:
1
  pb := @i;

Hier wird ein Zeiger auf eine Integer-Variable einer Variablen vom Typ
"Zeiger auf Boolean" zugewiesen. Konvertierungen zwischen verschiedenen
Zeigertypen sind i.Allg. gefährlich und meist auch wenig sinnvoll. Eine
Ausnahme stellt die Konvertierung eines Zeigers auf ein Objekt der
Klasse C in einen Zeiger auf die Basisklasse von C dar.

In Object Pascal wird defaultmäßig deswegen keine Warnung ausgegeben,
weil @i kein Zeiger auf Integer, sondern ein typloser Zeiger (ähnlich
einem void* in C) ist und ein typloser Zeiger implizit in jeden anderen
Zeigertyp konvertiert werden kann.

C würde sich ebenso verhalten, wenn der Adressoperator & implizit einen
Cast nach (void *) enthalten würde. Das ist aber aus gutem Grund nicht
der Fall. Warum es in Object Pascal so gemacht wird, kann ich beim
besten Willen nicht nachvollziehen, da eine Konvertierung zwischen
verschiedenen Zeigertypen, die in keiner Vererbungsrelation zueinander
stehen, in 99.99% einen Fehler darstellt.

von Maxe (Gast)


Lesenswert?

Yalu X. schrieb:
> Ich meinte nicht den Wertebereich, sondern die Datentypen, mit denen
> hier Schindluder getrieben wird, und zwar in den Zeilen 8 und 12:
>
>
1
>   pb := @i;
2
>
>
> Hier wird ein Zeiger auf eine Integer-Variable einer Variablen vom Typ
> "Zeiger auf Boolean" zugewiesen.

Da hast du Recht. Der Kompiler müsste das nicht so einfach durchgehen 
lassen. Es scheint bei Pascal die Grundannahme zu gelten, wer mit 
Pointern hantiert muss wissen was er tut.

> Konvertierungen zwischen verschiedenen
> Zeigertypen sind i.Allg. gefährlich und meist auch wenig sinnvoll. Eine
> Ausnahme stellt die Konvertierung eines Zeigers auf ein Objekt der
> Klasse C in einen Zeiger auf die Basisklasse von C dar.

Im modernen Pascal ist der Einsatz von Pointern von Haus aus recht 
selten, da ja Arrays, Strings und Klassen ohne solche auskommen. Für 
dynamische Daten verwendet man Klassen, braucht sich also auch nicht mit 
Pointern aufzuhalten. Bleiben hauptsächlich Operationen auf 
Binärdatenfelder. Und da wird es mit Typsicherheit schon schwierig.

von mh (Gast)


Lesenswert?

Jörg W. schrieb:
> Dann stimme ich dir in folgender Aussage zu: "C hat keinen 'echten'
> Boolean-Typ, und Pascal hat keine bitweisen Operatoren."

Kannst du bitte nochmal kurz zusammenfassen, warum C keinen 'echten' 
Boolean-Typ hat? Ich konnte aus eurer Diskussion kein Kriterium 
ableiten, das für einen echten Boolen-Typ notwendig ist.

von Egon D. (Gast)


Lesenswert?

Klaus W. schrieb:

> Ist aber doch viel lesbarer als in C!

Nein.
Yalu hat erfolgreich nachgewiesen, dass ein echter
Programmierer in jeder Sprache C programmieren kann.

Wenn man jedoch Pascal verwendet, um Pascal zu programmieren,
wird es für noch nicht radikalisierte tatsächlich lesbarer.
Vertrau mir.

(Deswegen verwenden echte Programmierer kein Pascal:
Sie möchten ihren Job ja auch nächste Woche noch haben... )

von Egon D. (Gast)


Lesenswert?

Maxe schrieb:

> Im modernen Pascal ist der Einsatz von Pointern von Haus
> aus recht selten,

Kommt aber schon vor.

Zugriffe über daten[i] sind fühlbar langsamer als über
pointer^, weil bei daten[i] die Adresse jedesmal aus
Startadresse des Feldes und Element-Index ausgerechnet
wird.
Deswegen beiße ich in der innersten Schleife gelegentlich
in den sauren Apfel und verwende einen Pointer.

von Walter T. (nicolas)


Lesenswert?

Ich habe zwar nichts beizutragen, aber ich verspreche mir morgen früh 
einen hohen Unterhaltungswert dieses Threads ab dieser Stelle.

von Egon D. (Gast)


Lesenswert?

Walter T. schrieb:

> Ich habe zwar nichts beizutragen, aber ich verspreche
> mir morgen früh einen hohen Unterhaltungswert dieses
> Threads ab dieser Stelle.

Unterhaltend ist es jetzt.
Morgen früh ist hier zugesperrt, weil jemand unter dem
Deckmantel der Meinungsfreiheit das Forum missbraucht,
um seine Meinung über Pascal und C zu äußern.

von Walter T. (nicolas)


Lesenswert?

Egon D. schrieb:
> Morgen früh ist hier zugesperrt, weil jemand unter dem
> Deckmantel der Meinungsfreiheit das Forum missbraucht,
> um seine Meinung über Pascal und C zu äußern.

Ein Satz zum Einrahmen. Keep up the good work! Bis morgen!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mh schrieb:
> Ich konnte aus eurer Diskussion kein Kriterium ableiten, das für einen
> echten Boolen-Typ notwendig ist.

Das musst du schon W.S. fragen, denn von ihm war die Aussage ja.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Egon D. schrieb:
> Yalu hat erfolgreich nachgewiesen, dass ein echter
> Programmierer in jeder Sprache C programmieren kann.

Naja, das sollte ja kein Beispiel für guten Programmierstil sein,
sondern W.S: zeigen, dass ein boolean in Pascal – abgesehen von den
nicht vorhandenen impliziten Typkonvertierungen – nichts anderes als das
bool in C ist.

Aber zum Thema "Pascal in C programmieren":

Als ich das erste Mal etwas in Turbo Pascal programmieren durfte bzw.
musste, war ich überrascht, wieviele C-Features da im Vergleich zum
"echten" Pascal (das ich im Studium gelernt hatte) zur Verfügung
standen. Plötzlich konnte man auch in Pascal Anwendungen für die reale
Welt schreiben (und nicht nur für Übungsaufgaben an der Uni). Turbo
Pascal war für mich deswegen fast so etwas wie C mit BEGIN und END.

Andererseits konnte man sich damit – ähnlich wie in C – auch gewaltig
ins Knie schießen, was ich aber in Kauf nahm (der Reset-Knopf am PC war
immer in greifbarer Nähe). Da ich aber nicht primär auf MS-DOS-PCs
arbeitete, ist es für mich mangels Verfügbarkeit bald wieder gestorben.

: Bearbeitet durch Moderator
von Yalu X. (yalu) (Moderator)


Lesenswert?

Maxe schrieb:
> Im modernen Pascal ist der Einsatz von Pointern von Haus aus recht
> selten,

Gerade deswegen würde es nicht schaden, wenn der Compiler da etwas
pingeliger wäre. Wenn man Zeiger nur selten braucht, braucht man
Zeigerkonvertierungen noch seltener, weswegen es dem Programmierer
durchaus zuzumuten wäre, solche Konvertierungen explizit zu machen.

Egon D. schrieb:
> Zugriffe über daten[i] sind fühlbar langsamer als über
> pointer^, weil bei daten[i] die Adresse jedesmal aus
> Startadresse des Feldes und Element-Index ausgerechnet
> wird.
> Deswegen beiße ich in der innersten Schleife gelegentlich
> in den sauren Apfel und verwende einen Pointer.

Siehst du, so etwas mache ich in C nicht, weil solche Dinge der Compiler
sehr gut selber optimieren kann.

Vielleicht ist ja am Ende doch C das bessere Pascal :)

von mh (Gast)


Lesenswert?

Jörg W. schrieb:
> mh schrieb:
>> Ich konnte aus eurer Diskussion kein Kriterium ableiten, das für einen
>> echten Boolen-Typ notwendig ist.
>
> Das musst du schon W.S. fragen, denn von ihm war die Aussage ja.

Ich hatte gehofft, du verstehst es, da du ihm (eingeschränkt) zugestimmt 
hast. Was W.S. zu irgend etwas das C/C++ betrifft sagt, ist mir relativ 
egal. Es war deine Zustimmtung, die es Interessant gemacht hat.

von Egon D. (Gast)


Lesenswert?

mh schrieb:

> Kannst du bitte nochmal kurz zusammenfassen, warum C
> keinen 'echten' Boolean-Typ hat?

Dafür gibt es zwei Gründe:

1. C hat ÜBERHAUPT keine echten Typen, das sind alles
   mehr so unverbindliche Empfehlungen. Daraus folgt
   zwanglos, dass es auch keinen echten Boolean-Typ
   geben kann.

2. Wenn man genau hinschaut, bemerkt der aufmerksame
   Betrachter ein meist totgeschwiegenes Detail: Es gibt
   in C ZWEI VERSCHIEDENE (informelle) "Typen" für
   boolsche Variablen: Ergebnisse boolscher Ausdrücke
   sind stets nur "0" oder "1" -- aber Steueranweisungen,
   die von einer logischen Bedingung abhängen, akzeptieren
   dagegen ganzzahlige "Bedingungen" mit der Zuordnung
   "gleich 0" für "falsch" und "ungleich 0" für "wahr".


> Ich konnte aus eurer Diskussion kein Kriterium
> ableiten, das für einen echten Boolen-Typ notwendig ist.

"Sachkunde ist einer lebhaften Diskussion nur abträglich."

C ist bedeutend besser als die üblichen Erklärungen und
Erläuterungen zur Programmiersprache C.

So könnte man ja einfach sagen, dass...
1. Vergleichs- und ähnliche Ausdrücke STETS nur "0" oder "1"
   als Ergebnis produziern, die somit als Wahrheitswerte
   aufzufassen sind,
2. bedingte Steueranweisungen (leider) die Schlamperei mit
   den ganzzahligen (statt booleschen) Bedingungen zulassen,
3. die Operatoren "||" und "&&" in der Regel bösartig irre-
   führend und falsch erklärt werden, weil es sich dabei
   keineswegs um abkürzende Auswertung boolescher Ausdrücke
   handelt, sondern um Auswertung erweiterter boolescher
   Ausdrücke.

Aber DAS ware ja für mathematisch vorgebildete Leser
leicht verständlich -- und geht also gar nicht...

Frei nach Peter Altenberg: "In jeder Diskussion liegt
etwas Tiefes, Wahres.
Nur ist das nicht das, worum es in der Diskussion geht."

von mh (Gast)


Lesenswert?

Egon D. schrieb:
> [...] blubber [...]

Dein Beitrag ist inhaltlich eng verwandt mit dem was W.S. gewöhnlich von 
sich gibt und legt nahe, dass du von C keine Ahnung hast. Es hat einen 
Grund, warum ich die Frage explizit an Jörg W. gerichtet habe. Seine 
Beiträge basieren auf echtem Wissen.

von Egon D. (Gast)


Lesenswert?

Yalu X. schrieb:

> Egon D. schrieb:
>> Yalu hat erfolgreich nachgewiesen, dass ein echter
>> Programmierer in jeder Sprache C programmieren kann.
>
> Naja, das sollte ja kein Beispiel für guten Programmierstil
> sein,

Das hätte mich bei Dir auch gewundert :)

(Ich wollte halt nur mal über das Stöckchen springen, das
Klaus hingehalten hat... nur um in Übung zu bleiben.)


> sondern W.S: zeigen, dass ein boolean in Pascal – abgesehen
> von den nicht vorhandenen impliziten Typkonvertierungen –
> nichts anderes als das bool in C ist.

Naja, über echte oder unechte Typen in C zu diskutieren ist
m.E. weitgehend nutzlos. Man müsste -- wenn überhaupt --
ändern, dass Ausdrücke wie "if (17)" vom Compiler akzeptiert
werden, aber das hieße, die heilige Kuh der Kompatibilität
zu schlachten.


> Aber zum Thema "Pascal in C programmieren":
>
> Als ich das erste Mal etwas in Turbo Pascal programmieren
> durfte bzw. musste, war ich überrascht, wieviele C-Features
> da im Vergleich zum "echten" Pascal (das ich im Studium
> gelernt hatte) zur Verfügung standen.

Naja, das Problem an Standard-Pascal ist m.E., dass N. Wirth
wie ein akademischer Prinzipienreiter agiert hat. Der Ansatz
war ja gut -- aber er hatte offenbar kein Interesse an einer
koordinierten Weiterentwicklung der Sprache, sondern hat sich
alle Nase lang eine neue ausgedacht. Pech für alle seine Fans...


> Plötzlich konnte man auch in Pascal Anwendungen für die
> reale Welt schreiben (und nicht nur für Übungsaufgaben an
> der Uni). Turbo Pascal war für mich deswegen fast so etwas
> wie C mit BEGIN und END.

Nach Z80-Assembler, ein wenig BASIC und einer frustrierenden
Begegnung mit C (auf P8000, unter "WEGA"!) war TurboPascal
auch mein nächster Schritt.

Ich sehe das heute sehr ambivalent. Einerseits war ich sehr
erpicht auf die "strukturierte Programmierung" -- ich wusste
ja vom Assembler her, wie beschissen es ohne ist.
Andererseits kann (konnte) man m.E. mit TurboPascal keine
Systemprogrammierung machen, ohne zu wilden Hacks zu greifen,
und das murksige MS-DOS als Unterbau... naja. Und so etwas
wie eine "tool chain" gab es da auch nicht, also bin ich
auf der Strecke weitgehend ahnungslos...

von Egon D. (Gast)


Lesenswert?

mh schrieb:

> Egon D. schrieb:
>> [...] blubber [...]
>
> Dein Beitrag ist inhaltlich eng verwandt mit dem was
> W.S. gewöhnlich von sich gibt und legt nahe, dass du
> von C keine Ahnung hast.

Dann sei doch so gut zeige mit Zitat und (Gegen-)Argument,
welche meiner Aussagen über C falsch sind.

Vielen Dank im Voraus.


> Es hat einen Grund, warum ich die Frage explizit an
> Jörg W. gerichtet habe.

Nun, ich kann nichts dafür, dass Du den Unterschied
zwischen privater E-Mail und öffentlichem Diskussions-
forum nicht kennst.

Vielleicht lernst Du es ja noch irgendwann...

von Egon D. (Gast)


Lesenswert?

Yalu X. schrieb:

> Egon D. schrieb:
>> Zugriffe über daten[i] sind fühlbar langsamer als über
>> pointer^, weil bei daten[i] die Adresse jedesmal aus
>> Startadresse des Feldes und Element-Index ausgerechnet
>> wird.
>> Deswegen beiße ich in der innersten Schleife gelegentlich
>> in den sauren Apfel und verwende einen Pointer.
>
> Siehst du, so etwas mache ich in C nicht, weil solche
> Dinge der Compiler sehr gut selber optimieren kann.

Ich verstehe offen gestanden auch nicht, warum der
FreePascal-Compiler es nicht optimieren kann. Bei "-O3"
ist er ziemlich clever, was arithmetische Sachen angeht;
der Output ist da m.E. nahe am Optimum.
Aber Feldzugriffe in einer for-Schleife werden prinzipiell
als "Index holen, mit Elementgröße malnehmen, Basisadresse
addieren" umgesetzt -- auch dann, innerhalb der Schleife
nicht weiter an der Laufvariablen herumgefummelt wird.

Verstehe nicht, warum der Compiler da keinen mitlaufenden
Pointer verwenden kann (bzw. verwendet).


> Vielleicht ist ja am Ende doch C das bessere Pascal :)

Definiere "besser" :)

Aber im Ernst: Ich sehe keinen Unterschied in der Sprache,
der die Beobachtung rechtfertigt. Das ist m.E. eine rein
technische Sache, also eine Frage der konkreten Implemen-
tierung des Compilers.
Feldzugriffe über den Index in for-Schleifen sind sowieso
redundant. "foreach" wäre häufig viel praktischer...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Egon D. schrieb:
> Man müsste -- wenn überhaupt --
> ändern, dass Ausdrücke wie "if (17)" vom Compiler akzeptiert
> werden, aber das hieße, die heilige Kuh der Kompatibilität
> zu schlachten.

Das wäre vermutlich dann das, was W.S. unter "echtem Boolschen Typen" 
verstehen würde.

Im Prinzip ließe sich das sogar im C-Standard unterbringen: man könnte, 
nachdem es _Bool ja nun schon mehr als 20 Jahre lang gibt, auch 
festlegen, dass die Steuerausdrücke nach if, while etc. von ebendiesem 
Typ sind. Da C ja trotzdem auch implizite Typumwandlungen kennt, wäre 
ein "if (42)" dann mit einer impliziten Typumwandlung von "int" nach 
"_Bool" verbunden, für die der Compiler natürlich freizügig eine Warnung 
erzeugen kann.

Die Frage ist nur: außer, dass W.S. das dann vielleicht als "echten 
Boolschen Typen" akzeptieren könnte, welches reale Problem wäre damit 
gelöst? Also, warum genau sollte man solche Klimmzüge machen? Es ist ja 
nun nicht so, dass die derzeitige Lösung eine fundamentale Schwachstelle 
der C-Sprachdefinition wäre, die vielleicht zu massenhaft 
Sicherheitsproblemen führt oder dergleichen. Außer, dass es dann besser 
der "reinen Lehre" genügt, wäre rein gar nichts damit gewonnen.

Daher wird sich wohl keiner die Mühe machen, sowas in den Standard 
überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich 
da eher mit real existierenden Problemen herum und einer Lösung dafür.

von Nop (Gast)


Lesenswert?

Egon D. schrieb:

> 1. C hat ÜBERHAUPT keine echten Typen, das sind alles
>    mehr so unverbindliche Empfehlungen. Daraus folgt
>    zwanglos, dass es auch keinen echten Boolean-Typ
>    geben kann.

Doch, und das bemerkst Du spätestens dann, wenn der Compiler Dir wegen 
pointer aliasing auf verschiedene Typen Dein Programm wegoptimiert.

von mh (Gast)


Lesenswert?

Jörg W. schrieb:
> Daher wird sich wohl keiner die Mühe machen, sowas in den Standard
> überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich
> da eher mit real existierenden Problemen herum und einer Lösung dafür.

Die Leute aus der Compiler- und Tooling-Ecke würden sich sicher über die 
zusätliche Arbeit freuen, die diese Änderung verursachen würde. Dieses 
"Problem" hat anscheinend auch niemand als wichtig genug (oder als 
Problen überhaupt) eingestuft, um eine entsprechende Warnung in den gcc 
einzubauen.

von W.S. (Gast)


Lesenswert?

Jörg W. schrieb:
> Die Frage ist nur: außer, dass W.S. das dann vielleicht als "echten
> Boolschen Typen" akzeptieren könnte,

Ach nö, so nicht, mein Lieber. Du hast mit Behauptungen angefangen (wie 
z.B. daß es in Pascal keine oder nur rudimentäre boolsche Algebra gäbe 
oder daß C seit Jahren eine echten boolean Typ hätte), die allesamt 
sachlich unrichtig sind und ich habe versucht, es dir zu erklären, so 
daß du in die Lage kommst, das Ganze zu verstehen. Es ist mein Versuch, 
dich aus dem Brunnen zu fischen, in den du hineingefallen bist. Ich 
selber komme auch so mit C klar und habe für mich keinen Bedarf an 
blöden Bemerkungen anderer, die zwar ebenfalls in denselben Brunnen 
gefallen sind wie du, es aber noch nicht gemerkt haben. Was mich 
allerdings stört, ist der Gedanke, daß wenn andere Leute hier mitlesen 
und von euch völlig falsche Dinge gesagt bekommen, sie damit etwas 
Falsches lernen.

Um das Ganze mal abzukürzen: In C sieht es so aus, daß eigentlich alles 
außer Gleitkomma in den numerischen Bereich der Integerzahlen projiziert 
wird. Boolean wird zu einem Integer des Bereiches 0..1, Textzeichen 
werden ebenfalls zu Integers mit dem Bereich 0..255 oder -128..+127 je 
nachdem, ob man ein Textzeichen nun als vorzeichenbehaftet ansehen will 
oder nicht, na und so weiter.

Ich stelle mir grad vor, wie Jörg ein großes 'A' auf sein Blatt Papier 
mit dem Bleistift schreibt und dann darüber grübelt, woran man dessen 
Vorzeichen erkennen kann.

Apropos Textzeichen: Bitte mal das Alphabet aufsagen. So, wie wir es 
gelernt haben, beginnt es mit A B C und so weiter.  Das heißt, wenn wir 
uns die Ordnungszahl des A in unserem Alphabet näher anschauen, stellen 
wir fest, daß das A die Nummer 1 ist, denn das Alphabet beginnt mit 
damit. Wenn wir uns hingegen das ASCII-Alphabet anschauen, dann hat dort 
das A die Ordnungszahl 65 (wenn ich mich nicht grad verzählt habe) und 
wenn wir die Alphabete anderer Kulturkreise anschauen, wo die 
Textzeichen eine ganze Silbe oder gar ein ganzes Wort darstellen, dann 
erkennen wir, daß Textzeichen eben keine Integers sind, sondern deren 
Ordnungszahl sich nur aus dem gerade verwendeten Alphabet ergibt. 
Textzeichen sind keine Rechengrößen und Vergleiche zwischen Textzeichen 
können deshalb nur auf Gleichheit oder Ungleichheit gemacht werden. 
Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner) 
funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet. Man 
kann zwar damit zurechtkommen, daß ein char in C im wesentlichen ein 
numerischer Typ ist (mit oder ohne Vorzeichen), aber daß das ganze 
Konstrukt an der Realität vorbei geht und sachlich falsch ist, sollte 
man sehen können.


Natürlich kann man alles zusammen in den Topf werfen, man muß allerdings 
mit den Folgen leben, die es nach sich zieht: Dann muß man hinterher 
sich Regeln einfallen lassen, um die zusammengerührten Dinge wieder 
auseinander zu kriegen. Und so muß man sich in C z.B. zwei Stück UND 
einfallen lassen, eines für das bitweise Und-Verknüpfen von Integers und 
ein anderes für die logische Verknüpfung. Und so weiter. Jedes "if 
(A)..." ist eigentlich ein "if (A!=0)..." - aber das so zu schreiben 
wäre dem durchschnittlichen C Programmierer ja zu buchstabenreich aber 
es wäre eine der Vorarbeiten, um einen Boolean Typ in C einzuführen. Und 
mehr als Faulheit vermag ich in solcher Schreibweise nicht zu sehen. 
Benutze solches Geschreibe in C ja selber. Aber im Gegensatz zu euch 
mache ich mir dabei nix vor.

W.S.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mh schrieb:
> Jörg W. schrieb:
>> Daher wird sich wohl keiner die Mühe machen, sowas in den Standard
>> überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich
>> da eher mit real existierenden Problemen herum und einer Lösung dafür.
>
> Die Leute aus der Compiler- und Tooling-Ecke würden sich sicher über die
> zusätliche Arbeit freuen, die diese Änderung verursachen würde.

Die sitzen eh (zumindest zu einem Teil) mit in der WG14. Vermutlich ist 
dort das Problem aber gar nicht so groß. Die Einführung eines _Bool (der 
nur die Werte false und true hat) haben sie ja auch mitgetragen.

W.S. schrieb:
> Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner)
> funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet.

Wobei das lateinische Alphabet (als Basis-Zeichensatz) letztlich in 
jeder Sprache, welche diese Zeichen nutzt, die Ordnung von 'A' nach 'Z' 
bzw. 'a' nach 'z' hat. Außerdem gibt es noch eine Ordnung von '0' bis 
'9'. Das sind die einzigen implizierten Bedingungen für Textzeichen im 
C-Standard. Insbesondere hatte man damit ja auf EBCDIC Rücksicht zu 
nehmen, bei dem bspw. die Buchstaben nicht lückenlos aufeinander folgen.

Andere Alphabete lassen sich auf diese Weise logischerweise nicht 
abbilden und werden auch nicht abgebildet. Die Frage, ob ein 'Л' nun 
also kleiner oder größer als ein 'L' ist, ist von diesem Standard nicht 
definiert worden, und du hast ja dargelegt, dass eine solche Definition 
auch keinen Sinn hätte.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jörg W. schrieb:
> Wobei das lateinische Alphabet (als Basis-Zeichensatz) letztlich in
> jeder Sprache, welche diese Zeichen nutzt, die Ordnung von 'A' nach 'Z'
> bzw. 'a' nach 'z' hat. Außerdem gibt es noch eine Ordnung von '0' bis
> '9'. Das sind die einzigen implizierten Bedingungen für Textzeichen im
> C-Standard. Insbesondere hatte man damit ja auf EBCDIC Rücksicht zu
> nehmen, bei dem bspw. die Buchstaben nicht lückenlos aufeinander folgen.

Das ist auch in Pascal so und sogar im ISO-Standard festgeschrieben. Und
wenn W.S. behauptet, in Pascal sei für Textzeichen kein Vergleich auf
größer oder kleiner möglich

W.S. schrieb:
> Textzeichen sind keine Rechengrößen und Vergleiche zwischen Textzeichen
> können deshalb nur auf Gleichheit oder Ungleichheit gemacht werden.
> Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner)
> funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet.

dann zeigt er damit nur, dass er nicht nur von C, sondern auch von
Pascal keine Ahnung hat :)

Mich erinnert W.S. ein wenig an Moby, der immer als der ganz große
AVR-Assemblergott dastehen wollte, bis sich irgendwann herausstellte,
dass er nicht einmal den EOR-Befehl kannte.

von Egon D. (Gast)


Lesenswert?

Jörg W. schrieb:

> Egon D. schrieb:
>> Man müsste -- wenn überhaupt -- ändern, dass
>> Ausdrücke wie "if (17)" vom Compiler akzeptiert
>> werden, aber das hieße, die heilige Kuh der
>> Kompatibilität zu schlachten.
>
> Das wäre vermutlich dann das, was W.S. unter "echtem
> Boolschen Typen" verstehen würde.

Vermutlich -- und ich kann dieser Logik durchaus folgen.


> Im Prinzip ließe sich das sogar im C-Standard unterbringen:
> man könnte, nachdem es _Bool ja nun schon mehr als 20 Jahre
> lang gibt, auch festlegen, dass die Steuerausdrücke nach
> if, while etc. von ebendiesem Typ sind. Da C ja trotzdem
> auch implizite Typumwandlungen kennt, wäre ein "if (42)"
> dann mit einer impliziten Typumwandlung von "int" nach
> "_Bool" verbunden, für die der Compiler natürlich freizügig
> eine Warnung erzeugen kann.

Mal schauen... vielleicht erlebe ich das noch. Wer warten
kann, erlebt fast alles. Bei der Pointerarithmetik in Pascal
hat es ja schon funktioniert...


> Die Frage ist nur: außer, dass W.S. das dann vielleicht als
> "echten Boolschen Typen" akzeptieren könnte, welches reale
> Problem wäre damit gelöst? Also, warum genau sollte man
> solche Klimmzüge machen?

Naja, wie so oft ist der Sprachstandard klüger als viele der
Leute, die ihn anwenden oder erklären (Anwesende natürlich
ausgenommen). Der Standard VERBIETET es ja nicht, die korrekte
Langform zu schreiben -- nur übertrumpfen sich die C-Tutorien
gegenseitig mit Hinweisen "'xyz' kann auch kürzer als 'q'
geschrieben werden", "'abc' kann an dieser Stelle weggelassen
werden", statt sich erstmal auf die Langform zu beschränken,
die immer stimmt und immer funktioniert.

Die derart zur Schlampigkeit erzogenen Nachwuchsprogrammierer
werden dann in der zweiten Runde mit MISRA geelendet, um
ihnen wenigstens eine minimale Korrektheit im Ausdruck
einzubläuen.

Könnte man auch irgendwie einfacher haben...

von Egon D. (Gast)


Lesenswert?

Yalu X. schrieb:

> Und wenn W.S. behauptet, in Pascal sei für Textzeichen
> kein Vergleich auf größer oder kleiner möglich [...]

Leider hat er das gar nicht behauptet.

Seine Aussagen sind:
1. Buchstaben sind keine Zahlen.
2. Eine Ordnungsrelation in der Menge der Buchstaben
   gilt immer nur in einem m.o.w. willkürlichen Alphabet.

Beide Aussagen sind richtig -- also in der wirklichen
Welt, meine ich.

In C ist (war) die erste Aussage "selbstverständlich"
falsch; wer eine kleine Ganzzahl vereinbaren wollte,
verwendete "char". Muss man nicht verstehen.


> Mich erinnert W.S. ein wenig an Moby, der immer als
> der ganz große AVR-Assemblergott dastehen wollte, [...]

Mich nicht.

Mich erinnern im Gegenteil die Programmierer, die es
empört von sich weisen, als Ingenieure angesehen zu werden,
weil sie ja freischaffende Heroen der Mathematik-Kunst
seien, an die Halbstarken auf dem Schulhof, die zwar
markige Sprüche klopfen können, aber von Tuten und Blasen
keine Ahnung haben: C verwendet zwar mathematische Begriffe,
tut dies aber auf eine Weise, die jedem sorgfältigen
mathematisch geschulten Geist die Zornesröte ins Gesicht
treibt -- und wenn man diese Vergewaltigung von Begriffen
kritisiert, wird man als dumm und ignorant angepflaumt,
weil man "ja überhaupt keine Ahnung von C" hat.

Liebe Leute: Das Problem ist nicht C. C ist gar nicht SO
schlecht, wie es von seinen Kritikern häufig gemacht wird.

Das Problem sind die C-Missionare.

von Egon D. (Gast)


Lesenswert?

W.S. schrieb:

> Ach nö, so nicht, mein Lieber. Du hast mit Behauptungen
> angefangen (wie z.B. daß es in Pascal keine oder nur
> rudimentäre boolsche Algebra gäbe

Hat er nicht.

Der Kern seiner Aussage war nach meinem Verständnis:
"WENN man kritisiert, dass in C Wahrheitswerte (die
eigentlich 'boolesch' sein müssten) durch kleine
Ganzzahlen (Bereich 0..1) dargestellt werden, DANN
müsste man eigentlich auch kritisieren, dass man in
Pascal boolesche Operationen auf Ganzzahlen anwenden
kann. Beides ist eine Verletzung des Typsystems."

Die Aussage ist m.E. richtig.

In keiner mir bekannten Arithmetik der Welt ist ein
bitweises XOR (oder AND oder... usw.) definiert.
Das sind Operationen der BOOLESCHEN Algebra -- keine
arithmetischen Operationen über Zahlen!

Für die mathematisch korrekte Implementierung von
bitweisen booleschen Verknüpfungen müsste es einen
Bitvektortyp geben -- den es in Pascal aber m.W.
nicht gibt. Pech für die Kuh Elsa.

Die Kritik ist korrekt -- und für mich überraschend;
sie zeigt, wie sehr man sich an bestimmte Dinge gewöhnt.
Balken, Splitter, und so...


> oder daß C seit Jahren eine echten boolean Typ
> hätte),

Das ist unfair.
Du hast Dich, soweit ich sehe, darüber ausgeschwiegen,
was Du unter einem echten booleschen Typ verstehen
willst -- im Gegensatz zu einem unechten.

Auf meinen Deutungsvorschlag, dass es inkonsistent ist,
wenn "boolesche" FUNKTIONSWERTE einen anderen Wertebereich
haben wie "boolesche" ARGUMENTE, ist Jörg ja eingegangen
und hat dem implizit zugestimmt.

Das ist auch die einzige Sicht, die für mich Sinn gibt.


> Und so muß man sich in C z.B. zwei Stück UND einfallen
> lassen, eines für das bitweise Und-Verknüpfen von
> Integers und ein anderes für die logische Verknüpfung.

Immer wieder gern genommen... :)

Stimmt aber so nicht.
Hat Jörg auch schon erklärt: Wenn man immer korrekte,
vollständige boolesche Ausdrücke baut, erhält man im
Prinzip auch mit den Bit-Operatoren korrekte Resultate --
wenn das Problem mit der Auswertungsreihenfolge nicht wäre.

Letzteres lösen "&&" und "||"; die Beschränkung auf 0/1
ist nur willkommener, aber verzichtbarer Nebeneffekt.

von Peter K. (os2fan2)


Lesenswert?

der Standard IST Turbo Pascal / Delphi!!
Das hat mit Wildwuchs nichts zu tun.
Alles richtet sich daran aus, und es spricht nichts dagegen, wenn 
Freepascal noch Erweiterungen anbietet, dennoch ist es kompatibel zu 
Turbo Pascal/Delphi
Die, die immer wegen Standards rumheulen, Linux wäre tod, mit diesem 
Argument.
Da klammert sich auch niemand an Standards fest

Dieses Argument von Pascal Standards nervt nur und ist immer wieder 
schlicht falsch.
Jeder der mit Pascal arbeitet weiß das


> Ich schrieb absichtlich von Standard-Pascal. Dass es bei Pascal offenbar
> nur Wildwuchs gibt (zwei Standards, an die sich keiner halten mag), ist
> ja nun eher kein positives Markenzeichen.
>

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:
> der Standard IST Turbo Pascal / Delphi!!

Da fehlt noch mindestens ein Ausrufezeichen. :-))

Das ist dann in etwa der Zustand, den C vor 1989 hatte, als sich alles 
nach den Beschreibungen von K&R ausgerichtet hat.

Kann man gut finden, muss man nicht.

> Die, die immer wegen Standards rumheulen, Linux wäre tod, mit diesem
> Argument.
> Da klammert sich auch niemand an Standards fest

Linux hält sich durchaus an den zugehörigen Standard (IEEE 1003.2), 
andere unixoide Systeme auch, und der entsprechende Standard wird auch 
kontinuierlich weiter entwickelt.

> Dieses Argument von Pascal Standards nervt nur und ist immer wieder
> schlicht falsch.

Also erfreuen wir uns dann daran, dass das Kurzschlussverhalten 
logischer Operatoren per Compileroption zu- oder abwählbar ist.

Schrieb da oben jemand was wegen einer heiligen Kuh der 
Rückwärtskompatibilität? :-}

Mir ist echt nicht klar, wofür zum Geier™ man logische Operatoren ohne 
Kurzschlussverhalten brauchen würde. Das war zu den Zeiten, als ich noch 
recht aktiv Pascal programmiert habe (und das war damals eben nicht 
nur Turbo-Pascal), immer völlig nervig, dass man if ... then if ... 
then schreiben musste, wenn man sicherstellen wollte, dass der zweite 
Ausdruck auch wirklich erst dann bewertet worden ist, wenn der erste 
erfolgreich war.

von Peter K. (os2fan2)


Lesenswert?

tatsächlich finde ich es schade, das der Thread leider durch sinnlose 
Diskussionen kaputtgemacht wird und anstatt das der Mod diese Diskussion 
beendet oder Beiträge löscht, sich sogar noch daran beteiligt:-(
Naja, immerhin hat es der Thread einige Zeit Geschafft seinen Sinn zu 
erfüllen.


Ich merke mir ledier nicht alle Quellen..aber das Arguemtn mit den 
fehlenden Standards bei Linux ist stichhaltig, genauso wie Linux selber 
sagte, das Linux noch lange nicht für den Einsatz auf dem Desktop taugt 
für die Normalanwender weil es viel zu Frickelig ist.

Wenn das selbst der Erfinder von Linux sagt, verstehe ich nicht weshalb 
viele diese Aussage immer so aufregt.
Alles braucht nun mal seine Zeit

Und genau wie C ist auch Pascal in den Jahren gereift und besser 
geworden.
Und mit Turbo Pascal 7 oder Freepascal und Delphi gibt es eine super 
Oberfläche .
Und klar kann man auch C  oder C++ nehmen.
Nur geht es darum in diesem Thread überhaupt nicht sondern es soll 
lediglich aufzeigen, das Pascal erheblich aktiver sit als viele denken
Und diese Aussage ist halt auch interessant, wie gesagt.

"Delphi and Freepascal is different in more ways than one, but beyond
language compatibility there is one aspect that is quintessential for
them both; namely their role in the commercial sector. Where other
languages, like C/C++ or (for example) JavaScript see a lot of
open-source activity, especially with regards to Linux and Node.js –
Delphi and Freepascal are predominantly used to write high-quality,
commercial, closed source business applications. In other words, the
vast majority of code produced by the millions of Object Pascal
developers around the world – is never publicly committed to GitHub or
BitBucket."

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:
> Nur geht es darum in diesem Thread überhaupt nicht sondern es soll
> lediglich aufzeigen, das Pascal erheblich aktiver sit als viele denken

Naja, darum ging es mal vor zwei Jahren. Damit auch niemand denkt, es 
sei Ruhe rein gekommen, muss aber immer mal wieder jemand den Thread mit 
neuen Beweisen hervor holen. (Vermutlich sind das nicht die Leute, die 
Pascal aktiv und gern benutzen, die werden besseres zu tun haben.)

Das Argument, Pascal-Programme wären nur wenig im Opensource-Bereich zu 
sehen und mehr im kommerziellen Bereich unterwegs, wurde ja nun auch 
schon mehr als einmal genannt. Es ignoriert natürlich, dass auch die 
Masse an anderer Software ganz sicher kein Opensource ist, das ist also 
keineswegs ein Alleinstellungsmerkmal von Pascal-Programmen.

von Peter K. (os2fan2)


Lesenswert?

ist sollte ein fortlaufender Thread sein, der immer ergänzt wird.
Aber das wird gerade zunichte gemacht

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Peter K. schrieb:
> ist sollte ein fortlaufender Thread sein, der immer ergänzt wird

Wofür denn aber eigentlich? Ego-boosting? "Ich habe doch die richtige 
Programmiersprache gewählt?" Ein wirklicher Sinn dahinter ist mir nicht 
klar. Es gibt doch auch für andere Programmiersprachen keine Threads 
"Projekt XXX benutzt YYY".

Keiner zweifelt an, dass Pascal (in der einen oder anderen Form) 
Verwendung findet. Wenn es das nicht wäre, wären die entsprechenden 
Compiler-/IDE-Projekte schon längst eingeschlafen. Dass es nicht noch 
stärker Verwendung findet, hat diverse Gründe, aber das wird sich auch 
durch einen solchen Tread sicher kaum verbessern.

: Bearbeitet durch Moderator
von Peter K. (os2fan2)


Lesenswert?

Irgendwie hat dich die Sinnfrage gar nicht zu interessieren, darum geht 
es in diesem Thread schlicht überhaupt nicht
Es geht auch nicht darum etwas zu verbessern!!!
Wenn du wissen willst, welchen Sinn er hat, dann lies den Eingangspost!!
Ein Forum dient unter Anderem dem Austausch, der Informations und 
Meinungsbildung etc.
Das kann Abhängig vom Forenthema sein

Aber ich sehe schon wohin das hier wieder führt, und für diese Art der 
Moderation ist das Forum bzw. die Moderatoren hier ja bekannt

Schwachsinnige Posts wie diese
Beitrag "Was ist das?"
sind in diesem Forum offenbar besser aufgehoben

Und das permanente Störer wie der Cyblord nicht gesperrt werden, obwohl 
es mehrere Threads mit der Diskussion warum er nicht gesperrt wird seit 
2014 gibt, erschließt sich mir auch nicht, zeigt aber sehr gut, was in 
diesem Forum schief läuft

Ich bin hier raus und werde diesen Thread nicht mehr weiterführen.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

Egon D. schrieb:
> Yalu X. schrieb:
>
>> Und wenn W.S. behauptet, in Pascal sei für Textzeichen
>> kein Vergleich auf größer oder kleiner möglich [...]
>
> Leider hat er das gar nicht behauptet.
>
> Seine Aussagen sind:
> 1. Buchstaben sind keine Zahlen.
> 2. Eine Ordnungsrelation in der Menge der Buchstaben
>    gilt immer nur in einem m.o.w. willkürlichen Alphabet.
>
> Beide Aussagen sind richtig -- also in der wirklichen
> Welt, meine ich.

Ok, vielleicht habe ich in seine Aussagen zuviel hineininterpretiert. Da
es in dem Thread aber um Pascal geht und W.S. in allen seinen Beiträgen
bestrebt ist, die Vorzüge von Pascal gegenüber C herauszustellen, bin
ich davon ausgegangen, dass auch seine Ausführungen zu Alphabeten und
Ordnungszahlen diesem Zweck dienen.

In diesem Kontext habe ich seine Aussagen wie folgt interpretiert:

W.S. schrieb:
> dann erkennen wir, daß Textzeichen eben keine Integers sind,

Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal
nicht. Deswegen ist C schlecht und Pascal gut.

Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache.

> Textzeichen sind keine Rechengrößen

Interpretation: In C sind auf char Rechenoperationen erlaubt, in Pascal
nicht. Deswegen ist C schlecht und Pascal gut.

Das ist nur teilweise richtig, denn auch in Pascal kann mit char
gerechnet werden. wenn auch nur sehr eingeschränkt. Mit inc ist nämlich
eine Addition mit einem Integer definiert. Beispiele: inc('A') -> 'B',
inc('A', 4) -> 'E'. Man muss also nicht chr(ord('A')+4) schreiben, wie
es W.S. wohl vorschwebt.

> und Vergleiche zwischen Textzeichen können deshalb nur auf Gleichheit
> oder Ungleichheit gemacht werden. Jegliche weiterführenden
> mathematischen Vergleiche (größer oder kleiner) funktionieren nur mit
> der Ordnungszahl in einem bestimmten Alphabet.

Interpretation: In C sind sind > und < auf char erlaubt, in Pascal
nicht. Deswegen ist C schlecht und Pascal gut.

Das stimmt definitiv nicht, denn auch in Pascal ist das erlaubt.
Beispiele 'A'>'B' -> false, 'A'<'B' -> true. Man muss also nicht
ord('A')<ord('B') schreiben, wie es W.S. wohl vorschwebt.

Meine Vermutung, dass es W.S. mit den vorangegangenen Aussagen
tatsächlich um den Vergleich Pascal<->C ging, wird durch den folgenden
Nachsatz erhärtet:

> Man kann zwar damit zurechtkommen, daß ein char in C im wesentlichen
> ein numerischer Typ ist (mit oder ohne Vorzeichen), aber daß das ganze
> Konstrukt an der Realität vorbei geht und sachlich falsch ist, sollte
> man sehen können.

Wie ich schon mehrfach schrieb, liegen Pascal bzw. Object Pascal und C
bzw. C++ in ihrer jeweiligen heutigen Ausprägung gar nicht mehr so weit
auseinander.

von W.S. (Gast)


Lesenswert?

Yalu X. schrieb:
> Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal
> nicht. Deswegen ist C schlecht und Pascal gut.
>
> Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache.

Tja, der erste Satz ist von mir, der zweite Satz ist von dir.
Das macht den Unterschied.

W.S.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> Yalu X. schrieb:
>> Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal
>> nicht. Deswegen ist C schlecht und Pascal gut.
>>
>> Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache.
>
> Tja, der erste Satz ist von mir, der zweite Satz ist von dir.

Ach so, du behauptest also gar nicht, dass Pascal "besser" (in welcher
Hinsicht auch immer) als C sei?

Super, dann war das wohl ein Missverständnis meinerseits, und wir können
die Diskussion beenden.

von Egon D. (Gast)


Lesenswert?

Yalu X. schrieb:

> Da es in dem Thread aber um Pascal geht und W.S. in
> allen seinen Beiträgen bestrebt ist, die Vorzüge von
> Pascal gegenüber C herauszustellen,

...was ich für legitim halte... :)

> bin ich davon ausgegangen, dass auch seine Ausführungen
> zu Alphabeten und Ordnungszahlen diesem Zweck dienen.

Selbstverständlich.


> W.S. schrieb:
>> dann erkennen wir, daß Textzeichen eben keine Integers
>> sind,
>
> Interpretation: In C gehört char zur Gruppe der
> Integertypen, in Pascal nicht. Deswegen ist C schlecht
> und Pascal gut.
>
> Mit dem ersten Satz hat er recht, der zweite ist
> Geschmackssache.

Das ist unstrittig.


>> Textzeichen sind keine Rechengrößen
>
> Interpretation: In C sind auf char Rechenoperationen
> erlaubt, in Pascal nicht. Deswegen ist C schlecht und
> Pascal gut.
>
> Das ist nur teilweise richtig, denn auch in Pascal kann
> mit char gerechnet werden. wenn auch nur sehr eingeschränkt.
> Mit inc ist nämlich eine Addition mit einem Integer
> definiert. Beispiele: inc('A') -> 'B', inc('A', 4) -> 'E'.
> Man muss also nicht chr(ord('A')+4) schreiben, wie es W.S.
> wohl vorschwebt.

Meine Überraschung ist Dir sicher. Das habe ich auch nicht
gewusst.

A propos "definiert": Schätzungsweise kann man aus
mathematischer Sicht auf jeder endlichen geordneten Menge
"rechnen", da sich diese auf eine passende Teilmenge der
natürlichen bzw. ganzen Zahlen abbilden lässt. Ob eine
Programmiersprache jedoch solche "Rechnungen" zulassen
sollte, ist eine andere Frage. Oder welcher Sinn ist dem
Ausdruck
1
"x" % "N"
zuzuordnen?


>> und Vergleiche zwischen Textzeichen können deshalb nur
>> auf Gleichheit oder Ungleichheit gemacht werden. Jegliche
>> weiterführenden mathematischen Vergleiche (größer oder
>> kleiner) funktionieren nur mit der Ordnungszahl in einem
>> bestimmten Alphabet.
>
> Interpretation: In C sind sind > und < auf char erlaubt,
> in Pascal nicht. Deswegen ist C schlecht und Pascal gut.

Hmm. Nee.
Das habe ich anders aufgefasst.

W.S. argumentiert (auch in den hier nicht zitierten
vorhergehenden Sätzen) im Kern so, dass sich die "Zahl"-
Eigenschaft der Buchstaben auf die m.o.w. willkürlich
zugewiesene Platznummer (Ordinalzahl) in einem Alphabet
beschränkt. Der Vergleich des üblichen deutschen Alphabetes
mit z.B. ASCII lehrt aber, dass ein und dieselbe Reihen-
folge der Buchstaben (=Ordnungsrelation) mittels gänzlich
verschiedener Zahlen ausdrücken lässt!
Dass sich eine Ordnungsrelation in einer (ansonsten
beliebigen endlichen) Menge über Zahlen ausdrücken lässt,
die den Elementen der Menge zugeordnet werden, heisst aber
nicht, dass die Elemente dieser -- nunmehr geordneten --
Menge plötzlich Zahlen sind ! In C ist das aber so.

Oder sind -- das sind jetzt meine Worte -- "Q" und
"d" Quadrat-Buchstaben, weil zufällig ASCII("Q")=81
und ASCII("d")=100 gilt?


> Das stimmt definitiv nicht, denn auch in Pascal ist das
> erlaubt. Beispiele 'A'>'B' -> false, 'A'<'B' -> true.
> Man muss also nicht ord('A')<ord('B') schreiben, wie es
> W.S. wohl vorschwebt.

Was Du hier schreibst, ist zwar eine völlig geradlinige
Zuspitzung seiner Argumentation, aber ich habe bei ihm
nicht herausgelesen, dass er das tatsächlich in dieser
zugespitzten Form behauptet bzw. gefordert hätte.

Ebensogut könnte man '>' und '<' als überladene Operatoren
auffassen, die für Druckzeichen halt "steht im Alphabet
nach" bzw. "steht im Alphabet vor" bedeuten... :)


> Wie ich schon mehrfach schrieb, liegen Pascal bzw.
> Object Pascal und C bzw. C++ in ihrer jeweiligen
> heutigen Ausprägung gar nicht mehr so weit auseinander.

Unbestritten.

Dennoch bleibt bei mir der Eindruck, dass bei (einer
bestimmten Gruppe von) C-Anwendern eine bestimmte
logische und begriffliche Schlampigkeit aggressiver
und lautstärker als integraler Bestandteil echten
Könnertums verteidigt wird, als das im Pascal-Lager
der Fall ist.
Der für mich deutlich erlebbare Nachteil dieser
Schlampigkeit ist, dass es dem Lernenden schwerer
gemacht wird, als es der Sache nach sein müsste.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Egon D. schrieb:
> Dennoch bleibt bei mir der Eindruck, dass bei (einer
> bestimmten Gruppe von) C-Anwendern eine bestimmte
> logische und begriffliche Schlampigkeit aggressiver
> und lautstärker als integraler Bestandteil echten
> Könnertums verteidigt wird, als das im Pascal-Lager
> der Fall ist.

Naja, "bestimmte Gruppen" wirst du wohl immer finden. ;-) Es gibt auch 
Leute, die sich über die Kryptizität einer Perl-Syntax aufregen und dann 
in Python "aus Optimierungsgründen" alles mit Lambdas und allen 
möglichen andere Tricks in eine Zeile quetschen müssen.

Aber man sollte sich wohl nicht an schlechten Beispielen orientieren 
sondern eher an den guten, denke ich.

von Zeno (Gast)


Lesenswert?

Egon D. schrieb:
> Liebe Leute: Das Problem ist nicht C. C ist gar nicht SO
> schlecht, wie es von seinen Kritikern häufig gemacht wird.
>
> Das Problem sind die C-Missionare.

Besser hätte man es nicht formulieren können.

von Roland F. (rhf)


Lesenswert?

Hallo,
Egon D. schrieb:
> Das Problem sind die C-Missionare.

Und die Pascal-Missionare. Und Rust-Missionare. Und Python-Missionare. 
Und ...

Oder allgemein:
"Hüte dich vor Sturm und Wind und Menschen, die fanatisch sind"

rhf

von Keiler (Gast)


Lesenswert?

@Jörg:

Zu dem (nicht) statisch gelinkten QT:
Normalerweise reicht es doch die DLLs im selben Ordner zu haben und dann 
braucht man keinen Installer (der die irgendwo unter $WINDOWS\system 
ablegt), oder irre ich mich da?

Zu VisualBasic & deiner Tek2USB Anwendung:
Das halte ich für gar nicht so abwegig. FreeBASIC und Gambas können 
anscheinend beide mit libusb umgehen. Nicht dass ich davon Ahnung hätte, 
das sagten mir jeweils die drei ersten Google-Ergebnisse.


Ich kann Installer für solche kleinen Dinge auch nicht ab. Mit SDL und 
Dev-C++ hatte ich auch schon meine Problemchen und hab letztendlich die 
DLLs mitgeben müssen - solange man die im Programmordner hält, umgeht 
man auch (mehr oder weniger) die Höllenkreise.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Keiler schrieb:

> Zu dem (nicht) statisch gelinkten QT:
> Normalerweise reicht es doch die DLLs im selben Ordner zu haben und dann
> braucht man keinen Installer (der die irgendwo unter $WINDOWS\system
> ablegt), oder irre ich mich da?

Weiß nicht, irgendwas ging da nicht oder wie auch immer, ist auch lange 
her.

> Zu VisualBasic & deiner Tek2USB Anwendung:
> Das halte ich für gar nicht so abwegig. FreeBASIC und Gambas können
> anscheinend beide mit libusb umgehen.

Naja, am Ende hat sich der Betreffende sowieso durchgerungen, seinen 
Lab-PC mal auf Windows 10 hochzurüsten, und er hat auch einen anderen 
Weg gefunden, die Daten da einzulesen. Den anderen Tek492 habe ich 
inzwischen an meine alte Firma verkauft, und die haben das Qt-GUI dann 
unter Linux in Betrieb genommen.

von Erich R. (riedere)


Lesenswert?

Das Thema ist zwar schon alt - dennoch aktuell.

Ich hatte früher mit Clipper gearbeitet. Ab 1999 dann mit Delphi und 
seit neuestem mit Lazarus.
Manchmal wurde ich belächelt - Was mit Clipper und mit dbf Tabellen ! 
Waren da die Sprüche.
Doch eines ist Tatsache: Kunden die um 1990 mein Programm (Clipper und 
dbf) gekauft hatten die haben bis heute (ja 24.Juli 2022) alle Daten 
noch.

Ich war nie ein Komponenten Enwickler - ich habe Software für normale 
Benutzer gemacht die vielfach das erste mal mit einem PC in Berührung 
kamen - und sie konnten sofort produktiv damit arbeiten.

Meiner Ansicht nach ist es irrelevant in was die Anwendung geschieben 
ist. Relevant ist des Kunden Zufriedenheit im Bezug auf Stabilität 
Gechwindigkeit und Kontinuität. Die klare Struktur und der 
unkomplizierte Aufbau hilft bei der Weiterentwicklung und einer 
Portierung immens.

Ich bin nun 74 und habe wieder begonnen, diesmal mit Lazarus und SQLite.
Mit meinen eigenen Regeln die ich mir schon immer auferlegt habe:

Wers wissen will:
1. bevor ich begonnen habe für Windows Apps zu schreiben habe ich das 
"Normenbuch" von Microsoft angesehen.
2. Meine ersten Programmieraufgaben waren in Assembler 8080, 8085, Z80 
etc. Und die Datenspeicherung erfolgte auf Tonband, das Programm war 
100m lang - ja auf Lochstreifen, dann auf Karten. Da hat man gelernt auf 
Effizienz zu achten.
3. Meine eigenen Regeln im Programm - eine Struktur zB auch mit den 
Variablen, Dateibezeichungen etc.. Ich kann meine Programme von 1985 
noch lesen und problemlos verstehen.

Ich hatte einmal was zu tun in VisualBasic. Und hatte grösste Mühe damit 
- ich war und bin eingefahren auf Pascal. Aber nie würde ich 
missionieren.
Jeder nach seinem Gusto - das Ergebnis zählt.

Gruss in die Runde von einem "alten Klaus"
Erich

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Erich R. schrieb:
> Jeder nach seinem Gusto - das Ergebnis zählt.

Da stimme ich auch zu. Ich bin nur 10 Jahre jünger und hatte
damals Ender 90er auch MS-DOS, dBaseIII und Clipper gelernt.

Hobbymäßig hatte ich dann mit Turbo Pascal 3.0 und später den
ersten Delphi - Versionen weiter gemacht. Bis dann Borland
an Embaraco verkauft wurde und Delphi unglaublich teuer wurde.

Dann ist mir dann Profan (heute XProfan), das auch mit Delphi
entwickelt wurde, über den Weg gelaufen. Mit dem arbeite ich
heute noch sehr gerne. Natürlich mit den aktuellen Versionen.

In dem Sinne wäre ich heute dann auch etwas rückständig.
Aber wie gesagt, das Ergebnis zählt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.