Georg schrieb:> Für sowas ist zwar C nicht absolute Voraussetzung, aber das Verschleiern> des Sinns hinter einer Programmkonstruktion fällt doch mit C oder C++> mit Abstand am leichtesten, wenn man einmal von einigen sehr exotischen> Sprachen absieht (oder scherzhaft gemeinten wie Brainfuck).
Kennst du den Spruch "real programmers can write fortran in any
language"? Keine Programmiersprache der Welt ersetzt eine gute
Dokumentation, es sei denn du erfindest einen Compiler für Prosatexte.
Eine gute Dokumentation kann einiges an kruden Code kompensieren,
solange die Programmstruktur verständlich ist.
Georg schrieb:> Dass man, im Gegensatz dazu, ein Programm wie englischen Klartext lesen> kann, spricht noch mehr als für Pascal für die Uralt-Sprache COBOL,
Das trifft vielleicht auf die Syntax zu, aber nicht auf die Semantik.
Bei C hat man sich halt an der Mathematik orientiert. Es ist nichts
weiter als eine andere Notation, die sich wie jede andere auch schnell
im Kopf verankert. Dann weiß ich was das ein oder andere bedeutet, ohne
darüber nachzudenken. Warum soll ich ständig "begin end" schreiben wenn
es auch ein {} tut? Für Anfänger mag das erst mal toll sein, man bleibt
allerdings nicht für den Rest seines Lebens Anfänger. Obwohl manche
Leute schaffen das sogar.
Albert M. schrieb:> Aus Erfahrung weiss ich dass C/C++ Programmierer für umfangreiche> Applikationen ca. die 3 bis 10 fache Zeit als Delphi Programmierer> benötigen.
Waren die Applikationen überhaupt vergleichbar? Wie viel Erfahrung und
Kenntnisse hatten die Programmierer in der jeweiligen Sprache? Welche
Entwicklungswerkzeuge wurden benutzt? Welche Bibliotheken wurden
verwendet? Wahrscheinlich wurden auf der einen Seite schlechtere
Bibliotheken/Werkzeuge benutzt, obwohl es besseres gibt. Hört sich
jedenfalls ziemlich übertrieben an.
Albert M. schrieb:> Es> gibt jede Menge grosser Industrie-Software die auch heute noch in Delphi> geschrieben wird. Das hat wohl seinen Grund.
Das heißt gar nichts. Es gibt noch einiges an Software die in Cobol
geschrieben worden ist und weiter entwickelt wird. Nicht weil Cobol so
toll ist, nein. Sondern weil sich keiner bei den Banken traut, die Basis
der Software anzurühren oder neu zu schreiben. Wer nimmt das Risiko auf
sich? Darüberhinaus schreibt Niemand größere Software mal so schnell
neu. Das ist sehr zeitaufwändig und teuer. Das wird im normalen Fall
kein Wirtschaftler erlauben.
Wie wärs jetzt mal richtig handfesten Argumenten? Wie zum Beispiel
starke Typisierung, Referenzen und Modulsystem bei Pascal? Oder seid ihr
einfach nur Pascal-Fanboys? Gibt es da so tolle Analysetools wie
Valgrind oder Lint?
also irgendwie sollte die Diskussion schon auF Pascal und C , Cpp, basic
beschränkt bleibe, in der Vergangenheit wurde ganz offensichtlich auch
nur dieser kreis nicht ohne Grund, auch kommerziell bedient
Ich kenne keinen Cobol oder sonstigen Compiler für AVT oder ARM der
komerziell ist ;-)
>Warum soll ich ständig "begin end" schreiben wenn>es auch ein {} tut?
also "end" schreibt man eigentlich nicht (das wird automatisch
eingefügt)
außerdem kann man das Wort begin/end schneller schreiben als { bzw. }
(ich schreibe {} mit AltGr also der rechten Hand, das ist schon ziemlich
"müll", ... könnte man vielleicht auf strg-alt umgewöhnen, aber viel
besser wird es da auch nicht..)
ein fettes blaues begin/end "erkennt" man auch besser, zwischen den
ganzen (Runden/Eckigen)-Klammern die sonst so herumschwirren..
Robert L. schrieb:> außerdem kann man das Wort begin/end schneller schreiben als { bzw. }> (ich schreibe {} mit AltGr also der rechten Hand, das ist schon ziemlich> "müll", ... könnte man vielleicht auf strg-alt umgewöhnen, aber viel> besser wird es da auch nicht..)
Aber auch nur beim deutschen Tastaturlayout :P.
Robert L. schrieb:> ein fettes blaues begin/end "erkennt" man auch besser, zwischen den> ganzen (Runden/Eckigen)-Klammern die sonst so herumschwirren..
Warum muss das denn so auffällig sein? Wenn man den Code ordentlich
einrückt sind die Scopes ohnehin schon leicht zu erkennen. Das fette
blaue begin/end stört nur und verdeckt die Sicht auf das wesentliche.
>stört nur und verdeckt die Sicht auf das wesentliche.
für einen "Anfänger" der sich nicht damit beschäftigt hat, vielleicht
;-)
nachdem das "wesentlich" immer Schwarz und dünn geschrieben ist
und das unwesentliche (if, then, else, and, or, try except, finally,
uses, infertface initialization usw. )immer dick (und bunt), ist die
Trennung fürs geübte Gehirn ziemlich einfach.. (außerdem kann sich das
jeder einstellen wie er will... und hat mit der Sprache jetzt nix zu
tun..)
Andreas H. schrieb:> Also Lisp als neu erfundene (!!) ''"grandiosere" Sprache'' aufzulisten> ist mutig aber lustig.
Ähemm.. kannst du lesen? Ich meine nicht nur die Buchstaben, sondern
auch die Satzzeichen. Oder anders gesagt: das war ein ZITAT, weswegen
es auch in den doppelten Hochkommas (vulgo Gänsefüßchen) steht.
Andreas H. schrieb:> Und willst Du wirkich heute noch Fortran IV hacken ?
Ich selber nicht, aber ich kenne einige Leute, die ihre Berechnungen
immer noch in Fortran machen. Die Sprache ist tatsächlich uralt, hat
aber immer noch ihre Meriten.
NSA schrieb:> Achso und in Pascal hätten sie diese Probleme nicht gehabt?
Nö. Ganz eindeutig Nö.
NSA schrieb:> Und wo ist da jetzt das Problem mit stdint.h?
Du hast es nicht kapiert. Einfach überhaupt nicht kapiert.
Kein einziger C-Compiler auf dieser Welt kennt so ein Schlüsselwort wie
uint32_t. Derartige Schlüsselwörter fehlen ganz einfach in der Sprache
C. Und was du da anziehst, ist lediglich ein lumpiges Includefile. Sowas
kann jeder sich selber schreiben, um darin von typedef Gebrauch zu
machen, aber das ist lediglich eine simple Umbenennung. Kannst du das
begreifen oder nicht?
Karl Käfer schrieb:> Es ist der Industriestandard. Dieser Umstand ist zunächst einmal nur> eine Feststellung und wäre alleine noch kein Argument. Aber entscheidend> ist das Ergebnis: nämlich die breite Verfügbarkeit von sehr> leistungsfähigen, gut getesteten und dokumentierten Werkzeugen und> Bibliotheken.
Stop mal. Wir diskutieren doch nicht etwa, wieviele Compiler es gibt,
sondern wir diskutieren über die sprachlichen Qualitäten von C versus
Pascal. Mir ist völlig klar, daß es im Gegensatz zu Pascal für C eine
große Anzahl von Toolchainesund Zielplattformen gibt - aber das ist kein
Qualitätsmerkmal der jeweiligen Sprachkonstrukte um die es hier geht.
Ich habe das Yalu ja schon geschrieben, den Vergleich mit den Milliarden
Fliegen. Also bitte! Die praktische Frage "Wo krieg ich nen Compiler
her" ist selbstverständlich relevant für alle Leute, aber sie ist eine
andere als die, die wir hier diskutieren.
Vielleicht würde es helfen, Leuten wie mikroe mal nahezulegen, ihr
Compilerkonzept auf kundendefinierbare Hardware-Definitionen
umzustellen. Dann wäre das nämlich eine recht passable Basis für eine
deutlich größere User-Basis. Und es würde der C-Inzucht entgegenwirken.
Yalu X. schrieb:> Wie oft muss ich noch wiederholen, dass das nicht stimmt?
Und wie oft muß ich wiederholen, daß du falsch liegst? Ich könnte dir
jetzt mit K&R versus ANSI kommen, was letztlich auf Stein- ach was sag
ich UR-UR-UR-alt-Versionen von Sprachen hinausläuft. Der eigentliche
Punkt war und ist dein wirklich nicht haltbares Argument, daß die
Kompatibilität zu Altbeständen an Code ja SOOO wichtig sei. Und dieses
Argument ist schlichtweg überzogen, denn wer will heutzutage noch
Steinalt-Quellen mit heutigen Compilern übersetzen? Zu welchem Zweck?
Allenfalls nur als akademische Übung ohne praktische Relevsnz. Die
Blickrichtung heißt eigentlich ZUKUNFT und wie gut welche
Programmiersprache für die Zukunft geeignet ist.
Ich sag's mal so: Erst mit der ANSI-Renovierung ist C in den benutzbaren
Bereich gekommen und erst mit Borland ist Pascal in den benutzbaren
Bereich gekommen. Und beides ist verdammt lange her. Also komm du mir
nicht mit Uraltkamellen, die sind längst vertrocknet. Sowas lutscht
keiner mehr.
Spring einfach mal über deinen Schatten und gib es endlich zu, daß die
Art und Weise der Deklaration von Konstanten Typen und Variablen bei
Pascal ganz einfach besser und flexibler und weitsichtiger gelöst ist
als bei C. In Pascal kann man einen neuen Datentyp einführen, ohne
bestehende Datentypen zu tangieren. Bei C geht das nicht. Siehe Boolean,
Strings, Objekte und so weiter. Das kommt vom Konzept, was von einem
Grunddatentyp ausgeht und Modifikationen an diesem Datentyp anstelle
separater Datentypen. Das ist der Punkt, auf dem ich so lange
herumhacke, bis du es begriffen hast.
Typ-Probleme sind aber nur einer von vielen Aspekten. Die Vielzahl von
Seiteneffekten, die ganz häufig zu völlig unerwarteten Bugs führen, ist
eine andere Sache. Ebenso Dinge, die zwar syntaktisch völlig richtig
sind, aber nach jahrzehntelanger Erfahrung sich zu 99.9% als
Schusselfehler erwiesen haben. Beispiel: if(a=b)..
C ist von Grund auf verkorkst, weswegen man tatsächlich erheblichste
Probleme bei etwaigen Modernisierungsversuchen hat. stdint.h ist ein
beredtes Beispiel dafür. Deshalb bin ich fest davon überzeugt, daß C
nicht wirklich zukunftsträchtig ist und genau deshalb eine eher
ausbremsende Wirkung in künftigen Generationen haben wird.
So, genug für heute.
Denkt lieber an's Eiersuchen...
Frohe Ostern wünscht
W.S.
W.S. schrieb:> Spring einfach mal über deinen Schatten und gib es endlich zu, daß die> Art und Weise der Deklaration von Konstanten Typen und Variablen bei> Pascal ganz einfach besser und flexibler und weitsichtiger gelöst ist> als bei C.
Mag sein. Ok gut, ist so. 1:0 für Pascal.
Aber, wo ist C heute? Wo ist Pascal heute? Der Sieger der Herzen. Ist ja
auch was...
W.S. schrieb:> stdint.h ist ein beredtes Beispiel dafür.
C verfolgt da eben ein anderes Konzept. Es wird soviel wie möglich in
standardisierte Bibliotheken verlagter (printf und Co.), der Sprachkern
bleibt schlank.
Pascal geht eben einen anderen Weg.
Welcher Weg nun besser ist kann man drüber streiten.
Der C-Weg ist wohl portabler.
Die aktuelle Compilerlandschaft gibt mir da recht.
W.S. schrieb:> denn wer will heutzutage noch Steinalt-Quellen mit heutigen Compilern> übersetzen? Zu welchem Zweck?
Unix(artige) Systeme sind häufig in C geschrieben. Häufig kommen dabei
Werkzeuge aus dem GNU-Umfeld zum Einsatz. Die Sourcen von grep und Co.
dürfen wohl als "uralt" bezeichnet werden.
W.S. schrieb:>> Also Lisp als neu erfundene (!!) ''"grandiosere" Sprache'' aufzulisten>> ist mutig aber lustig.>> Ähemm.. kannst du lesen? Ich meine nicht nur die Buchstaben, sondern> auch die Satzzeichen. Oder anders gesagt: das war ein ZITAT, weswegen> es auch in den doppelten Hochkommas (vulgo Gänsefüßchen) steht.
Das Lisp hast Du selbst eingeführt --hatte mich auch etwas verwirrt. Die
Lisp-Familien sind sicher durchaus interessant, aber eben schon sehr
alt. Womöglich hast Du Python oder Crystal gemeint?
W.S. schrieb:> Der eigentliche Punkt war und ist dein wirklich nicht haltbares> Argument, daß die Kompatibilität zu Altbeständen an Code ja SOOO> wichtig sei.
Das ist dort wichtig, wo Softwareentwicklung Geld kostet. Im
Hobbybereich sieht es das naturgemäß etwas anders anders aus.
W.S. schrieb:> Die Blickrichtung heißt eigentlich ZUKUNFT und wie gut welche> Programmiersprache für die Zukunft geeignet ist.
Wenn Abwärtskompatibilität unwichtig ist, sondern man die freie Wahl
hat, nimmt man doch nicht einen uralten, im Lauf der Jahre nur durch
unzählige Facelifts gerade so am Leben erhaltenen Dinosaurier, sondern
eine der jungen, frischen Programmiersprachen, in deren Entwicklung die
jahrzehntelange (positive wie negative) Erfahrung mit anderen Sprachen
bereits von Anfang an mit eingeflossen ist. Auswahl gibt es zur Genüge.
Wer heute noch freiwillig Pascal lernt, denkt dabei (genauso wie bei
Fortran oder Cobol, die eine vergleichbare Entwicklung durchgemacht
haben) an alles Mögliche, aber ganz sicher nicht an seine Zukunft.
> C ist von Grund auf verkorkst, weswegen man tatsächlich erheblichste> Probleme bei etwaigen Modernisierungsversuchen hat. stdint.h ist ein> beredtes Beispiel dafür.
Was hast du nur immer mit stdint.h und den darin deklarierten Integer-
Typen? Es ist doch in der Praxis doch so etwas von völlig belanglos, ob
diese Datentypen im Compiler hartcodiert oder per typedef deklariert
sind.
Hallo,
die Unterschiede zwischen Programmiersprachen sind ein endloses Thema,
aber sich daran aufzugeilen ob man { oder begin schreibt, und darüber
jahrzehntelang Krieg zu führen, ist vollkommen lächerlich. Das ist
überhaupt kein relevanter Unterschied.
Georg
Nene das siehst du falsch. Solche Syntaxunterschiede sind die Quelle für
die längsten Forenthreads. Da gibt es nur jeweils eine richtige Meinung
und jeder der was anderes gut findet ist schwer gestört!
Wenn du jetzt hingehst und einen Parser schreibst, der begin/end in
C-Code erlaubt dann explodieren die Köpfe :)
Zum Thema (haha :D ): Syntaxmässig finde ich Pascal auch etwas schöner.
Nach Basic für den C64 habe ich auch Turbo Pascal gelernt und zum Lernen
ist die Sprache imho sehr schön. Ansonsten würde ich das niemandem
empfehlen.
C ist der Standard für Mikrocontroller und es gibt imho keinen
vernünftigen (begin/end statt {} ist nicht vernünftig) Grund davon
abzuweichen. Es funktioniert, man muss sich nicht verkrampfen und am
wichtigsten, es gibt zigtausende libs, Hilfestellungen und Mitleidene
die einem helfen können.
Jemandem der am PC schnell Sachen fertig haben will würde ich im Moment
auch eher Python empfehlen. Nicht weil die Syntax bombastisch ist (ich
finde sie aber extrem gut lesbar) sondern weil man schnell voran kommt
und es viel Hilfe gibt. Gibt sicherlich in Detailfragen besser designte
und vor allem schnellere Sprachen aber das lohnt sich imho nur selten...
eben drum, und schlussendlich wissen insgeheim sowieso alle das Pascal
besser ist ;-) hehe
Wenn einige hier wüßte, welch kommerzielle Produkte alle (also µc) in
PAscal programmeirt wurde würden sie blaß werden :-)
Im PC Bereich das gleiche und mindestens genauso häufig wird auch noch
in Visal basic gearbeitet.
Viele der verwendeten Lieblingsprogramme könnten in einer davon
programmiert worden sein....;-)
Sehr viel bzw das meiste aber sicher in, C, aber das sich nicht immer
das Beste durchsetzt wissen wir seit VHS, Windows etc, ansonsten würden
wir heute alle mit OS/2 arbeiten z.B :-)
Ich würde mich ehrlich gesagt sehr wundern, wenn irgendeines meiner
täglich genutzten Programme in Pascal programmiert ist. In Visual Basic
noch mehr.
Zu den Mikrocontrollern würde ich jetzt mal dreist schätzen, dass >95%
aller verkauften System in C und/oder Assembler programmiert sind.
Habe noch nie von Pascal in dem Bereich gehört und auch noch nie eine
Stellenanzeige in der Art gesehen.
Hallo Teslaspule,
Teslaspule schrieb:> Kennst du den Spruch "real programmers can write fortran in any> language"? Keine Programmiersprache der Welt ersetzt eine gute> Dokumentation, es sei denn du erfindest einen Compiler für Prosatexte.
Also etwa sowas: [1]?
Liebe Grüße,
Karl
[1] http://en.wikipedia.org/wiki/Literate_programming
zapotek schrieb:> Zu den Mikrocontrollern würde ich jetzt mal dreist schätzen, dass >95%> aller verkauften System in C und/oder Assembler programmiert sind.
In einigen Bereichen wird viel modellbasiert entwickelt. Das wird zwar
im Prinzip auch als C-Code für die Zielplattform übersetzt, aber man
kann eigentlich nicht davon sprechen, daß es in C programmiert ist.
Die Frage ist auch, was für dich ein System ist und ab wann du davon
sprichst, daß es in C programmiert ist. Auf vielen Systemen kommen heute
mehrere Sprachen zum Einsatz. Beispiel Android: Der Kernel und
vermutlich ein paar Systembibliohteken sind in C programmiert, aber die
ganzen Apps - auch die, die Teil des Systems sind - sind überwiegend in
Java geschrieben.
Karl Käfer schrieb:> Also etwa sowas: [1]?
Vielleicht auch sowas:
http://en.wikipedia.org/wiki/Shakespeare_(programming_language)
Hallo W.,
W.S. schrieb:> Karl Käfer schrieb:>> Es ist der Industriestandard. Dieser Umstand ist zunächst einmal nur>> eine Feststellung und wäre alleine noch kein Argument. Aber entscheidend>> ist das Ergebnis: nämlich die breite Verfügbarkeit von sehr>> leistungsfähigen, gut getesteten und dokumentierten Werkzeugen und>> Bibliotheken.>> Stop mal. Wir diskutieren doch nicht etwa, wieviele Compiler es gibt,> sondern wir diskutieren über die sprachlichen Qualitäten von C versus> Pascal.
Das habe ich anders verstanden. Ich habe die Frage des TO so verstanden,
daß er eine Entscheidung zwischen C und Pascal treffen will und
Argumente sucht, warum er sich für die eine oder andere Sprache
entscheiden sollte. Die Frage beschränkt sich also nicht nur auf die
sprachlichen Qualitäten, und deswegen spielen die Infrastruktur an
Werkzeugen, Dokumentationen und Beispielen, die sich rund um diese
beiden Programmiersprachen gebildet haben, sicher eine gewichtige Rolle.
> Mir ist völlig klar, daß es im Gegensatz zu Pascal für C eine> große Anzahl von Toolchainesund Zielplattformen gibt - aber das ist kein> Qualitätsmerkmal der jeweiligen Sprachkonstrukte um die es hier geht.
Wie gesagt, nach meiner Einschätzung der Frage geht es eben nicht nur um
die jeweiligen Sprachkonstrukte. Die spielen natürlich eine Rolle, wenn
auch IMHO eine eher untergeordnete. Für einen Entwickler ist es für
seine praktische Arbeit, insbesondere im Hinblick auf Produktivität,
Effizienz und Komfort, doch viel wichtiger, wie gut er von Werkzeugen,
Bibliotheken und Dokumentationen unterstützt wird. Die beste
Programmiersprache ist in der Praxis unbrauchbar, wenn es keine
Werkzeuge, keine Bibliotheken, oder keine Dokumentation dafür gibt.
Ohnehin spielen die Sprachkonstukte für die Beantwortung der Frage
sicher eine untergeordnete Rolle, denn ob ich "{" oder "BEGIN" schreibe,
ist am Ende dann doch nur eine Frage des Geschmacks, des einmaligen
Lernens und langfristig eine der Routine. Die Leistungsfähigkeit der
beiden Sprachen unterscheidet sich allerdings auch gar nicht so
wesentlich, daß sie als Kriterium für die genannte Fragestellung dienen
könnte.
Über Geschmack läßt sich bekanntlich nicht streiten, über
Infrastrukturen und die Verfügbarkeit und Nützlichkeit von Werkzeugen
hingegen schon.
Liebe Grüße,
Karl
der Support in Pascal Foren ist freundlicher!
Ich lese da nie sowas wie nimm ein Buch oder lerne erstmal die
Grundlagen etc!!
Das ist für mich alleine schon ein gewichtiger Grund!!!
Obwohl ich zugeben muss, ich weiß nicht wie es in den richtigen C Foren
ist...im Mikrocontroller Forum ist der Support jedenfalls zum Kotzen.
W.S. schrieb:> Ich habe das Yalu ja schon geschrieben, den Vergleich mit den Milliarden> Fliegen.
tja, auch kein Argument, auch da stellt sich die Frage wer langfristig
überlebt, die Fliegen die Sch... fressen oder die kultivierten Menschen
W.S. schrieb:> denn wer will heutzutage noch> Steinalt-Quellen mit heutigen Compilern übersetzen? Zu welchem Zweck?
ich z.B., und der Zweck ist ein altes Programm auf einem aktuellen
Rechner verwenden zu können.
Ich habe vor ca. 30 Jahren ein Commandline Programm für den MAC
geschrieben das heute noch genutzt wird.
Damals noch mit 68k Prozessoren, ein C-Compiler dessen Namen ich gar
nicht mehr weiß, dann kam der Power PC, -> neuer Compiler, dann Umstieg
auf Intel, -> neuer Compiler, dann Umstieg auf 64-Bit -> neuer Compiler
und nur da musste ich eine Änderung vornehmen weil ich in jugendlichem
Leichtsinn einen Pointer in einem long gespeichert hatte.
noch viel offensichtlicher wird es wenn man sich die existierenden C
Bücher anschaut.
Es gibt eigentlich nicht eins wo es nicht sofort heißt..das ist quatsch,
der Autor hat keine Ahnung der ist zu Dumm und hält sich nicht an den
Ansii Standards etc pp :-)
Ich hatte hier im Forum mal Fragen dazu gestellt und wurde
zurechtgewisen mit lies ein buch..mache erstmal die Grundalgfen...lol
nur eben genau diese Grundlagen!! waren in mehreren Büchern völlig
unterscheidlich!
Das fängt schon mit void main(void) an
Ich bin dann bei Pascal geblieben da gibt es nicht schon bei den
einfachsten Grundalgen einen Seitenlangen Threat und
Grundsatzdiskussionen!!
Veilleicht leigt es gar nicht darn das die Anwender von C bescheut sind,
das die Diskussionen immer so ausunfern..vieleicht leigt es einfach an
C!
In PAscal stellt man eine Frage und bekommt innerhalb weniger Minuten
2-3 Beispiele mit das besipiel ist gut, Du kannst es auch auch so amchen
dann sparst Du dir xy :-9
In C geht es nur los, nein das ist so nicht korrekt, kalr kann man
machen ist halt nur kacke etc pp
Ich finde das sagt schon sehr viel über eine SPrache ;-)
Pascal liegt und hält sich seit Jahren hartnäckig im Mittelfeld irgendwo
zwischen Perl und Ruby.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Wenn man die Trennung Pascal vs Object Pascal mal wegnimmt und
zusammenfasst (die Gegenseite darf das dann auch gerne mit
(Object-)C(++) ebenfalls tun) dann kommen wir zusammen auf über 2% und
sind dann irgendwo in der VisualBasic und Python-Ecke. Also auch da noch
bekannte Namen rundherum.
http://www.tiobe.com/index.php/content/paperinfo/tpci/Pascal.htmlhttp://www.tiobe.com/index.php/content/paperinfo/tpci/Delphi_Object_Pascal.html
Als abgeschlagenen Sonderling oder Exoten der nur noch unter "ferner
liefen" läuft würde ich so eine Plazierung bestimmt nicht bezeichnen.
Und wenn man jetzt mal etwas selektiert weil man bestimmte Anforderungen
hat, also zum Beispiel mal alles rauswirft was Scriptsprache ist, alles
rauswirft was einen JIT oder eine VM oder dergleichen benötigt und nur
noch drin lässt was kompakten nativen Code erzeugt dann kommt man auf
folgende Liste:
* C
* Objective-C
* C++
* (Object-)Pascal
Also wenn man keinen C-Dialekt haben will dann kommt als nächstes (und
war da schon immer und wird es immer sein) gleich das gute alte (neue,
zeitlose) Pascal.
Das ist also nicht "ferner liefen", danach kommt auch erstmal lange nix
anderes mehr und dann vielleicht noch Go wenn man sich die Wahl gönnen
will und sich nicht von vornherein in die Tasche lügt es gäbe ja nix
anderes als C-basiertes. Aber das gibts ja zum Glück, ist quicklebendig,
hat ne rege Community, exzellenten Support und die freie (L)GPL
Toolchain wird sehr aktiv gepflegt und ständig weiterentwickelt (es
vergeht kein Tag ohne ein halbes dutzend Commits) von einer gut
durchmischten internationalen Crew aus 15+ sehr erfahrenen
Compilerarchitekten mit insgesamt mehreren hundert Jahren Erfahrung.
Adrian schrieb:> naja, wie gesagt, es sollte die Sprache auch für µc geben, und da bleibt> eben nur PAscal, C und Basic
Das stimmt so ganz nicht.
Nim ist prinzipiell durchaus für uC einsetzbar, da es C code erzeugt.
32k Speicher sollte der uC wohl schon haben. Yalu hatte in die Richtung
ja mal etwas experimentiert -- ich hätte igentlich auch Lust, habe aber
momentan absolut keine freie Zeit. Mit dem MSP430 hatte hatte jemand
kürzlich immerhin eine LED zu blinken gebracht.
Rust ist wohl auch prinzipiell für kleine uC einsetzbar, da kann ich
mich aber nicht an Details erinnern. Und bei D? Sollte prinzipiell
möglich sein. Crystal? Die setzen die LLVM ein, um nativen Code zu
erzeugen. Wobei ich nicht weiss, wie weit da uC unterstützt werden. Auch
hatte hier ja mal jemand ein Oberon für einen kleinen uC vorgestellt,
aber das darf man wohl nicht allzu ernst hehmen. Sogar Python für uC
gibt es wohl, wurde hier kürzlich genannt. Also es gäbe schon
Alternativen, wenn man partout kein C mag -- für ARM natürlich erst
recht. Nur man bekommt eben nicht alles vorgekaut serviert.
na aber eine wirkliche Unterstützung nenne ichd as nicht..freepascal
geht auch für ARM, aber für den embedded bereich nicht wirklich.
Das etwas funktioniert heisst ha nicht, das es vernünftig nutzbar
wäre..und erst recht nicht, wenn es offenbar keine kommerziellen
Anbieter hierfür gibt, was dafür spricht, das es keinen Markt gibt..
Adrian schrieb:> noch viel offensichtlicher wird es wenn man sich die existierenden C> Bücher anschaut.
Na ich weiß nicht ob das nur C betrifft, ich glaube das betrifft
irgendwie fast alle Lehrbücher über Programmiersprachen im
deutschsprachigen Raum. "Programmieren in C" ist ein gutes Buch, nur
leider adressiert es keine Programmieranfänger, sondern Anfänger der
Sprache C. Die englischen Bücher sind wesentlich besser. Keine Ahnung
wie das zu erklären ist, möglicherweise schreiben die Autoren, die
wirklich Ahnung, haben einfach in englisch, weil sie damit eine
wesentlich größere Anzahl an potentiellen Kunden erreichen können.
Autoren die mehr Halbwissen besitzen, hätten keine Chance auf dem
internationalen Markt und beschränken sich deshalb auf einen kleineren
Markt (z.B. deutschsprachiger Raum). Keine Ahnung ob da was dran ist.
Aber gerade Anfänger können die Bücher kaum bewerten, was man an einigen
Amazon Rezessionen zu sehen ist.
Adrian schrieb:> Ich hatte hier im Forum mal Fragen dazu gestellt und wurde> zurechtgewisen mit lies ein buch..mache erstmal die Grundalgfen...lol> nur eben genau diese Grundlagen!! waren in mehreren Büchern völlig> unterscheidlich!
Es gibt in den Foren fast täglich solche Threads in denen es letzten
Endes einfach nur um läppische Grundlagen geht. Hätten sich die Anfänger
ein Buch besorgt und dieses auch wirklich gelesen, gäbe es mindestens
2/3 dieser Threads nicht. Die meisten Anfänger sind sehr jung und bei
den neueren Generationen sind Bücher, Geduld und Eigeninitiative einfach
out. Da wird lieber ein halbgares Tutorial, gespickt mit viel
Halbwissen, halb durchgelesen und sofort Code geschrieben. Oft
funktioniert dieser nicht und es wird schnell mal im Forum nachgefragt.
Das nerft. Es gibt hier einige geduldige und kompetente Leute, die
kommen dann allerdings auch irgendwann mal an ihre Grenzen. Da geht dann
eine Menge Zeit drauf und wirklich interessante Threads gehen unter. Ein
bisschen unnötig oder? Hier in diesem Forum ist dann auch noch besonders
Schlimm, weil viele gleich einen µC programmieren wollen. Ein
zusätzlicher Problemherd.
Ein populäres Beispiel ist die Nullterminierung bei Strings, der String
"Test" ist nicht vier Zeichen lang sondern fünf. Das steht in jedem
C-Buch drin, trotzdem kommt das Thema ständig auf.
Ich war auch mal Anfänger, aber für mich war das Forum immer der letzte
Ausweg. Da ging dann natürlich ein paar Stunden drauf, aber dafür lernte
ich Fehlermeldungen zu verstehen und wie man Fehler sucht.
Was mich interessieren würde: was war das für ein Problem und warum soll
das in Büchern anders drinstehen?
Adrian schrieb:> Ich bin dann bei Pascal geblieben da gibt es nicht schon bei den> einfachsten Grundalgen einen Seitenlangen Threat und> Grundsatzdiskussionen!!
Grundsatzdiskussionen gibt es in jeder Sprache, ob nun dies oder das die
elegantere und bessere zur Lösung eines Problemes ist. Gerade bei einer
Sprache wie C, die dir selbst keine Schranken aufweist, ist dieses
Potential natürlich groß. Bei C++ ist es noch viel schlimmer, weil die
Sprache so verdammt mächtig ist und dir so viele Sprachmittel zur
Verfügung stellt.
Adrian schrieb:> Veilleicht leigt es gar nicht darn das die Anwender von C bescheut sind,> das die Diskussionen immer so ausunfern..vieleicht leigt es einfach an> C!
Vielleicht liegt es auch einfach nur an der größeren Popularität von C.
Bei Star Wars oder Star Trek gibt es auch einige (wirklich heftige)
Diskussionen, aber bei einem drittklassigen Sci-Fi Film eher weniger.
Adrian schrieb:> In PAscal stellt man eine Frage und bekommt innerhalb weniger Minuten> 2-3 Beispiele mit das besipiel ist gut, Du kannst es auch auch so amchen> dann sparst Du dir xy :-9
Dann schau mal genauer hin, denn diese Threads gibt es auch bei C zu
genüge.
Adrian schrieb:> Ich hatte hier im Forum mal Fragen dazu gestellt und wurde> zurechtgewisen mit lies ein buch..mache erstmal die Grundalgfen...lol> nur eben genau diese Grundlagen!! waren in mehreren Büchern völlig> unterscheidlich!
Ah jetzt ist mir klar was du meinst.
Beitrag "" in String Konstante verwenden?"
Jaja, Anführungszeichen "in mehreren Büchern völlig unterschiedlich".
Erzähl keine Märchen. Du hast das Recht Kritik zu äußern verspielt.
Keine Ahnung warum du glaubst deswegen anderer Leute Zeit verschwenden
zu müssen, wenn es eine simple Suche nach "C Anführungszeichen in
Strings" auch getan hätte.
C hat daran keine Schuld.
nein darum ging es nicht, wie gesagt berits mit int main (void) beginnt
es..
bzw void main(void) etc. was alles beides in Lehrbücher steht und alles
sovöllig falsch ist.. z.B. das große C Buch mit über 1400 Seiten oder
so, doer C für kids war glaube ich angeblich ebenfalls falsch
Salewski, Stefan schrieb:> Auch> hatte hier ja mal jemand ein Oberon für einen kleinen uC vorgestellt,> aber das darf man wohl nicht allzu ernst hehmen.
Naja, so klein ist der C167 mit seinen 144 Pins ja nicht. ;-)
Die Unterscheidung zwischen Pascal und Oberon geht mit halt auf den
Geist, und wenn sowas noch ausgrechnet von Yalu kommt..., der könnte
es besser wissen.
Ich wollte usprünglich auch einen Pascalcompiler schreiben, aber schon
die ganz kleine Recherche (deutsche! Wikipedia) hat mich davon
überzeugt, dass das Unsinn ist. Deshalb Oberon, sagen wir Pascal mit
Objekten. Kein Mensch programmiert mehr in K&R-C, aber für Pascal
wird noch immer die 1972er-Version zum Vergleich herangezogen.
Da wir hier ja unter uns sind, das kannst du schon ernst nehmen:
Der Modulimport inklusive Linken funktioniert. Dazu aber bald mehr im
anderen Thread.
Grüße, Guido
Guido B. schrieb:> Die Unterscheidung zwischen Pascal und Oberon geht mit halt auf den> Geist, und wenn sowas noch ausgrechnet von Yalu kommt..., der könnte> es besser wissen.>
Nun ja, jemand hatte hier Pascal als die von einem Professor perfekt
geplante Sprache bezeichnet. Dabei hat Wirth selbst Pascal recht schnell
verworfen und durch Modula und Oberon ersetzt. Wenn er selbst so angetan
von Pascal gewesen wäre, hätte er wohl den Namem beibehalten. Pascal
hatte eben auch einige Schwachpunkte. Nur haben sich Borland und die
Delphi-Leute an den Namen geklammert und eben leider auch einige
konzeptionelle Schwächen beibehalten.
> Ich wollte usprünglich auch einen Pascalcompiler schreiben, aber schon> die ganz kleine Recherche (deutsche! Wikipedia) hat mich davon> überzeugt, dass das Unsinn ist. Deshalb Oberon, sagen wir Pascal mit> Objekten. Kein Mensch programmiert mehr in K&R-C, aber für Pascal> wird noch immer die 1972er-Version zum Vergleich herangezogen.>> Da wir hier ja unter uns sind, das kannst du schon ernst nehmen:> Der Modulimport inklusive Linken funktioniert. Dazu aber bald mehr im> anderen Thread.
Ich wollte den Oberon-Compiler auch keinesfalls gering schätzen --
dessen Autor ist einer der wenigen hier im Forum, der überhaupt mal
etwas gemacht hat, statt wie üblich nur dumm und gefräßig
herumzulungern.
Wenn man allerdings einige der modernen Compilerbauer betrachtet, dann
kommen einem selbst die Oberon-Compiler der ETH recht primitiv vor. Und
mit denem haben sich Generationen vom Doktoranden über Jahre
beschäftigt. Ich selbst habe Oberon über einige Jahre verwendet, es ist
eine eher schlichte Sprache, die ich C vorziehen würde, wenn es denn
einen freien, ahnlich guten Compiler wie gcc gäbe. Aber wenn man mal
Ruby oder Python verwendet hat, sieht man doch, dass Oberon eben doch in
den 90 er Jahren des letzten Jahrhunderts stehen geblieben ist. Und etwa
Nim bietet die wesentlichen merkmale vom Ruby oder Python (und noch sehr
viel mehr!) verbunden mit der Performance von C und durch die native
Codegenerierung ist eben auch der Einsatz auf kleinen Mikrocontrollern
möglich. Da bleibt für Oberon nicht mehr viel Raum. Wobei es jetzt
wiederum auch zu Nim durchaus Alternativen gibt, etwa Rust oder D. Die
haben allerdings leider die mir nicht so behagende {} Syntax, aber das
ist eben Geschmacksache. (Rust erscheint mir persönlich doch eine eher
schwierig zu erlernende Sprache zu sein.) Oder vielleicht auch Crystal
mit Ruby Syntax und LLVM Backend, aber davon habe ich erst kürzlich zum
erstem mal gehört.
Hallo Adrian,
Adrian schrieb:> noch viel offensichtlicher wird es wenn man sich die existierenden C> Bücher anschaut.> Es gibt eigentlich nicht eins wo es nicht sofort heißt..das ist quatsch,> der Autor hat keine Ahnung der ist zu Dumm und hält sich nicht an den> Ansii Standards etc pp :-)
Mir würde da ganz spontan einfallen:
- "Programmieren in C" (Kernighan + Ritchie)
Und dann:
- "Programmieren in der UNIX-Umgebung" (Stevens)
- "Programmieren von UNIX-Netzwerken" (Stevens)
- "Linux/UNIX-Systemprogrammierung" (Kofler, IIRC)
Sind halt dicke Wälzer, klar. Niemand hat behauptet, C sei einfach. Das
ist auf diesem Niveau allerdings keine Programmiersprache. Aber wer eins
dieser Bücher gelesen hat und das Gelesene anwenden kann, ist sicherlich
kein totaler Anfänger mehr.
Nur für AVRs kann man auch mit "AVR-Mikrocontroller in C programmieren"
und dem "AVR Kochbuch" weiter kommen -- aber nicht sehr weit in C. Aber
das ist der Punkt: wer mit seinem Werkzeug umgehen kann, wird in Pascal
oder C, Object Pascal oder C++ effizient arbeiten.
> Das fängt schon mit void main(void) an
Das Betriebssystem erwartet einen Rückgabewert, und daher ist "void
main(void)" immer falsch -- es muß also mindestens "int main(void)"
heißen. Auch das ist IIRC erst in den neueren Standards erlaubt.
In C++11 ist es IIRC sogar zulässig, bei "int main(void)" das "return"
am Ende des Hauptprogramms wegzulassen. Trotzdem halte ich es für guten
Stil es hinzuschreiben -- aber sauberer Stil ist: immer eine Frage der
eigenen Erfahrung und dann: eine des persönlichen Geschmacks. Ich mag
eben lieber deskriptiven Quellcode und verkneife mir syntaktischen
Zucker.
> In PAscal stellt man eine Frage und bekommt innerhalb weniger Minuten> 2-3 Beispiele mit das besipiel ist gut, Du kannst es auch auch so amchen> dann sparst Du dir xy :-9
Das gibt es in C ganz genauso. Gemeckert wird nach meiner Erfahrung nur,
wenn man sieht, daß der Frager seine Hausaufgaben nicht gemacht hat. :-)
Liebe Grüße,
Karl
le x. schrieb:> C verfolgt da eben ein anderes Konzept. Es wird soviel wie möglich in> standardisierte Bibliotheken verlagter (printf und Co.), der Sprachkern> bleibt schlank.> Pascal geht eben einen anderen Weg.>> Welcher Weg nun besser ist kann man drüber streiten.
Das, was du da sagst, ist vollständig, also im Grundsatz falsch, denn in
irgend einer Bibliothek oder einer Header-Datei kann man nichts
unterbringen, was nicht schon zuvor in der grundlegenden
Sprach-Konstruktion vorgesehen ist.
Wenn also irgend ein Element nicht schon von Anfang an in der Sprache
definiert ist, kann man seine Funktionalität niemals mittels irgend
welcher Bibliotheken etc. herbeiführen.
Denk mal an das Erzeugen eines Objektes. Natürlich kann man in C ein
struct kreieren, wo man neben diversen Variablen auch Zeiger auf
Funktionen einbaut, aber ein Objekt wird daraus nie und nimmer.
Ein anderes Beispiel ist das von dir genannte printf und Konsorten. Das
ist zwar mit Hilfe von fast hirnrissig zu nennenden va_arg und so in C
darstellbar - aber zu welchem Preis? hast du jemals dir auch nur einen
Gedanken über die Folgen gemacht? Nein? Nun, zu jedem printf gehört ein
Foematstring und dazu eben ein Klartextinterpreter, der in so ein
Programm, das printf benutzt, eben eingebettet werden muß. Der wiederum
muß mit allen möglichen Formatstrings zurechtkommen und ist deshalb eben
sowohl langsam als auch umfänglich.
Der ingenieurtechnische Knackpunkt beim Vergleich von printf zu write
ist, daß write keine Funktion ist und deshalb vom Compiler komplett zur
Übersetzungszeit aufgelöst wird - printf hingegen nicht. Ganz klar:
printf ist verschwenderischer und komplett unökonomischer als write.
Obendrein braucht write keine solche aberwitzige Konstruktion wie
va_arg.
Der Weg von C ist erwiesenermaßen ein Holzweg. Es ist - wie ich schon
schrieb - eben nur vom Denken bis zum eigenen Mützenrand geprägt, eben
ohne Weitsicht. Damals wurde printf als "die viel weitsichtigere"
Methode als write gepriesen - aber das war und ist ein hirnrissiger
Trugschluß.
Genau so ergeht es der völlig fehlenden Stringverarbeitung in C. Kannst
du dir eigentlich vorstellen, wie unsäglich oft die char's in
irgendwelchen Arrays in C abgezählt werden, bloß um die Länge eines
Strings zu ermitteln? Wie oft genau dieses selbst in
Laufzeitbibliotheken vorkommt und wieviel Rechenzeit weltweit für diesen
Stumpfsinn drauf geht? Auch hier ist die Pascal-Methode der C-Methode
haushoch überlegen.
Kurzum, jeder Laffe mag darüber streiten, aber dem Fachmann ist es
völlig klar, daß der Weg von Pascal von Anfang an der bessere ist und
sich deshalb ein Streit darüber als sinnlos erweist.
Karl Käfer schrieb:> Die beste> Programmiersprache ist in der Praxis unbrauchbar, wenn es keine> Werkzeuge, keine Bibliotheken, oder keine Dokumentation dafür gibt.
Ja, leider ist das nur zu wahr, was du da schreibst. Aber man versuche
mal, etwas gegen die Uneinsichtigkeit zu tun.. Es ist leider vergebens.
Es sollte unsereins aber nicht davon abhalten, die Dinge zu erkennen und
beim Namen zu nennen.
Adrian schrieb:> noch viel offensichtlicher wird es wenn man sich die existierenden C> Bücher anschaut.> Es gibt eigentlich nicht eins wo es nicht sofort heißt..das ist quatsch,> der Autor hat keine Ahnung der ist zu Dumm und hält sich nicht an den> Ansii Standards etc pp :-)
Naja.. im Prinzip stimmt der Spruch "RTFM" schon. Aber das ist leider
eines der Grundprobleme von C. Diese Sprache ist nämlich nicht logisch
aufgebaut, sondern eher in einer Art, die ich als "diktatorisch"
bezeichnen würde. Man muß in dieser Sprache eben eine erhebliche Menge
an Dingen einfach auswendig lernen - auch dann, wenn diese Dinge ganz
offensichtlich unlogisch sind. Beispiel? A+1 ergibt bitte was? Nun, das
hängt vom Datentyp von A ab. Schick.. was?
Nein, C ist nicht wirklich zum Lösen von Problemen gedacht, sondern zum
"Sich-Ausleben" von Programmierern, denn es ist völlig unnötigerweise
durch das Betonen von Satzzeichen und das Minimieren von
Schlüsselwörtern so schwierig zu erlernen, daß darüber das Konzentrieren
auf die eigentlichen Probleme in's Abseits gerät. Für eine
problemorientierte höhere Programmiersprache ist aber das Gegenteil
gefordert: Eine Sprache, deren Erlernbarkeit leicht ist, so daß man sich
auf die eigentlich zu lösenden Probleme konzentrieren kann. C kann sowas
nicht leisten.
Karl Käfer schrieb:> Das Betriebssystem erwartet einen Rückgabewert, und daher ist "void> main(void)" immer falsch -- es muß also mindestens "int main(void)"> heißen. Auch das ist IIRC erst in den neueren Standards erlaubt.
Hier sieht man mal wieder die Mützenrand-Denke. Ich kenne eigentlich
kein µC-System, wo man aus 'main' wieder zurückkehrt. Wohin auch, da es
ja kein Betriebssystem gibt. Natürlich wäre es eine durchaus machbare
Sache, auf eine Funktion 'mains' schlichtweg zu verzichten und einen
Funktionsnamen eigener Wahl (z.B. myfirst) zu verwenden, was dann inm
Startup-Code etwa so aussehen könnte:
LDR R0, =myfirst
BLX R0
und eine Funktion void myfirst(void) möglich machte.
Man könnte es.. aber kaum einer guckt wirklich so weit über den
Tellerrand.
W.S.
W.S. schrieb:> Der ingenieurtechnische Knackpunkt beim Vergleich von printf zu write> ist, daß write keine Funktion ist und deshalb vom Compiler komplett zur> Übersetzungszeit aufgelöst wird - printf hingegen nicht.
Doch. Da printf teil des C-Standards ist, darf der Compiler Annahmen zum
Verhalten von printf treffen und es entsprechend wegoptimieren.
Aus diesem Trivialprogramm:
1
#include<stdio.h>
2
3
intmain(void){
4
volatilechar*s="Hallo Welt";
5
printf("%s\n",s);
6
return0;
7
}
erzeugt der gcc was ohne printf:
1
...
2
volatile char *s = "Hallo Welt";
3
printf("%s\n", s);
4
8048311: 68 a0 84 04 08 push $0x80484a0
5
8048316: e8 b5 ff ff ff call 80482d0 <puts@plt>
6
...
W.S. schrieb:> Natürlich wäre es eine durchaus machbare> Sache, auf eine Funktion 'mains' schlichtweg zu verzichten und einen> Funktionsnamen eigener Wahl (z.B. myfirst) zu verwenden, was dann inm> Startup-Code etwa so aussehen könnte:>> LDR R0, =myfirst> BLX R0>> und eine Funktion void myfirst(void) möglich machte.> Man könnte es.. aber kaum einer guckt wirklich so weit über den> Tellerrand.
Gerade ausprobiert: Klappt.
W.S. schrieb:> Andreas H. schrieb:>> Also Lisp als neu erfundene (!!) ''"grandiosere" Sprache'' aufzulisten>> ist mutig aber lustig.>> Ähemm.. kannst du lesen? Ich meine nicht nur die Buchstaben, sondern> auch die Satzzeichen. Oder anders gesagt: das war ein ZITAT, weswegen> es auch in den doppelten Hochkommas (vulgo Gänsefüßchen) steht.>
Aha. Du zitierst WAS ??? Ich habe da keine Quelle gesehen. Anyway, der
Sinn meines Kommentars ist Dir offensichtlich entgangen.
> Andreas H. schrieb:>> Und willst Du wirkich heute noch Fortran IV hacken ?>> Ich selber nicht, aber ich kenne einige Leute, die ihre Berechnungen> immer noch in Fortran machen.
Den Neffen eines Schwagers der Tante eines Bekannten ?
Ich wage mal frech zu bezweifeln, dass Deine Leute Fortran IV hacken.
Der aktuelle Standard ist "geringfügig" neuer & geändert (so 2008 oder
so).
Auch hier, mangels Fortran-IV Kenntnissen, den Witz nicht verstanden,
schade^^
/regards
Andreas
W.S. schrieb:> Natürlich wäre es eine durchaus machbare> Sache, auf eine Funktion 'mains' schlichtweg zu verzichten und einen> Funktionsnamen eigener Wahl (z.B. myfirst) zu verwenden, was dann inm> Startup-Code etwa so aussehen könnte:>> LDR R0, =myfirst> BLX R0>> und eine Funktion void myfirst(void) möglich machte.> Man könnte es.. aber kaum einer guckt wirklich so weit über den> Tellerrand.
Natürlich ist das machbar.
Aber wieso sollte ich im Startup-Code rumhacken?
Den lass ich lieber unangetastet, bzw. so wie er ausgelifert wurde.
Mein Nachteil dadurch: mein C-Einsprungspunkt heißt "main" und nicht
"myPersonalFirstFunction". Damit kann ich leben.
Zumal eh jeder der sich Fremdcode ansieht erstmal nach der main sucht,
und nicht nach myPersonalFirstFunction.
W.S. schrieb:> Das, was du da sagst, ist vollständig, also im Grundsatz falsch, denn in> irgend einer Bibliothek oder einer Header-Datei kann man nichts> unterbringen, was nicht schon zuvor in der grundlegenden> Sprach-Konstruktion vorgesehen ist.>> Wenn also irgend ein Element nicht schon von Anfang an in der Sprache> definiert ist, kann man seine Funktionalität niemals mittels irgend> welcher Bibliotheken etc. herbeiführen.
Hm, mein C-Standard kennt keine Netzwerkprotokolle, trotzdem gibts zig
Bibliotheken die das implementieren. Wie machen die das wenn es nicht im
Standard definiert wurde? Magic?
> Denk mal an das Erzeugen eines Objektes.
Ah darum gehts dir. Du willst die Sprache selbst um Sprachelemente
erweitern. Dass dieser Vergleich hinkt ist dir schon klar oder?
Ausgangs ging es um das Nachreichen von Datentypen mittels stdint.h, und
das geht ja (wie man sieht).
W.S. schrieb:> Ganz klar:> printf ist verschwenderischer und komplett unökonomischer als write.
Ja mag sein. Wobei schlaue Compiler da nachhhelfen. Aber OK, ja, printf
ist schlechter als write. Nimm dir nen Keks :-)
(Wobei es Stoustrup geschafft hat das noch zu toppen, aber das ist ein
anderes Thema...)
W.S. schrieb:> denn es ist völlig unnötigerweise> durch das Betonen von Satzzeichen und das Minimieren von> Schlüsselwörtern so schwierig zu erlernen, daß darüber das Konzentrieren> auf die eigentlichen Probleme in's Abseits gerät.
Das ist aus zwei Gründen Unsinn:
1) Subjektive Wahrnehmung. Ich tu mich mit { } leichter als mit den
BEGIN END Eskapaden in Captain Capslock-Manier, die mich beim Öffnen
eines (COBOL-, BASIC-) Pascalprogrammes anschreien und die Sicht auf
"die Geschäftslogik" erschweren.
Und 2):
> aber dem Fachmann ist es> völlig klar, daß der Weg von Pascal von Anfang an der bessere ist
Diesem Fachmann sollte doch dann ein { } kein Problem bereiten? Der
Fachmann analysiert den Sprachkern, die Mächtigkeit einer Sprache.
Syntax und Schlüsselwörter sind Mittel zum Zweck. Die lassen den
Fachmann kalt.
Es sei denn er will absichtlich provozieren.
W.S. schrieb:> C ist nicht wirklich zum Lösen von Problemen gedacht
Und löst trotzdem Millionen von Problemen weltweit. Und das obwohl es
dazu nicht gedacht war. Find ich eine beachtliche Leistung :-)
Hallo W.,
W.S. schrieb:> Kurzum, jeder Laffe mag darüber streiten, aber dem Fachmann ist es> völlig klar, daß der Weg von Pascal von Anfang an der bessere ist und> sich deshalb ein Streit darüber als sinnlos erweist.
Wie willst Du denn beurteilen, was einem Fachmann klar ist? Der "Weg von
Pascal" war am Anfang einfach nur lächerlich. Am Anfang durften Strings
eine Maximallänge von 255 Zeichen haben, was schon damals niemand ernst
nehmen konnte. Das ursprüngliche Pascal war daher, über die Funktion als
einfache Lernsprache hinaus, schlicht und ergreifend unbrauchbar. Darum
hat das damalige C mit seinen Stärken und Schwächen bis heute überlebt,
während das damalige Pascal heute einfach nur noch tot ist.
> Karl Käfer schrieb:>> Das Betriebssystem erwartet einen Rückgabewert, und daher ist "void>> main(void)" immer falsch -- es muß also mindestens "int main(void)">> heißen. Auch das ist IIRC erst in den neueren Standards erlaubt.>> Hier sieht man mal wieder die Mützenrand-Denke. Ich kenne eigentlich> kein µC-System, wo man aus 'main' wieder zurückkehrt.
Die Mützenrand-Denke ist ganz bei Dir. C wurde originär nicht für uCs
geschrieben, sondern für UNIX-Betriebssysteme, und diese erwarten nun
einmal einen Rückgabewert.
Liebe Grüße,
Karl
>Das ursprüngliche Pascal war daher, über die Funktion als>einfache Lernsprache hinaus, schlicht und ergreifend unbrauchbar.
UND es ist immer noch ein Lernsprache aber JETZT ist es nicht mehr
unbrauchbar (wie Strings JETZT in z.B. XE7 funktionierten getraust dich
wohl nicht mit C/C++ zu vergleichen ;-) )
Hallo Robert,
Robert L. schrieb:>>Das ursprüngliche Pascal war daher, über die Funktion als>>einfache Lernsprache hinaus, schlicht und ergreifend unbrauchbar.>> UND es ist immer noch ein Lernsprache aber JETZT ist es nicht mehr> unbrauchbar
Deswegen ist es immer noch Schwachsinn und eines Fachmannes nicht
würdig, das, was nach vielen Jahren und Verbesserungen aus Pascal
geworden ist, mit dem zu vergleichen, was C von vorneherein gewesen und
bis heute immer noch geblieben ist. Der Ansatz von C war offenbar
zukunftsfähig genug, um sich in vielen Anwendungsgebieten durchzusetzen
und bis heute zu halten. Der Ansatz von Pascal war offensichtlich nicht
zukunftsfähig, denn trotz vieler Verbesserungen und Erweiterungen führen
Pascal und seine Derivate bis dato nur ein karges Nischendasein.
Und trotz seiner Leistungs- und Zukunftsfähigkeiten wurde C obendrein
auch noch weiterentwickelt, nämlich zu C++, das in der
Anwendungsentwicklung weiter verbreitet ist, als es Pascal und alle
seine Abkömmlinge zusammen je gewesen sind. Insofern hat Pascal zwar
zweifellos an Brauchbarkeit zugelegt, aber seiner Popularität hat das
trotzdem nicht viel genutzt. Warum nur? Nein, mal ehrlich: wenn diese
Programmiersprache so toll ist, wie ihre Zeloten behaupten, warum ist
sie dann nicht weiter verbreitet und fristet dieses Nischendasein? Man
sollte doch erwarten, daß eine so tolle Sprache mehr Entwickler von
ihren Vorzügen überzeugen kann.
> wie Strings JETZT in z.B. XE7 funktionierten getraust dich> wohl nicht mit C/C++ zu vergleichen ;-)
Warum sollte ich die Stringfunktionen von Object-Pascal nicht mit denen
von C++ vergleichen? C++-Strings sind ausgesprochen leistungsfähig --
und wer noch mehr Spaß haben will, wird bei Boost und / oder Qt fündig.
Liebe Grüße,
Karl
"daß eine so tolle Sprache mehr Entwickler von
ihren Vorzügen überzeugen kann" a
aus dem gleichen grund aus dem nahezu 90% alle Pcs mit Windows
laufen..wir drehen uns im Kreis :-)
Das war ziemlcih am Anfang der Diskussion...
desweiteren ist das ja einer der Pro Argumente FÜR Pascal, das es sich
weiterentwicklelt
Hallo Kim,
Kim Schmidt schrieb:> "daß eine so tolle Sprache mehr Entwickler von> ihren Vorzügen überzeugen kann" a> aus dem gleichen grund aus dem nahezu 90% alle Pcs mit Windows> laufen..
Da gibt es nur einen kleinen, aber feinen Unterschied: hinter Windows
und Pascal stehen größere Unternehmen mit Marketingbudgets, hinter C und
C++ nicht. Auch das würde eher für Pascal und gegen C sprechen, aber die
Realität sieht eben anders aus -- und dafür gibt es zweifellos
sachlichere Gründe als die berühmten Fliegen.
> desweiteren ist das ja einer der Pro Argumente FÜR Pascal, das es sich> weiterentwicklelt
Das tut C ja auch -- es heißt dann eben C++.
Liebe Grüße,
Karl
"Das tut C ja auch -- es heißt dann eben C++."
eben genau das ist nicht vergleichbar, siehe Diskussion weiter oben oder
war es ein anderer Threat? egal
Tja, das liegt wohl eher daran , das Borland es damals nicht gebacken
bekam mit Turbo Pascal für Windows....leider
Erst danach mit Delphi taugte es wieder was, nur das es da zu spät war
Joachim Drechsel schrieb:> 1 Seite Pascal = 1 Zeile C.
Genau! Das werden die Pascaljuenger dann merken wenn die Gelenke in den
Finger im Alter nicht mehr so wollen und fuer jeden nicht getippten
Buchstaben dankbar sein. :=)
C oder Pascal? Komische Frage. Kommt darauf an was man will.
Rainer S. schrieb:> Habe ein Hauptprojekt (PC Programm) geschrieben in Pascal.> Pascal als Sprache gefällt mir sehr gut.
Ja dann bleib doch dabei. C ist aber vielerorts ein de facto Standard
den man als Profi schlecht ignorieren kann. Da nützt es auch nichts
seitenlang zu diskutieren warum das so ist und ob andere Sprachen Exoten
sind oder nicht.
C hab ich spät gelernt als ich nicht mehr drumherum kam. War ne harte
Schule hat sich aber gelohnt.
Was ich an der Sprache schätze und hier noch nicht aufgeführt wurde) ist
die Möglichkeit in "Steno" schreiben zu können was Konzepte bzw.
Prototypen sehr schnell zum laufen bekommt. Die Freiheit von C hat aber
ihren Preis, eine falsche Bewegung und schon fährt man gegen den
(virtuellen) Baum.
Karl Käfer schrieb:> Deswegen ist es immer noch Schwachsinn und eines Fachmannes nicht> würdig, ...
Meiner Meinung nach sind solche Diskussionen etwas kindisch. Auch ist
der Bezug auf eine anonyme Autorität sinnlos. Es gibt nun mal keine
einheitliche Meinung, auch nicht unter Fachleuten. Andernfalls wäre eine
Diskussion esoterisch, so sinnvoll wie über die Regeln von Kirchhoff.
W.S. schrieb:> A+1 ergibt bitte was? Nun, das> hängt vom Datentyp von A ab. Schick.. was?
Ja. Auch in Pascal übrigens und das ist schon gut so wie es ist.
Hallo X4U,
X4U schrieb:> Karl Käfer schrieb:>> Deswegen ist es immer noch Schwachsinn und eines Fachmannes nicht>> würdig, ...>> Meiner Meinung nach sind solche Diskussionen etwas kindisch. Auch ist> der Bezug auf eine anonyme Autorität sinnlos.
Es wäre mir neu, daß ich mich auf Autoritäten beziehen müßte, nichtmal
auf anonyme. Mir reichen die Tatsachen vollständig aus. ;-)
Tatsächlich spreche ich primär darüber, daß C seit dreißig Jahren nahezu
unverändert benutzt wird und es darum einfach unsinnig ist, es mit einer
zwar ähnlich alten Sprache zu vergleichen, die in dieser Zeit aber viele
erhebliche Änderungen und Modernisierungen erfahren hat.
> Es gibt nun mal keine einheitliche Meinung, auch nicht unter Fachleuten.
Sowohl hinsichtlich des Erfolges von C, als auch hinsichtlich der
Historie der Änderungen an C ist die Sache im Vergleich mit Pascal aber
jedenfalls absolut eindeutig. Man muß kein Fachmann sein, um das zu
erkennen.
Und wenn dann hier einer aufpoppt, die Stringverarbeitung von Pascal im
Jahre 2014 für absolut überlegen gegenüber der von C aus dem Jahr 1972
erklärt, und alle, die das anders sehen, pauschal als "Laffen" bepöbelt,
dann muß man ihn einmal erinnern, wie die Sache im ursprünglichen Pascal
von 1971 ausgesehen hat -- nämlich für ernsthafte Anwendungen in jeder
Hinsicht unbrauchbar. Auch zu dieser Erkenntnis bedarf es weder einer
ausgewiesenen Expertise, noch einer anonymen Autorität.
Letztlich ist die Sache eindeutig: C ist der etablierte
Industriestandard, und Pascal hat es trotz angeblicher Vorteile, trotz
vieler Verbesserungen und Modernisierungen und trotz der Tatsache, daß
eine kommerzielle Firma mit Marketingbudget und Werbeabteilung seine
Verbreitung fördert, nicht geschafft, an diesem Industriestandard auch
nur ansatzweise zu kratzen.
All das sind für Hobbyisten zunächst noch keine Argumente für oder gegen
Pascal oder C. Das Argument ist die Folge des vorgenannten: daß es für
den Industriestandard eine riesige Infrastruktur an Werkzeugen,
Bibliotheken und Dokumentationen gibt. Und das ist wohl ein besseres
Argument als "ich kann es besser lesen" von ah. oder die genannten
"Laffen" von W.S..
Trotzdem kann man, zumindest als Hobbyist, jederzeit und gerne bei
Pascal bleiben. Kein Problem, macht doch watt Ihr volt. Mach ich ja
auch. ;-)
Liebe Grüße,
Karl
Karl Käfer schrieb:> nicht geschafft, an diesem Industriestandard auch> nur ansatzweise zu kratzen.
Doch, 2% sind schon ansatzweise. 99% aller Sprachen sind weniger beliebt
oder bekannt. Allein die Tatsache daß es solche erhitzten Threads
hervorrufen kann wo die Gegner dann mit hochroten Köpfen ins Schwitzen
geraten sagt einiges über seine Kraft.
Bernd K. schrieb:> Allein die Tatsache daß es solche erhitzten Threads> hervorrufen kann wo die Gegner dann mit hochroten Köpfen ins Schwitzen> geraten sagt einiges über seine Kraft.
Du meinst solche Threads, wie diesen hier, in dem die C-Gegner mit
allerlei Halbwissen zu Felde ziehen? Und erstmal viel Zeit und Arbeit in
die Aufklärung fließen muss, um eine anständige und faire Diskussion zu
ermöglichen. Ja da kommt dann schon mal die Wut hoch.
Lukas K. schrieb:> Doch. Da printf teil des C-Standards ist, darf der Compiler Annahmen zum> Verhalten von printf treffen und es entsprechend wegoptimieren.
Du redest jetzt aber nicht von der Sprache C, sondern davon, was
inzwischen sehr weit "ausgebuffte" Compiler an Effizienz beim Kampf
gegen C erreichen können. Das ist ein dezenter Unterschied zum
Sprachentwurf, gelle? Grundsätzlich muß man aber davon ausgehen, daß
sowas wie printf eben nicht zum Auseinandernehmen und Wegoptimieren
durch den Compiler gedacht ist.
Ach ja, irgendwie ärgert es einen schon, daß hier so heftig und
unsachlich diskutiert wird und seitens der C-Leute so empfindlich
lamentiert wird. Aber andererseits ist es genau dieses, worüber ich mir
ein Grinsen nicht verkneifen kann.
Zusätzlich konnte man im bisherigen Verlaufe sehen, wie unfähig oder
unwillig die hier versammelten Diskutierer sind, auf Sachargumente auch
sachlich einzugehen. Mir kommt das vor wie Kinder, die sich die Ohren
zuhalten und mit den Füßen aufstampfen. "RIDICCULUS" hieß das wohl bei
Harry Potter.
Tja, recht possierlich ist es schon, daß sich bei einem (Achtung, Zitat)
"Kurzum, jeder Laffe mag darüber streiten," offenbar ALLE angesprochen
fühlen. Nun gut, ich nehme das genau so zur Kenntnis. Grins..
Doch an genau dieser Stelle komme ich auf den Anfang zurück:
Rainer S. schrieb:> Ich überlege jetzt evtl. auf C umzusteigen bevor es "zu spät" ist.
Dazu meine Antwort an den TO:
Denke nicht an irgend ein "Umsteigen", sondern an ein "Auch Benutzen".
Bewahre die Vielfalt und die eigene Flexibilität im Kopfe. Nichts ist
schlimmer als eine Selbstbeschränkung auf irgendeine spezielle Sparte
bzw. Programmiersprache.
Es gibt eine Menge Leute, die sowohl in Pascal als auch in C
programmieren. Und die eigentlichen Fachleute sind diejenigen, die die
Vorzüge, Nachteile, Grenzen und Stärken der jeweiligen Sprachen kennen
und eben nicht wie Fanboys lamentieren.
Leute, entweder hattet ihr keinen Oster-Urlaub, oder er hat euch nicht
gut getan.
Amen.
W.S.
Hallo Bernd,
Bernd K. schrieb:> Karl Käfer schrieb:>> nicht geschafft, an diesem Industriestandard auch>> nur ansatzweise zu kratzen.>> Doch, 2% sind schon ansatzweise.
Wo kommt eigentlich diese Zahl her?
> 99% aller Sprachen sind weniger beliebt oder bekannt.
Da ist sicher was dran, aber die sind doch nicht der Maßstab. Der
Maßstab im Bereich der Systemprogrammierung ist, momentan und schon seit
geraumer Zeit, nun einmal C. Und derzeit sieht es wohl nicht danach aus,
als würde sich das in absehbarer Zukunft ändern.
Liebe Grüße,
Karl
Karl Käfer schrieb:> Hallo X4U,
Selber Hallo ;-)
> Es wäre mir neu, daß ich mich auf Autoritäten beziehen müßte, nichtmal> auf anonyme. Mir reichen die Tatsachen vollständig aus. ;-)
Sorry, hab ich falsch zitiert. Auf den Pascal Spezi der meint das Wort
"Fachleute" sei ein Argument wollte ich antworten.
> Sowohl hinsichtlich des Erfolges von C, als auch hinsichtlich der> Historie der Änderungen an C ist die Sache im Vergleich mit Pascal aber> jedenfalls absolut eindeutig. Man muß kein Fachmann sein, um das zu> erkennen.
Die Diskussion an sich ist doch sinnlos. So ist z.B. ein in der
süddeutschen Provinz beheimateter Stadtverein die mit Abstand
erfolgreichste Marke im bezahlten Fußball hierzulande. Trotzdem kann ich
diese Firma nicht leiden da ich zusammengekaufte Legionärstruppen nun
mal für reines Business und nicht für Sport halte (von dem weibisch
unsportlichen Gekeife des "Marktführers" wenn Sie sich mal benachteiligt
fühlen ganz zuschweigen).
Will damit sagen das aus Historie und Erfolg nichts zu schließen ist.
Müßig darüber zu diskutieren oder zu streiten (wie über die Platzierung
in der Bundesliga).
Die Einzelheiten sind natürlich hilfreich. Da hier aber Fakten zählen
wird es für spätpubertäre Hahnenkämpfer (womit ich nicht dich meine)
naturgemäß langweilig.
Hallo W.,
W.S. schrieb:> Du redest jetzt aber nicht von der Sprache C, sondern davon, was> inzwischen sehr weit "ausgebuffte" Compiler an Effizienz beim Kampf> gegen C erreichen können. Das ist ein dezenter Unterschied zum> Sprachentwurf, gelle? Grundsätzlich muß man aber davon ausgehen, daß> sowas wie printf eben nicht zum Auseinandernehmen und Wegoptimieren> durch den Compiler gedacht ist.
Dann benutz' doch puts(3) oder write(2) oder C++-Streams. Es ist ja
nicht so, als ob es keine Alternativen zu printf(1) gäbe. Tipp: Du
kannst Deine Ahnungslosigkeit nicht verbergen, indem Du große Töne
spuckst.
> Zusätzlich konnte man im bisherigen Verlaufe sehen, wie unfähig oder> unwillig die hier versammelten Diskutierer sind, auf Sachargumente auch> sachlich einzugehen.
Auf genau welche Sachargumente hätte man denn eingehen können? Bisher
hast Du nur provoziert und gepöbelt. Zu mehr bist Du wohl nicht fähig.
Trotzdem liebe Grüße,
Karl
Hallo X4U,
X4U schrieb:>> Es wäre mir neu, daß ich mich auf Autoritäten beziehen müßte, nichtmal>> auf anonyme. Mir reichen die Tatsachen vollständig aus. ;-)>> Sorry, hab ich falsch zitiert. Auf den Pascal Spezi der meint das Wort> "Fachleute" sei ein Argument wollte ich antworten.
Ok. :-)
> Die Diskussion an sich ist doch sinnlos. So ist z.B. ein in der> süddeutschen Provinz beheimateter Stadtverein die mit Abstand> erfolgreichste Marke im bezahlten Fußball hierzulande. Trotzdem kann ich> diese Firma nicht leiden da ich zusammengekaufte Legionärstruppen nun> mal für reines Business und nicht für Sport halte (von dem weibisch> unsportlichen Gekeife des "Marktführers" wenn Sie sich mal benachteiligt> fühlen ganz zuschweigen).>> Will damit sagen das aus Historie und Erfolg nichts zu schließen ist.
Naja, in diesem speziellen Fall würde der Vergleich ja so aussehen, daß
C ein kleiner Fußballverein mit wenig Geld ist, dessen Spieler, Trainer
und Vereinsführung ausnahmslos aus dem eigenen Nachwuchs kommen und der
trotz dieser Umstände seit Jahren die Liga unangefochten und mit einem
riesigen Abstand anführt. Da drängt sich doch die Frage auf: warum? ;-)
Liebe Grüße,
Karl
>Letztlich ist die Sache eindeutig: C ist der etablierte>Industriestandard,
PHP ist der Industriestandard
J(ava)Script ist der Industriestandard
VBScript ist der Industriestandard
Java ist der Industriestandard
...
es gibt genug bereiche wo niemand auch nur drüber nachdenkt C zu
verwenden..
es gibt genug bereiche wo niemand auch nur drüber nachdenkt C nicht zu
verwenden..
nur weil jemand C/C++ verwendet heißt das ja nicht, dass es dadurch
"besser" wäre, oder dass derjenige der gerne tut...
ich "muss" ja leider auch C Programmieren, im Excel auch mal Basic..
usw.
>Und wenn dann hier einer aufpoppt, die Stringverarbeitung von Pascal im>Jahre 2014 für absolut überlegen gegenüber der von C aus dem Jahr 1972
(hab ich zwar nicht, aber egal..)
und im "selben Satz" schreibst du, dass das "tolle" an C ist, dass seit
eweigen zeiten "unverändert" verwendet wird??
als ob das ein Vorteil wäre, dass man IMMER NOCH mit null-terminierten
strings arbeiten muss...
Karl Käfer schrieb:>> Zusätzlich konnte man im bisherigen Verlaufe sehen, wie unfähig oder>> unwillig die hier versammelten Diskutierer sind, auf Sachargumente auch>> sachlich einzugehen.>> Auf genau welche Sachargumente hätte man denn eingehen können? Bisher> hast Du nur provoziert und gepöbelt. Zu mehr bist Du wohl nicht fähig.
Ja genau den Eindruck habe ich auch. Hier ein Beispiel:
W.S. schrieb:> NSA schrieb:>> Und wo ist da jetzt das Problem mit stdint.h?>> Du hast es nicht kapiert. Einfach überhaupt nicht kapiert.> Kein einziger C-Compiler auf dieser Welt kennt so ein Schlüsselwort wie> uint32_t. Derartige Schlüsselwörter fehlen ganz einfach in der Sprache> C. Und was du da anziehst, ist lediglich ein lumpiges Includefile. Sowas> kann jeder sich selber schreiben, um darin von typedef Gebrauch zu> machen, aber das ist lediglich eine simple Umbenennung. Kannst du das> begreifen oder nicht?
Spuckt hohe Töne und checkt nicht mal selbst was er da schreibt. Mit dem
Headerfile hat er natürlich recht, aber er zieht absolut die falschen
Schlussfolgerung daraus. Denn es macht einfach keinen Unterschied ob die
Typen fix eingebaut sind oder ob ich vor der Verwendung stdint.h
einbinden muss. Der Standard garantiert mir, dass die Typen die
angeforderte Größe haben. Punkt. Dass dies mit normalen C Hausmitteln
realisierbar ist, spricht für C und nicht dagegen.
Robert L. schrieb:> und im "selben Satz" schreibst du, dass das "tolle" an C ist, dass seit> eweigen zeiten "unverändert" verwendet wird??> als ob das ein Vorteil wäre, dass man IMMER NOCH mit null-terminierten> strings arbeiten muss...
C ist ein einfaches und solides Werkzeug mit dem sich so ziemlich jedes
Problem erschlagen lässt, wenn auch nicht immer sonderlich komfortabel.
Jeder kann es so handhaben wie er will. Bei der Low-Level Programmierung
(µC, OS Entwicklung) ist C aber nach wie vor gut. Alles ist möglich
statisch angelegt und Stringoperationen kommen kaum vor. Genau dafür
wurde C konzipiert. Auf dem PC nehme ich hingegen lieber C++.
Hallo Robert,
Robert L. schrieb:>>Letztlich ist die Sache eindeutig: C ist der etablierte>>Industriestandard,>> PHP ist der Industriestandard
Naja, PHP ist im Bereich der Webseitenentwicklung aber bei Weitem nicht
so unangefochten wie C im Bereich der Systemprogrammierung. Perl, Python
und Ruby, aber auch Java haben hier signifikante Marktanteile.
> J(ava)Script ist der Industriestandard
Java- bzw. ECMA-Script ist der unangefochtene Industriestandard im
Bereich der interaktiven Webseiten.
> VBScript ist der Industriestandard
Eigentlich nicht. VB und VBA sind eine andere Geschichte, aber VBScript
war immer nur ein kleines Lichtlein und ist zudem schon abgekündigt.
> Java ist der Industriestandard
Java ist zweifellos ein Industriestandard in der Anwendungsentwicklung,
aber keineswegs unangefochten; hier haben C++, C#, C und sogar Pascal
durchaus Marktanteile.
All das ändert aber nichts daran, daß C der etablierte Industriestandard
im Bereich der Systemprogrammierung und der Embedded-Entwicklung ist und
aller Wahrscheinlichkeit nach auf absehbare Zeit bleiben wird. Alle vier
der verbreitetsten Betriebssystemkerne sind in C oder seiner moderneren
Schwester Objective-C implementiert -- und ob letzteres eine gute Idee
gewesen ist, wird sich erst in ein paar Jahren herausstellen.
Liebe Grüße,
Karl
Hallo Robert,
Robert L. schrieb:>>Und wenn dann hier einer aufpoppt, die Stringverarbeitung von Pascal im>>Jahre 2014 für absolut überlegen gegenüber der von C aus dem Jahr 1972>> (hab ich zwar nicht, aber egal..)
Du warst auch nicht gemeint.
> und im "selben Satz" schreibst du, dass das "tolle" an C ist, dass seit> eweigen zeiten "unverändert" verwendet wird??
Das ist bei langlebigen Projekten tatsächlich ein großer Vorteil.
> als ob das ein Vorteil wäre, dass man IMMER NOCH mit null-terminierten> strings arbeiten muss...
Ach Gottchen ja, es gibt Schlimmeres. Strings mit einer Variablen, die
die Länge festhält, sind genauso bescheuert. Trotzdem kannst Du
natürlich auch jederzeit eine C-String-Library Deiner Wahl wie
bstringlib benutzen, wenn Dir grade danach ist. Allerdings sind
zeichenterminierte Zeichenketten die einzige Implementierung, die
gleichzeitig (beinahe) endlos skaliert und den geringsten möglichen
Overhead hat.
Liebe Grüße,
Karl
>Trotzdem kannst Du>natürlich auch jederzeit eine C-String-Library Deiner Wahl
damit dann jeder seine "liebligs" libray verwendet.. ja, in meinem
Privaten Projekt geht das vielleicht ;-)
>Strings mit einer Variablen, die die Länge festhält
und Refrenzzähler nicht vergessen, und (bei ANSIString) CodePage, aber
warum ist das schlecht??
>endlos skaliert und den geringsten möglichen>Overhead hat.
du meinst, weil man dann in der "Praxis" immer brav 1024 oder 4096
zeichen reserviert um sich von irgend einer funktion einen string der
dann im endeffekt 5Byte lang ist zurückgeben zu lassen... ??
ja, sowas macht keinen Overhead ;-)
Hallo Robert,
Robert L. schrieb:>>Trotzdem kannst Du>>natürlich auch jederzeit eine C-String-Library Deiner Wahl>> damit dann jeder seine "liebligs" libray verwendet.. ja, in meinem> Privaten Projekt geht das vielleicht ;-)
Das kann man auch in einem Team machen, wenn man sich gemeinsam darauf
einigt oder es als begründete Ausnahme dokumentiert.
>>Strings mit einer Variablen, die die Länge festhält>> und Refrenzzähler nicht vergessen, und (bei ANSIString) CodePage, aber> warum ist das schlecht??
Einen Referenzzähler brauchst Du wohl nur, wenn Du so etwas wie eine
automatisierte Garbage Collection einbauen willst. Kann man machen, muß
man aber nicht -- meine Erfahrungen mit sowas sind eher durchwachsen,
vorsichtig ausgedrückt. Auch eine "Codepage" braucht man nicht immer.
>>endlos skaliert und den geringsten möglichen>>Overhead hat.>> du meinst, weil man dann in der "Praxis" immer brav 1024 oder 4096> zeichen reserviert um sich von irgend einer funktion einen string der> dann im endeffekt 5Byte lang ist zurückgeben zu lassen... ??
Leider verstehe ich nicht, was Du mir damit sagen möchtest.
Liebe Grüße,
Karl
"C" ist wie ein Sack voll Süßigkeiten, wie Cola Light oder wie
Kartoffelchips:
Jeder weiß, daß es eigentlich nicht gut ist, aber er stopft es trotzdem
in den Rechner. Warum? Weil es auf der Uni angefüttert wird.
SCNR
Kai Mauer schrieb:> Jeder weiß, daß es eigentlich nicht gut ist, aber er stopft es trotzdem> in den Rechner. Warum? Weil es auf der Uni angefüttert wird.
Auf Unis wird meistens Java gelehrt.
Kai Mauer schrieb:> Jeder weiß, daß es eigentlich nicht gut ist, aber er stopft es trotzdem> in den Rechner. Warum? Weil es auf der Uni angefüttert wird.
1x darfst du raten was ich an der Uni gelernt habe und was ich heute
programmiere ... (ein kleiner Tipp: ich habe nicht C gelernt und heute
programmiere ich nicht in Pascal)
Kai Mauer schrieb:>> 1x darfst du raten was ich an der Uni gelernt habe und was ich heute>> programmiere ...>> Kein Interesse...
dachte ich mir, so läuft ja die ganze "Diskussion" hier, keiner hat ein
Interesse mal über seinen Tellerrand zu schauen
Auf dem Unirechner gabs nur Assembler und Pascal.
C habe ich dann später mal selbst gekauft und gelernt
(damals Aztek). Geil .. Endlich funktioniert mal was.
>> du meinst, Weil man dann in der "Praxis" immer brav 1024 oder 4096>> zeichen reserviert um sich von irgend einer funktion einen string der>> dann im endeffekt 5Byte lang ist zurückgeben zu lassen... ??>Leider verstehe ich nicht, was Du mir damit sagen möchtest.>Liebe Grüße,>Karl
das einfachste aller "Probleme" (int to String)
(nur zum verdeutlichen was ich vom Prinzip her meine,..)
schaut in der Praxis wohl so aus:
char str[15];
sprintf(str, "%d", aInt);
man muss in C erst mal viel zu viel speicher reservieren um dann einen
String der VIELLEICHT (manchmal) so groß ist, platz zu haben
also wie soll diese "konzept" weniger overhead produzieren, als ein
spring der nur (etwas) mehr platz braucht, als er tatsächlich lang ist,
und automatisch nur solange lebt wie er tatsächlich verwendet .. usw.
Robert L. schrieb:> man muss in C erst mal viel zu viel speicher reservieren um dann einen> String der VIELLEICHT (manchmal) so groß ist, platz zu haben
Nein.
1
intsize=snprintf(NULL,0,"%u",1000)+1;
2
char*str=malloc(size);
3
snprintf(str,size,"%u",1000);
4
...
5
free(str);
Ansonsten steht einem der Weg immer noch offen:
1
charstr[50];
2
intsize=snprintf(NULL,50,"%u",1000);
3
if(size>=50)//wenn Puffer zu klein
4
...
Die paar Bytes mehr sind auf dem Stack auch nicht wirklich verschwendet.
Zudem ist die letzte Variante schneller. Also kann man je nach
Anwendungsfall entscheiden was man eher braucht.
Robert L. schrieb:> man muss in C erst mal viel zu viel speicher reservieren um dann einen> String der VIELLEICHT (manchmal) so groß ist, platz zu haben> also wie soll diese "konzept" weniger overhead produzieren, als ein> spring der nur (etwas) mehr platz braucht, als er tatsächlich lang ist,> und automatisch nur solange lebt wie er tatsächlich verwendet .. usw.
Man muss in C gar nichts. Das ist einer der Vorteile.
Das Problem ist ein allgemeines, kein C-spezifisches. Wenn man vorher
nicht weiß, wieviel Platz man braucht, muß man entweder schrittweise
vergrößern, indem man jedesmal einen neuen Puffer allokiert und alles
umkopiert, oder vorher soviel Platz lassen, dass es auf jeden Fall
reicht. Manche Sprachen machen das automatisch im Hinterund, und man
muss damit leben, wie es dort umgesetzt ist.
TriHexagon schrieb:> int size = snprintf(NULL, 0, "%u", 1000) + 1;> char* str = malloc(size);> snprintf(str, size, "%u", 1000);> ...> free(str);
Ich bin ja doch eher pro-C, aber das ist ein schlechtes Beispiel.
2 mal den Formatstring parsen will man eher nicht.
>Man muss in C gar nichts. Das ist einer der Vorteile.
dass ist einer der Nachteile wolltest wohl sagen ?
gerade dieses Beispiel (Buffer zu klein) ist ja das Parade-Beispiel,
welches in den letzten Jahrzehnten zu Millionen von Sicherheitslücken
führte..
aber solche Fehler machen ja nur die anderen.. davon bist du sicher
überzeugt ;-)
Hallo Robert,
Robert L. schrieb:>>> du meinst, Weil man dann in der "Praxis" immer brav 1024 oder 4096>>> zeichen reserviert um sich von irgend einer funktion einen string der>>> dann im endeffekt 5Byte lang ist zurückgeben zu lassen... ??>>>> Leider verstehe ich nicht, was Du mir damit sagen möchtest.>> das einfachste aller "Probleme" (int to String)> (nur zum verdeutlichen was ich vom Prinzip her meine,..)> schaut in der Praxis wohl so aus:>> char str[15];> sprintf(str, "%d", aInt);>> man muss in C erst mal viel zu viel speicher reservieren um dann einen> String der VIELLEICHT (manchmal) so groß ist, platz zu haben
Wenn es wirklich mal auf die paar Bytes in einem Puffer ankommt, rechne
ich vorher aus wie groß der Puffer sein muß:
Karl Käfer schrieb:> Wenn es wirklich mal auf die paar Bytes in einem Puffer ankommt, rechne> ich vorher aus wie groß der Puffer sein muß:> int len_int(int num) {> int neg = 1;> if(num < 0) {> num *= -1;> neg += 1;> }> for(int i = 1; i < 10; ++i) {> if( num < pow((double)10, (double)i) ) {> return i + neg;> }> }> return 0;> }
Da lacht jetzt aber der Delphi/Pascal Benutzer mal kräftig über so eine
Blähung.
Hallo LachtÜberC,
LachtÜberC schrieb:> Karl Käfer schrieb:>> Wenn es wirklich mal auf die paar Bytes in einem Puffer ankommt, rechne>> ich vorher aus wie groß der Puffer sein muß:>> [siehe oben]>> Da lacht jetzt aber der Delphi/Pascal Benutzer mal kräftig über so eine> Blähung.
Tatsächlich? Wie machen das denn Delphi und Pascal? Intern, meine ich?
Abgesehen davon sehe ich auch die "Blähung" nicht. Wo riechst Du denn da
eine "Blähung"? Bitte sei so nett und erklär' mir das. Danke.
Liebe Grüße,
Karl
Mal ne bescheidene Frage: wie wandelt Pascal einen Int nach String?
Das gibt es als Str()-Procedure, der muß man einen Ziel-String mitgeben.
Oder als IntToStr()-Funktion, die einen String zurückliefert. Beide
Varianten allokieren die notwendigen Bytes dezent im Hintergrund vom
Heap. Natürlich wissen beide sowenig wie eine C-Funktion wieviel Platz
sie brauchen.
Nur weil man die Implementierung nicht sieht, bedeutete das nicht, daß
sie über jeden Zweifel erhaben wäre.
BTW, Verwendung von Heap ist doch das, was C++ immer angelastet wird und
was sich "total gut" mit kleinem RAM im μC verträgt. Wie schaltet man
das in Pascal noch mal ab? In C reicht es es nicht zu benutzen.
Bitte nicht falsch verstehen: es gab Zeiten, da hab ich gerne in
(Turbo-)Pascal programmiert. Zu CP/M Zeiten gab es nichts besseres.
Heute ist das anders.
Karl Käfer schrieb:> Tatsächlich? Wie machen das denn Delphi und Pascal? Intern, meine ich?
Delphi macht das so:
function IntToStr(Value: Integer): string;
// FmtStr(Result, '%d', [Value]);
asm
PUSH ESI
MOV ESI, ESP
SUB ESP, 16
XOR ECX, ECX // base: 0 for signed decimal
PUSH EDX // result ptr
XOR EDX, EDX // zero filled field width: 0 for no leading zeros
CALL CvtInt
MOV EDX, ESI
POP EAX // result ptr
CALL System.@LStrFromPCharLen
ADD ESP, 16
POP ESI
end;
Wo ist der Code von CvtInt und System.@LStrFromPCharLen?
So wie das da steht, ist zu befürchten, daß auch noch zwischen den zig
verschiedenen Pascal-String konvertiert wird.
Wie gesagt, nicht falsch verstehen: das ist alles nicht schlimm.
Script-Sprachen sind da noch viel verschwenderischer. Nur, wenn man bei
C meckert, dann muß man hinnehme daß jemand unter den Pascal-Teppich
schaut und dort auch Kehricht findet.
Robert L. schrieb:> das einfachste aller "Probleme" (int to String)> (nur zum verdeutlichen was ich vom Prinzip her meine,..)> schaut in der Praxis wohl so aus:>> char str[15];> sprintf(str, "%d", aInt);>> man muss in C erst mal viel zu viel speicher reservieren um dann einen> String der VIELLEICHT (manchmal) so groß ist, platz zu haben> also wie soll diese "konzept" weniger overhead produzieren, als ein> spring der nur (etwas) mehr platz braucht, als er tatsächlich lang ist,> und automatisch nur solange lebt wie er tatsächlich verwendet .. usw.
Wenn man in Pascal dynamische Strings benutzt, ist das immer mit einem
gewissen Speicher-Overhead verbunden, der gerade bei kurzen Strings wie
in deinem Beispiel schon recht deutlich ins Gewicht fällt.
Beispiel:
Die aus 4 Ziffern bestehende Zahl "1234" kann in C in einem 5 Byte
großen Array gespeichert werden. Bei einem Turbo-Pascal-String (mit
8-Bit-Längeninformation) sind es ebenfalls 5 Bytes. In beiden Fällen
muss man aber natürlich sicherstellen, dass die Zahl tatsächlich maximal
4 Ziffern lang ist.
Komfortabler geht es mit dynamischen Strings, wie es sie in neueren
Pascal-Dialekten (Delphi und Free Pascal) und in C++ gibt. In Free
Pascal auf einem 32-Bit-PC belegt der String "1234" aber immerhin schon
36 Bytes:
Stringdaten einschließlich des abschließenden 0-Bytes: 5 Bytes
9
Füllbytes für eine Chunk-Größe von 16·n 15 Bytes
10
11
————————
12
Alles zusammen: 36 Bytes
Die Routinen Str und IntToStr, mit denen eine Integer-Zahl in einen
String konvertiert wird, erzeugen aber nicht direkt einen AnsiString,
sondern gehen den Umweg über einen temporären ShortString, der für die
Dauer der Konvertierung zusätzlich mit 256 Bytes zu Buche schlägt.
Wie man sieht, bezahlt man den Komfort der dynamischen Strings mit einem
nicht ganz unerheblichen Overhead, den man auf speicherpotenten PCs aber
gerne in Kauf nimmt (weswegen dort nur noch selten in C programmiert
wird). Auf schwachbrüstigen Mikrocontrollern hingegen möchte man diesen
Overhead aber meist vermeiden, weswegen dort C-Strings oder Turbo-
Pascal-Strings meist die bessere Wahl sind, wenngleich deren richtige
Dimensionierung etwas Denkarbeit des Programmierers erfordert.
Yalu X. schrieb:> Wenn man in Pascal dynamische Strings benutzt, ist das immer mit einem> gewissen Speicher-Overhead verbunden
Ich habe, wegen der Kompatibiltät zu Windows APIs, viele Jahre lang in
Delphi mit nullterminierten Strings programmiert, die Funktionen dafür
sind ja genauso vorhanden wie in C - daher kommt mir die Diskussion
relativ lächerlich vor. Man nimmt was man gerade am besten verwenden
kann, ausser natürlich man ist Sprach-Fundamentalist. Wenn ich mehr
Delphi-VCL verwende als direkte WIN32-Funktionen, nehme ich
Delphi-Strings, so what.
Georg
Die "lächerliche Diskussion" begann damit, das man C seine
Null-terminierten String vorgeworfen hat. Diese Aussage wurde dann von
der "Gegenseite" mit ein paar Details der Pacal-Strings garniert.
Wobei die "Gegenseite" in meinem Fall kein Pascal-Hasser ist, sonder
eher ein C-mehr-Möger (und auch ein Rechenmaschinenversteher seit
Jahrzehnten).
Einige Pascal-Freunde fanden aber, daß das einzig Wahre das weniger
Beachtete sein.
Mir ist's egal. Für das Eine hab ich gute&günstige Compiler, das Andere
vermisse ich seit Turbo-Zeiten nicht wirklich.
Fragezeichen? schrieb:> Turbo-Zeiten
Ja, ja, ja, die guten alten Turbo Zeiten. :-)))
Ab Turbo Pascal 5.5 gab es das Schlüsselwort "object". Ab da muss man TP
mit C++ vergleichen. Ich finde C++ besser als C und damit ...
@Oldtimer:
Es stand die Frage im Raum: Pascal oder C?
Da sag ich C.
Fragt jemand nach C oder C++, dann ist die Antwort genau so klar:
Her mit dem Doppelplus!
Auch wenn ich sicher nie alles ausreitzen werde. Einziger
Wermutstropfen: warum gibt es in C++ keine "named address spaces". Das
wäre so schön auf'm kleinen Atmel :-)
Fragezeichen? schrieb:> Turbo-Pascal für CP/M. War das eine Wohltat> gegenüber M80 :-))
Sag nichts gegen M80. Das war die letzte nahezu perfekte und fehlerfreie
Software die Microsoft geliefert hat. Da kann sich fast jeder heutige
Assembler noch Scheiben abschneiden, z.B. die Assemblierung für einen
anderen Adressbereich mit .PHASE.
Georg
Ich meinte M80 also Synonym für Z80/8080 Assembler.
Wenn's um M80 als Programm geht: 10 Jahre später durfte ich ASM370
benutzen. Dagegen war M80 nur ein Spielzeug.
Bei Turbo-P gab's damals schon einen Editor als Pascal-Source. Und in
wenigen Sekunden war der übersetzt. Sowas in ASM wollte ich nicht
schreiben müssen.
BTW, den Editor erweiterte ein Norddeutscher geringfügig und verkaufte
in als Star-Star. Mit den verdienten Geld baute er Star-Office, das er
SUN verkaufte, woraus die OpenOffice machten, aus dem nach Kauf von SUN
durch Oracle LibreOffice wurde. Die IT-Welt ist so klein!
Fragezeichen? schrieb:> Bei Turbo-P gab's damals schon einen Editor als Pascal-Source.
Einen Editor? Meinst du TV, Fenster mit Mausbedienung? Borland war da
1000 Schritte vor MS.
Oldtimer schrieb:> Einen Editor? Meinst du TV
Es gab mehrere, HS habe ich noch lange danach benutzt, der hatte
Eigenschaften wie den Umgang mit Textdateien beliebiger Grösse, ohne wie
heute üblich erst mal alles in den Speicher zu laden, der konnte unter
DOS mit Megabytes an Text umgehen, da träumt mancher heutige Editor
davon.
Georg
bal schrieb:> Georg schrieb:>> da träumt mancher heutige Editor davon.>> Welcher?
Notepad? Immerhin der wohl meistbenutzte Editor auf unserem Planeten.
Georg
Hallo Georg,
Georg schrieb:> bal schrieb:>> Georg schrieb:>>> da träumt mancher heutige Editor davon.>>>> Welcher?>> Notepad? Immerhin der wohl meistbenutzte Editor auf unserem Planeten.
Der meistgenutzte Editor auf unserem Planeten ist Microsoft Word.
SCNR,
Karl
Ach, ihr diskutiert ja immer noch über des Kaisers Bart.
Und das so sachverständig wie unser Karl Käfer:
Karl Käfer schrieb:> Dann benutz' doch puts(3) oder write(2) oder C++-Streams...
...
> Auf genau welche Sachargumente hätte man denn eingehen können? Bisher> hast Du nur provoziert und gepöbelt. Zu mehr bist Du wohl nicht fähig.
Offenbar bist du ein bissel blind vor Eifer. Also ich erkläre es dir
NOCH EINMAL:
Ausgangspunkt: printf versus write.
Bei printf braucht es nen Formatstring, jedenfalls ist das so
vorgesehen.
Bei write braucht es keinerlei Formatstring, weil der Compiler es
auseinandernimmt und genau das, was bei C ein Textinterpreter in der
runtimelib zur Laufzeit machen muß, bereits beim Kompilieren erledigt.
erste Erwiderung dazu: Bei einem simplem konstanten Formatstring
analysiert der GCC selbigen und optimiert ihn einfach hinweg.
Meine Antwort dazu: Das ist ne Leistung eines heutigen Compilers und ist
in dieser Art durch die Erfinder von printf gar nicht so vorgesehen. Man
muß es dem GCC hoch anrechnen, daß er an dieser Stelle etwas gegen die
eigentliche Lausigkeit des printf-Entwurfes tut.
Und jetzt kommst du und pöbelst herum mit "Dann benutz' doch puts(3)
oder.." Das ist unsachlich, das ist das offensichtliche Nichteingehen
auf Sachargumente, das ist genau das, was du mir fälschlich vorwirfst:
Herumpöbeln. Schäm dich.
So, nochmal ein Anlauf meinerseits:
Warum ereifern sich denn hier so viele C-Leute so heftig über Pascal?
Offensichtlch hat das überhaupt keine technischen Gründe, sondern andere
- wie z.B. Das Nichtmögen von irgend etwas, Ressentiments die die
Schreiber nicht direkt rauslassen wollen und so weiter.
Also: Warum mögen diejenigen, die hier gegen Pascal so wettern denn
kein Pascal? Wäre doch mal interessant, die eigentlichen Beweggründe an
die Oberfläche zu holen.
W.S.
W.S. schrieb:> Also: Warum
Das ganze ist etwa so als wenn man diskutiert ob nun VW Käfer oder
Trabbi besser war, oder Betamax oder VHS. Ja gut, C gibt es noch, und
Pascal irgendwie auch.
W.S. schrieb:> Warum mögen diejenigen, die hier gegen Pascal so wettern denn kein> Pascal?
- mit C kann ich meine täglichen Vollkornbrötchen verdienen, mit Pascal
nicht
- ich mag die unauffälligen Sonderzeichen von C lieber als die
geschwätzigen Pascal-Schlüsselwörter
- C kann ich schon
- C ist auf jeder Platform verfügbar (ok, das geht in Richtung Punkt 1)
- ich lese gerne unsachliche Diskussionen wenns mir fad ist und ergreif
dabei auch gern Partei
Technisch nehmen sich beide wohl wenig.
Hallo W.,
W.S. schrieb:> Karl Käfer schrieb:>> Auf genau welche Sachargumente hätte man denn eingehen können? Bisher>> hast Du nur provoziert und gepöbelt. Zu mehr bist Du wohl nicht fähig.>> Offenbar bist du ein bissel blind vor Eifer. Also ich erkläre es dir> NOCH EINMAL:
Du kannst es noch zehnmal "erklären", es bleibt trotzdem Unsinn.
Und es wird Pascal auch nicht wieder zum Leben erwecken.
Grüße,
Karl
W.S. schrieb:> Also: Warum mögen diejenigen, die hier gegen Pascal so wettern denn> kein Pascal? Wäre doch mal interessant, die eigentlichen Beweggründe an> die Oberfläche zu holen.
also ich bin mir sicher dass das was mit den Chemtrails zu tun hat,
die haben uns alle manipuliert!
"- mit C kann ich meine täglichen Vollkornbrötchen verdienen, mit Pascal
nicht"
Unsinn! ICH verdiene mein Geld mit Pascal udn eine Menge anderer auch.
Wenn einer Pascal kann und eine Firma auf Pascal setzt, so wird dieser
"Spezialist" dort sicher sehr begehrt sein.
In C musst Du schon was zu bieten haben um da eine gute Position zu
bekommen.
Das Geld kannst Du damit nur verdienen wenn Du in C echt!! gut bist oder
eben halbwegs bis sehr gut Pascal beherscht.
Da alle auf C ausgebildet werden, ist also die Chance einen gutbezahlten
PAscal Job zu ergattern größer ;-) Auch wenn es sicher weniger davon
gibt.
Aber so einige kommerzielle Geräte laufen mit PAscal ohne das es jemand
weiß..
Angefangen vom Modellbaubereich bis zu Sanitärbereich ;-)
Tombo schrieb:> Unsinn!
Na das werd ich wohl besser wissen, meinst nicht?
In meiner Branche ist C gesetzt. Punkt.
Für manche Prozessoren hier gibts nicht mal nen gcc, wo soll ich da denn
nen Pascal-Compiler hernehmen?
Am PC ist C natürlich nicht die erste Wahl...
Tombo schrieb:> In C musst Du schon was zu bieten haben um da eine gute Position zu> bekommen.> Das Geld kannst Du damit nur verdienen wenn Du in C echt!! gut bist oder> eben halbwegs bis sehr gut Pascal beherscht.
Schön wärs...
Lustiges Argument: Pascal ist besser, weil da geringere Kenntnisse zum
Experten ausreichen als in C.
Also ich verdiene meine Brötchen mit Code einer Propietären Sprache mit
4 Buchstaben, deren erster ein A ist. Da muß ich viel schreiben, Kenner
wissen das (heute nicht mehr so viel dank Code-Completion), und so liebe
ich es zu Hobbyzwecken weniger schreiben zu müssen. Ich kann mir aus
sehr die Abkürzungen für BEGIN/ENDZudem, also { und } merken. Trotz
fortgeschrittenem Alter! Und bin ich sehr angetan von dem, was der GCC
so mit meine C(++)-Code an AVR-Code produziert. Ich habe weder Zeit mir
andere Compiler anzusehen, noch will ich dafür Geld ausgeben (Ja ich
gebe zu, ich nutze gern kostenlos Werke Anderer, wenn die das
ausdrücklich so wollen). Eine Verschwörung gegen Pascal habe ich aber
nicht im Sinn.
W.S. schrieb:> Ach, ihr diskutiert ja immer noch über des Kaisers Bart.
Freut mich, dass du wieder da bist. Ohne dich macht die Diskussion
hier einfach nur halb so viel Spaß :)
W.S. schrieb:> Ausgangspunkt: printf versus write.> Bei printf braucht es nen Formatstring, jedenfalls ist das so> vorgesehen.> Bei write braucht es keinerlei Formatstring, weil der Compiler es> auseinandernimmt und genau das, was bei C ein Textinterpreter in der> runtimelib zur Laufzeit machen muß, bereits beim Kompilieren erledigt.
Jetz pass mal auf:
Im Prinzip stimme ich dir zu, dass es besser ist, Formatbeschreibungen
bereits zur Compilezeit zu analysieren, um dann daraus jeweils Code mit
minimalem Overhead generieren zu können. Die Idee ist schon uralt, denn
schon Ur-FORTRAN von 1956 (damals noch in Schreischrift geschrieben ;-))
hat sie schon umgesetzt.
Weil du aber immer versuchst, den Leuten weiszumachen, wie sauber, gut
durchdacht und erweiterbar das Sprachdesign von Pascal sei, vergleichen
wir mal die Formatierfunktionen der drei Sprachen an einem Beispiel, das
in allen dreien (vermeintlich) leicht umsetzbar ist:
Es soll eine Tabellenzeile mit drei Spalten, getrennt durch '|'-Zeichen
ausgegeben werden, wobei in der ersten Spalte eine fortlaufende Nummer
(Integer) und in den beiden anderen jeweils ein Arrayelement mit 3
Nachkommastellen (Floating Point) stehen soll.
Nichts einfacher als das:
C:
1
printf("| %2d | %7.3f | %7.3f |\n", i, a[i], b[i]);
Auch hier keine Überraschung.
Warte, da fehlt doch etwas ...
Ja, Mist, jetzt habe ich in meinem Eifer doch glatt die Pascal-Version
vergessen ;-)
Aber wie geht denn das überhaupt in Pascal?
Naheliegend wäre ja so etwas wie
wobei s eine Stringvariable ist. Das funktioniert aber nicht, da writeln
diese Variable nicht als etwas Besonderes sieht, sondern sie genauso wie
alle anderen Argumente ausgibt.
Ok, dann gibt es sicher eine entsprechendes Konstrukt mit anderem Namen,
vielleicht
Nein, da meckert nur der Compiler.
Aber wie geht es dann?
Weil ich mir nach deinen obigen Ausführungen fast sicher war, dass
zumindest neuere Pascal-Dialekte eine elegante Lösung dieses Problems
bieten, habe ich Google und die Dokumentation von Free Pascal (das
weitgehend Delphi-kompatibel ist) bemüht und dabei im Wesentlichen zwei
Lösungen gefunden (falls es bessere gibt, bitte her damit).
Die erste Lösung (für dich wahrscheinlich die bessere, da sie noch am
ehesten die Pascal-Philosophie vertritt) sieht so aus:
Igitt, wie sieht dann das aus? Gleich vier Anweisungen für so etwas
Einfaches? Da muss doch tatsächlich jede Variable einzeln mit str
formatiert werden. Wäre str wenigstens eine Funktion, die den
Ergebnisstring als Return-Wert zurückgibt, dann könnte man alles in eine
einzelne (wenngleich sehr umständliche) Anweisung schreiben und auf die
temporären Stringvariablen verzichten.
Nein, das kann nicht die Lösung sein.
Das dachten sich sicher auch die Delphi-Entwickler und haben deswegen im
Modul sysutils eine komfortablere Prozedur bereitgestellt, die so
aussieht:
Ja, so sieht das doch schön kompakt und halbwegs übersichtlich aus.
Aber, o Schreck: Das hat ja überhaupt keine Ähnlichkeit mit der
writeln-Syntax mehr. Da sind überhaupt keine Doppelpunkte für die
Formatparameter, und die Liste der zu formatierenden Variablen muss auch
noch in eckige Klammern geschrieben werden.
Noch viel schlimmer: Die Formatangaben stehen in einem String, was
deiner Meinung nach ja völlig böse ist. Da kann der Compiler überhaupt
nichts optimieren.
Und Gipfel des Ganzen: Dieser Formatstring sieht (bis auf den
Zeilenvorschub am Ende) exakt so aus wie in sprintf von C.
Jeder C-Programmierer freut sich natürlich darüber, dass er hier nicht
umdenken muss. Aber was sagt da ein alter Pascal-Hase wie du dazu?
Könnte man mit vertretbarem Aufwand wenigstens einen eigenen
sprintf-Ersatz schreiben, der sich wie writeln verhält? Ich habe dazu
zwar Ansätze, aber nichts Überzeugendes gefunden.
Angesichts dieser Ernüchterung wage ich ja gar nicht erst zu fragen, wie
wohl die Pascal-Pendants von vprintf, vfprintf und vsprintf aussehen.
Und hätte ich doch nur nicht in der Free-Pascal-Dokumentation
geschmökert. Denn was musste ich da Unglaubliches sehen:
- Es gibt mittlerweile Pointer-Arithmetik, die exakt so funktioniert wie
in C. Berechnete Pointer können an beliebige Stellen im Adressraum des
Prozessors zeigen, womit man wie in C jede Menge Unfug anstellen kann.
- Es gibt sogar den Datentyp pointer, der exakt dem void-Pointer von C
entspricht. Damit ist es möglich, jeden Pointer auf Typ A in einen
Pointer auf einen beliebigen anderen Typ B zu casten. Wie war das noch
einmal mit der Typsicherheit von Pascal.
Das sind doch genau die Punkte, die bei Pascal-vs-C-Diskussionen von den
Pascal-Anhängern immer als erstes als die ganz großen Nachteile von C
aufgeführt werden. Jetzt müssen wir feststellen, dass diese Features
sogar von den Pascal-Entwicklern übernommen worden sind.
Der Trend läuft offensichtlich dahin, dass Pascal immer mehr zu einem
"C mit Begin und End" mutiert¹. Damit werden sich in naher Zukunft wohl
Diskussionen darüber, ob Pascal oder C die bessere Sprache sei,
erübrigen, da die Antwort ganz einfach lauten wird: Beide sind nicht nur
gleich gut, sie sind gleich ;-)
P.S.: Falls ich bei jemandem den Eindruck erwecken sollte, ich sei ein
Pascal-Hasser (so wie es hier auch einige C-Hasser gibt): Dem ist nicht
so. Ich wehre mich nur gegen Aussagen, dass Pascal die perfekte und
makellose Programmiersprache und C dagegen nur ein Haufen Murks sei.
Beides sind relativ alte Sprachen, die damals mit – aus heutiger Sicht –
wenig Weitblick entwickelt worden sind und durch die Erweiterungen, die
sie im Lauf der Zeit erfahren haben, zwar besser benutzbar, aber
keineswegs rund und sauber geworden sind. Das werden sie auch nie
werden.
Sehr viel runder und sauberer sind in meinen Augen Lisp (untern den
alten) und Haskell (unter den jüngeren Sprachen), aber auch diese haben
jede Menge Macken, die inzwischen auch nicht mehr restlos ausgebügelt
werden können.
————————————
¹) Diese Prozess begann wohl mit Turbo-Pascal 3, was mir damals deutlich
besser gefiel als der von mir bis dahin verwendete, an Ur-Pascal
angelehnte Dialekt, da von man jetzt an Real-World-Anwendungen
nicht nur in C, sondern auch in Pascal realisieren konnte, und das
insbesondre auf PCs, bei denen man damals mangels eines richtigen
Betriebssystems oft sehr hardwarenah programmieren musste.
W.S. schrieb:> erste Erwiderung dazu: Bei einem simplem konstanten Formatstring> analysiert der GCC selbigen und optimiert ihn einfach hinweg.>> Meine Antwort dazu: Das ist ne Leistung eines heutigen Compilers und ist> in dieser Art durch die Erfinder von printf gar nicht so vorgesehen.
Un da liegst du falsch. Eine der wichtigsten Regeln in C überhaupt ist
die "as-if rule", die besagt, daß der Compiler die Funktion des Code auf
beliebige Weise umsetzen kann, solange das beobachtbare Ergebnis das
gleiche ist. Und in einem Hosted-Environement darf der Compiler das ganz
explizit auch bei sämtlichen Funktionen der Standardbibliothek tun. Das
ist ganz bewußt so vorgesehen. GCC nutzt diese Option.
> So, nochmal ein Anlauf meinerseits:>> Warum ereifern sich denn hier so viele C-Leute so heftig über Pascal?>> Offensichtlch hat das überhaupt keine technischen Gründe, sondern andere> - wie z.B. Das Nichtmögen von irgend etwas, Ressentiments die die> Schreiber nicht direkt rauslassen wollen und so weiter.
Du tust genau das gleiche. Warum z.B. ist es bei Pascal ganz toll, wenn
der Compiler die Ausgaberoutine fest eingebaut hat, bei C ist aber genau
das gleiche für dich ganz furchtbar.
C läßt dem Compilerbauer die Wahl, wie er es macht. Warum ist das
schlechter, als der Pascal-Weg, der ihm eine Vorgehensweise aufzwängt?
"Lustiges Argument: Pascal ist besser, weil da geringere Kenntnisse zum
Experten ausreichen als in C."
wo habe ich das geschrieben?!?
Ich schrieb das man dadurch besser einen Job bekommt einfach weil nunmal
weniger PAscal Profis am Markt sind, ist also logischerweise die
Konkurenz hier nicht so groß, also hat man es eifnacher als bei den
vielen C Programmierern.
Ist doch logisch, das natürlich nicht so viele Pascal Prgrammeirer wie
für C gesucht werden ist auch klar aber das Verhältnis ist halt nicht
schlecht.
Eine null wird auch mit PAscal keinen Job bekommen, wenn er zu nichts zu
gebrauchen ist
Adrian schrieb:> Ich schrieb das man dadurch besser einen Job bekommt einfach weil nunmal> weniger PAscal Profis am Markt sind, ist also logischerweise die> Konkurenz hier nicht so groß, also hat man es eifnacher als bei den> vielen C Programmierern.> Ist doch logisch, das natürlich nicht so viele Pascal Prgrammeirer wie> für C gesucht werden ist auch klar aber das Verhältnis ist halt nicht> schlecht.
Aha und jetzt poste bitte doch mal deine Quellen. Die Statistik würde
ich mir gerne ansehen.
Arc Net schrieb:> @Yalu:> Wie wär's mit WriteStr> http://www.freepascal.org/docs-html/rtl/system/writestr.html
Tatsächlich, das geht. Danke für den Hinweis!
Kann es sein, dass diese Anweisung relativ neu in Free Pascal bzw.
Delphi ist? Da ich den Namen "WriteStr" nicht kannte, suchte ich über
Umschreibungen nach einer solchen Anweisung, und fand sie nicht.
Stattdessen fand ich mehrere (nicht besonders erfolgreiche) Versuche,
genau diese Funktion in Free Pascal oder Delphi nachzuprogrammieren.
Aber selbst wenn man die Lösung kennt und direkt nach "WriteStr" sucht,
findet man zwar die Dokumentation von Free Pascal dazu, aber recht wenig
Diskussionen in Foren u.ä. Irgendwie scheint die Anweisung keiner zu
kennen oder keiner zu benutzen. Die C-ähnlichen Formatierungsfunktionen
von Free Pascal wie bspw. Format scheinen verbreiteter zu sein.
wie kommt es eigentlich das C++ hiernach rückläufig ist?!
Also jetzt mal ganz unabhängig von der generellen Diskussion.
Wird für den PC noch so viel in C geschrieben?
Wieso?
Yalu X. schrieb:> - Es gibt sogar den Datentyp pointer,
Pointer gibts schon seit den Turbo-Zeiten. Guten Morgen!
Also heute zum ersten Mal seit Wirth wieder mit Pascal beschäftigt, für
ungefähr 5 Minuten durchs FPC Manual geblättert und schon ein Fachmann
sein wollen :-(
> der exakt dem void-Pointer von C> entspricht. Damit ist es möglich, jeden Pointer auf Typ A in einen> Pointer auf einen beliebigen anderen Typ B zu casten. Wie war das noch> einmal mit der Typsicherheit von Pascal.
Ich glaub Du verwechselst da was. Hint: Die Existenz von expliziten
Typumwandlungen hat nichts damit zu tun. Willst Du ernsthaft behaupten C
wäre genauso typsicher wie (Object-)Pascal? Dazwischen liegen Welten!
Welten!
Yalu X. schrieb:> Tatsächlich, das geht. Danke für den Hinweis!
Dann korrigiere doch bitte deinen falschen Beitrag weiter oben, danke.
Bernd K. schrieb:> Willst Du ernsthaft behaupten C> wäre genauso typsicher wie (Object-)Pascal? Dazwischen liegen Welten!> Welten!
Dafür gibt es C++, das weiter entwickelte C. ;-P
Gerade bie den Mikroe-Compilern ist es fast gleich ob C oder Pascal oder
Basic.Die sind alle sehr ähnlich, vermutlich weil sie auf einer engine
basieren uns sich nur äusserlich unterscheiden.
Bernd K. schrieb:> Yalu X. schrieb:>> - Es gibt sogar den Datentyp pointer,>> Pointer gibts schon seit den Turbo-Zeiten. Guten Morgen!
Wenn du das schreibst, dann wird es wohl so sein. In den Zeiten, wo
Turbo-Pascal noch hipp war und ich es auch tatsächlich (und nicht nur
hobbymäßig) verwendete, habe ich diesen Datentyp jedenfalls nie
gebraucht. Auch in C benutze ich void-Pointer nur ganz selten, in C++ so
gut wie überhaupt nicht. Deswegen war ich halt ein wenig überrascht,
dass es so etwas ausgerechnet in neueren Pascal-Dialekten gibt, wo der
Bedarf dafür eigentlich noch viel geringer ist.
>> der exakt dem void-Pointer von C>> entspricht. Damit ist es möglich, jeden Pointer auf Typ A in einen>> Pointer auf einen beliebigen anderen Typ B zu casten. Wie war das noch>> einmal mit der Typsicherheit von Pascal.>> Ich glaub Du verwechselst da was. Hint: Die Existenz von expliziten> Typumwandlungen hat nichts damit zu tun.
Als ich das schrieb, hatte ich Aussagen wie die folgende im Hinterkopf,
die von Pascal-Anhängern oft als ein entscheidender Vorteil "ihrer"
Sprache angeführt wird:
"Pointers in Pascal are type safe; i.e. a pointer to one data type can
only be assigned to a pointer of the same data type. […] Pointer
arithmetic (a common source of programming errors in C, especially
when combined with endianness issues and platform-independent type
sizes) is not permitted in Pascal."
(aus http://en.wikipedia.org/wiki/Comparison_of_Pascal_and_C)
Das ist zwar (fast) richtig für Ur- und ISO Pascal, aber eben nicht mehr
für die aktuell noch verwendeten Pascal-Dialekte.
> Willst Du ernsthaft behaupten C wäre genauso typsicher wie> (Object-)Pascal?
Nein, das will ich nicht und habe ich auch nicht.
> Dazwischen liegen Welten!> Welten!
Na, na, jetzt übertreib mal nicht. So geht bspw. folgender Code
anstandlos durch den Free-Pascal-Compiler, selbst mit der Option -vw
(show warnings):
1
program test;
2
3
var
4
i: integer;
5
b: byte;
6
pr: ^real;
7
8
begin
9
i := 1000;
10
11
b := i; { implizite Typumwandlung, Wert wird abgeschnitten }
12
writeln(b);
13
14
pr := @i; { implizite Typumwandlung, Pointer auf einen anderen Datentyp }
15
writeln(pr^)
16
end.
Was muss ich tun, um an den beiden kommentierten Stellen Fehlermeldungen
zu erhalten?
Ein C-Compiler wie der GCC würde wenigstens bei der Pointer-Zuweisung
eine Warnung ausgeben (selbst bei nicht explizit aktivierten Warnungen),
ein C++-Compiler sogar einen Fehler.
hash tag schrieb:> Yalu X. schrieb:>> Tatsächlich, das geht. Danke für den Hinweis!>> Dann korrigiere doch bitte deinen falschen Beitrag weiter oben, danke.
Welchen Fehler meinst du genau? Ich habe nicht geschrieben, dass es
eine solche Anweisung nicht gibt, sondern nur
Yalu X. schrieb:> habe ich Google und die Dokumentation von Free Pascal (das weitgehend> Delphi-kompatibel ist) bemüht und dabei im Wesentlichen zwei Lösungen> gefunden (falls es bessere gibt, bitte her damit).
Übrigens scheint WriteStr in Delphi nicht vorhanden zu sein, was eine
Erklärung dafür sein könnte, dass auch unter den Free-Pascal-Nutzern so
gut wie keine Diskussion über diese Anweisung stattfindet und sie
deswegen per Google nur schwer zu finden ist.
Yalu X. schrieb:> Pointer> arithmetic (a common source of programming errors in C, especially> when combined with endianness issues and platform-independent type> sizes) is not permitted in Pascal.
Das ist nur richtig, wenn sich der Programmierer auch dran hält und nur
direkte Zuweisungen verwendet - will er unbedingt Pointer umwandeln oder
Pointer Arithmetik betreiben, so gibt es dafür schon seit dem Urpascal
bedingte Variable (type case integer of...), die man u.a. wahlweise als
integer oder als pointer verwenden kann, aber halt auf eigene Gefahr.
Aber elegant und beliebt für Typumwandlungen, habe ich in embedded
Steuerungen z.B. verwendet, um 32bit-Zahlen ohne Aufwand als 4 Bytes zu
versenden.
Die hatte ich glaube ich schon auf meiner Pascal Maschine mit
UCSD-Pascal, lange vor Borland. Stammt wohl von Niklaus selbst.
Georg
Yalu X. schrieb:> Kann es sein, dass diese Anweisung relativ neu in Free Pascal bzw.> Delphi ist? Da ich den Namen "WriteStr" nicht kannte, suchte ich über> Umschreibungen nach einer solchen Anweisung, und fand sie nicht.> Stattdessen fand ich mehrere (nicht besonders erfolgreiche) Versuche,> genau diese Funktion in Free Pascal oder Delphi nachzuprogrammieren.
Habe WriteStr vor ca. 25 Jahren im Pascal Compiler der RISC Maschine IBM
6150 kennengelernt. Als ich dann viel später auf Freepascal umgestiegen
bin gab es den Befehl nicht und ich habe ihn sehr vermisst. Hatte damals
im Forum nachgefragt aber keine Antwort bekommen. Mir ist erst seit ca.
einem Jahr aufgefallen, dass Freepascal inzwischen WriteStr kennt. Hab
aber keine Ahnung, wie lange das schon implementiert ist.
Gerhard
Yalu X. schrieb:> Bernd K. schrieb:>> Yalu X. schrieb:>>> - Es gibt sogar den Datentyp pointer,>>>> Pointer gibts schon seit den Turbo-Zeiten. Guten Morgen!>> Wenn du das schreibst, dann wird es wohl so sein.
Ist nach meiner Erinnerung tatsächlich so. Ab wann
untypisierte Pointer erlaubt waren, weiss ich nicht
mehr sicher; typisierte funktionierten auch schon in
TurboPascal unter CP/M, möchte ich behaupten.
> b := i; { implizite Typumwandlung, Wert wird abgeschnitten }> writeln(b);>> pr := @i; { implizite Typumwandlung, Pointer auf einen anderen> Datentyp }> [...]> Was muss ich tun, um an den beiden kommentierten Stellen> Fehlermeldungen zu erhalten?
Mal Original-TurboPascal probieren?
SCNR
Im Ernst, ich würde schwören, dass beides bei original-TP nicht
durchgeht.
Yalu X. schrieb:> Was muss ich tun, um an den beiden kommentierten Stellen Fehlermeldungen> zu erhalten?
{$T+}
http://www.freepascal.org/docs-html/prog/progsu75.html
kurioserweise eine Einstellung die normalerweise nicht aktiv ist und
viele auch in Delphi nicht aktiviert haben.. warum auch immer..
Robert L. schrieb:> {$T+}
Ah, geht also doch.
> kurioserweise eine Einstellung die normalerweise nicht aktiv ist
Das wundert mich auch etwas. Schon in C muss man Pointer nur relativ
selten konvertieren, und in Pascal dürften diese Fälle noch wesentlich
seltener sein. D.h. in 99% der Fälle will man diese Typprüfung, und
für das restlichen 1% ist es völlig akzeptabel, den Pointer explizit zu
konvertieren.
Da diese Pointer-Konvertiererei sowieso etwas für Fortgeschrittene ist,
die genau wissen, was sie tun, sollten solche Prüfungen eigentlich per
Default aktiviert sein, damit sie insbesondere für den Anfänger, für den
sie den größten Nutzen darstellen, sofort verfügbar sind.
Gibt es eine ähnliche Compiler-Direktive, um bei einer impliziten
Konvertierung zu warnen, bei der der Wert verändert wird (wie im obigen
Beispiel bei der Zuweisung eines Integer-Werts an eine Byte-Variable)?
In C wird dieser Fall normalerweise nicht geprüft, da es bereits zuviel
Code gibt, der von der impliziten Typkonvertierung hemmungslos Gebrauch
macht. Man kann aber beim GCC die Prüfung mit -Wconversion aktivieren.
Dann bekommt man ggf. Warnungen wie die folgende angezeigt:
1
conversion to ‘uint8_t’ from ‘uint32_t’ may alter its value [-Wconversion]
Am schwierigsten beim programieren ist den Algoritm oder die richtige
Vorgehensweise zu erfinden, das ist dann wirkliches Programieren und
nicht das Eintipen von Text. Das kann jeder, egal in welcher Sprache,
aber ein Program auszudenken kann halt nicht jeder.
Rainer S. schrieb:> Pascal als Sprache gefällt mir sehr gut.
Weil sie dich bei der Hand nimmt und versucht dich vor allen Fehlern zu
beschützen. Lern C wenn du ein Mann bist!
Thread beobachten
Seitenaufteilung abschalten