Forum: PC-Programmierung C oder Pascal


von Rainer S. (rsonline)


Lesenswert?

Habe ein Hauptprojekt (PC Programm) geschrieben in Pascal.
Pascal als Sprache gefällt mir sehr gut.

Fange jetzt an die dazugehörigen AVR Mikrocontroller ebenfalls mittels 
Pascal zu programmieren.

Mit mikroPascal
http://www.mikroe.com/mikropascal/avr

Das geht ganz gut.

Parallel dazu denke ich schon über einen Umstieg auf ARM Controller 
nach.

Die Firma bietet ebenfalls einen Pascal Compiler für ARM Prozessoren an. 
Allerdings wird momentan nur STM32 uns Stellaris unterstützt.
Die Bibliotheken (Uart, Ethernet, usw.) sind wohl nicht quelloffen, 
jedenfalls habe ich bei einigem Suchen keine Quellen der Bibliotheken 
des ARM Compilers von Mikroelektronika gefunden. Vielleicht sind es ja 
übersetzte C Programme in Binärform, da die Firma ja auch C Compiler 
anbietet.

Ich überlege jetzt evtl. auf C umzusteigen bevor es "zu spät" ist.

Für C gibt es ja auf Linux freie Compiler.
Ich habe schon mal in C programmiert, allerdings finde ich es nicht 
unbedingt die bessere Sprache. Man kann in Pascal ebenfalls alles das 
machen was in C geht.

Habe schon in Freepascal für ARM compiliert. Auf einem Linux PC.
http://www.freepascal.org

Das ging irgendwann nach langem hin und her. Das ist aber wohl ebenfalls 
noch nicht 100% ausgereift.

Was spricht für C?

von Dussel (Gast)


Lesenswert?

Rainer S. schrieb:
> Was spricht für C?
Dass es die Standardsprache im Mikroprozessorbereich ist. Wenn du 
anstrebst, das professionell zu machen, also irgendwas in die Richtung 
zu lernen oder zu studieren, dann solltest du dich mit C beschäftigen. 
Privat geht auch Pascal, auch wenn ich persönlich nicht dazu raten 
würde.

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?


von Reinhard Kern (Gast)


Lesenswert?

Hallo,

Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich 
programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf). Du 
brauchst für die Benutzung von Fremdsoftware immer "Bindings", z.B. 
Definitionsdateien für die Funktionen einer DLL, und die bekommst du 
generell in C, nur sehr selten in Pascal. Selbst für Windows sind längst 
nicht alle APIs in Pascal definiert, die muss man dann selbst schreiben 
und das ist eine ganz erhebliche Mehrarbeit gegenüber C/C++ (Es dreht 
sich da um Aberhunderte von Funktionsdeklarationen!).

Dazu kommt, dass Borland und Nachfolger Embarcadero sehr 
"geschäftstüchtig" mit Lizenzen umgehen, mir sind durch einen Fehler bei 
Embarcadero alle Updatemöglichkeiten gestrichen worden und ein Neukauf 
würde einige Tausender kosten, was nicht nur nicht wirtschaftlich wäre, 
ich lasse mich auch aus Prinzip nicht gern betrügen, daher wird Delphi 
nicht mehr eingesetzt.

Also eindeutige Aussage: C, C++, und wenn man MS mag auch C#.

Gruss Reinhard

von Rainer S. (rsonline)


Lesenswert?

Dussel schrieb:
> Wenn du
> anstrebst, das professionell zu machen, also irgendwas in die Richtung
> zu lernen oder zu studieren, dann solltest du dich mit C beschäftigen.
> Privat geht auch Pascal, auch wenn ich persönlich nicht dazu raten
> würde.

Ich behaupte mal, dass ich das schon lange professionell mache.
Wie gesagt habe ich auch mal in C geschrieben, aber das hat mir nicht so 
100% zugesagt.

Michael Reinelt schrieb:
> http://www.pbm.com/~lindahl/real.programmers.html

Da stehen allerhand Sachen drin. Sieht ziemlich dogmatisch aus.

Reinhard Kern schrieb:
> Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich
> programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf).

Und das ganze Know-how, welches Du in Form von Pascal Quellcode 
angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen 
sollte.

> Du
> brauchst für die Benutzung von Fremdsoftware immer "Bindings", z.B.
> Definitionsdateien für die Funktionen einer DLL, und die bekommst du
> generell in C, nur sehr selten in Pascal.

So selten ist das gar nicht. Die meiste Software schreibe ich selbst. An 
Fremdsoftware benutze ich dann so ganz grundlegende Sachen wie das 
Betriebssystem oder die Funktionalität des Browsers (der schon da ist).

> Selbst für Windows sind längst
> nicht alle APIs in Pascal definiert, die muss man dann selbst schreiben
> und das ist eine ganz erhebliche Mehrarbeit gegenüber C/C++ (Es dreht
> sich da um Aberhunderte von Funktionsdeklarationen!).

In Freepascal ist Windowsprogrammierung überhaupt kein Problem. Die 
Sachen sind alle schon (einmal) definiert worden. Win 32, Win 64 und 
sogar Win CE wird unterstützt.

> Dazu kommt, dass Borland und Nachfolger Embarcadero sehr
> "geschäftstüchtig" mit Lizenzen umgehen, mir sind durch einen Fehler bei
> Embarcadero alle Updatemöglichkeiten gestrichen worden und ein Neukauf
> würde einige Tausender kosten, was nicht nur nicht wirtschaftlich wäre,
> ich lasse mich auch aus Prinzip nicht gern betrügen, daher wird Delphi
> nicht mehr eingesetzt.

Vollwertige Alternative: Freepascal.

Ich denke mit wenigen Anpassungen (wenn überhaupt) kannst Du Deine 
Quellen 1:1 weiterverwenden. Von der Mailingliste her weiß ich, dass auf 
Kompatibilität mit Delphi viel Wert gelegt wird. Meiner Meinung nach zu 
viel.

>
> Also eindeutige Aussage: C, C++, und wenn man MS mag auch C#.

In MS habe ich kein Vertrauen. Ich programmiere wenn es eben geht für 
Linux.

Was ich mir wünschen würde wäre ein Compiler, der beides kann.
Das sollte ja eigentlich machbar sein.

Die Mikroelektronika Leute machen ja beides.
http://www.mikroe.com/compilers

Das wäre ein Novum.

von Karl H. (kbuchegg)


Lesenswert?

Rainer S. schrieb:


> Michael Reinelt schrieb:
>> http://www.pbm.com/~lindahl/real.programmers.html
>
> Da stehen allerhand Sachen drin. Sieht ziemlich dogmatisch aus.

Dann hast du nicht verstanden,warum es beim 'real programmer' in 
Wirklichkeit geht.

> Reinhard Kern schrieb:
>> Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich
>> programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf).
>
> Und das ganze Know-how, welches Du in Form von Pascal Quellcode
> angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen
> sollte.


Das richtige Know-How sammelt sich in Form von Algorithmen an und nicht 
in Form von Quellcode. Die sind dein 'Schatz'. Code ist nur eine 
konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen 
Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben.


Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du 
willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann?

von Reinhard Kern (Gast)


Lesenswert?

Rainer S. schrieb:
> Und das ganze Know-how, welches Du in Form von Pascal Quellcode
> angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen
> sollte.

Und eben, damit das anderen NICHT passiert, empfehle ich Pascal nicht 
mehr.

Ich mache auch viel Embedded, da ist die Nichtverfügbarkeit von Pascal 
noch viel krasser als auf dem PC. Ich habe auch keine Bedenken, 
verschiedene Sprachen in einem Projekt zu kombinieren, aber das scheint 
wohl aus der Mode zu kommen, viele Systeme unterstützen das nicht mehr, 
weil sie kein standardisiertes Object-Format verwenden oder weil 
Änderungen des Makefiles, sofern vorhanden, nicht vorgesehen sind.

Meiner Einschätzung nach verschwindet Pascal nicht schlagartig, aber so 
allmählich wird der Marktanteil unter 1% sinken und es wird nur noch als 
antik oder exotisch besprochen.

Was das verlorene Knowhow angeht, ich habe mal mit ALGOL angefangen, das 
kennt heute schon niemand mehr. Verloren ist es trotzdem nicht, gelernt 
ist gelernt, eine vorhandene Problemlösung in Pascal kann ich natürlich 
in C/C++ umformulieren, das ist bloss Routinearbeit. Die Frage der 
Umstellung auf zukunftssichere Software hat sich übrigens schon länger 
gestellt, der Betrug durch Embarcadero hat jetzt den endgültigen 
Ausschlag gegeben. Es ist übrigens auch unter Marketingaspekten nicht so 
günstig, ein exotisches System zu verwenden, vielmehr ist durchaus 
denkbar, dass man ein Entwicklungsprojekt wegen der Verwendung von 
Pascal garnicht erst bekommt. Ein Kunde hat nämlich auch grosse 
Probleme, wenn er ein Pascal-Projekt an einen anderen Programmierer 
übertragen muss.

Gruss Reinhard

von Christian B. (casandro)


Lesenswert?

Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum. 
(Pascal basierend)

C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst 
nach einem Assembler machen. C++ ist eher was für Masochisten, die eine 
Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist. 
C# ist halt wie VBA eine reine Microsoftsache und selbst für 
nur-Windows-Projekte eine eher schlechte Wahl.

Wenn Du C machen willst, lies Dir erst mal "The Art of UNIX Programming" 
durch. http://www.faqs.org/docs/artu/
Das Buch stellt ein Regelwerk vor, dass Dir für C und andere Sprachen 
helfen kann. Das hilft Dir dabei bessere Softwaresysteme zu entwickeln. 
Auch außerhalb von UNIX. Das sind Gedanken von jemanden der schon mal 
gute Software geschrieben hat. Daran kann man sich halten, sollte es 
aber nicht sklavisch nachahmen. Man sollte meiner Meinung nach nicht C 
programmieren, ohne die Grundzüge dieses Buches verstanden zu haben. 
(Man kann da aber bewusst Dinge gezielt ignorieren.)
Mir haben die Prinzipen aus dem Buch im letzten Arbeitszeugnis den Satz 
"Insbesondere mit der oben erwähnten Datenauswertesoftware hat er 
unserem Schlüsselprodukt zu einem absoluten Alleinstellungsmerkmal 
verholfen, von dem unser Unternehmen sehr profitiert." beschert.

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Dann hast du nicht verstanden,warum es beim 'real programmer' in
> Wirklichkeit geht.

Zu seiner Entschuldigung sei gesagt, dass der Essay wohl ein gewisses 
Alter voraussetzt... wie sonst sollte man Anspielungen wie TRASH-80 
verstehen :-)

Zum Thema: Pascal ist eine Lehrsprache, und wurde auch dafür (und nur 
dafür) entwickelt. Dafür ist sie meiner Meinung nach auch recht gut 
geeignet (ich hab selbst mit Pascal programmieren gelernt).

Ich hab nie verstanden wie man ernsthaft professionell Software damit 
entwickeln will...

ich übrigen teile ich zu 150% die Meinung, dass Know-How in Algorithmen 
steckt, und nicht in Quellcode. Wer das anders sieht, ist wahrscheinlich 
mit einer Lehrsprache ganz gut bedient.

von Rainer S. (rsonline)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du
> willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann?

Vielleicht gibt es ja gute Argumente für C.
Aber Du hast recht ich sitze da relativ fest im Sattel.

Karl Heinz Buchegger schrieb:
> Das richtige Know-How sammelt sich in Form von Algorithmen an und nicht
> in Form von Quellcode. Die sind dein 'Schatz'. Code ist nur eine
> konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen
> Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben.

Ein Projekt von 50000 Zeilen Quellcode ist nicht mal eben so 
umprogrammiert, auch wenn es relativ einfach ist.

Reinhard Kern schrieb:
> Ich mache auch viel Embedded, da ist die Nichtverfügbarkeit von Pascal
> noch viel krasser als auf dem PC.

Mikroelektronika hat gute Pascal Compiler im Angebot und mit Freepascal 
(was Du Dir aber wohl nicht ansehen willst) kann man ebenfalls die ARM 
Prozessoren programmieren. Ich hatte zuerst Bedenken Freepascal zu 
benutzen, habe es aber bis heute nicht bereut. Die Quellen gebe ich 
üblicherweise nicht heraus.

Christian Berger schrieb:
> Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum.
> (Pascal basierend)

Ich benutze Lazarus.

Michael Reinelt schrieb:
> Zum Thema: Pascal ist eine Lehrsprache, und wurde auch dafür (und nur
> dafür) entwickelt. Dafür ist sie meiner Meinung nach auch recht gut
> geeignet (ich hab selbst mit Pascal programmieren gelernt).

SMS war auch erst kostenlos.
https://de.wikipedia.org/wiki/Short_Message_Service#Wirtschaftliche_Bedeutunghttps://de.wikipedia.org/wiki/Short_Message_Service#Wirtschaftliche_Bedeutung

Michael Reinelt schrieb:
> Ich hab nie verstanden wie man ernsthaft professionell Software damit
> entwickeln will...

Was verstehst Du daran nicht?

Ehemaliger Arbeitgeber: http://www.ideco-gmbh.de
Alle PC's mit Pascal programmiert.

von Reinhard Kern (Gast)


Lesenswert?

Rainer S. schrieb:
> Die Quellen gebe ich
> üblicherweise nicht heraus.

Mit anderen Worten, alle deine Software stirbt mit dir und die Kunden 
stehen mit ihrer Fehlinvestition im Regen. Da hast du natürlich recht, 
wenn man die Leute so über den Tisch zieht, kommt es auf C oder Pascal 
auch nicht mehr an. Ich dachte, du wärst ein seriöser Geschäftspartner.

Gruss Reinhard

von Karl H. (kbuchegg)


Lesenswert?

Rainer S. schrieb:
> Karl Heinz Buchegger schrieb:
>> Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du
>> willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann?
>
> Vielleicht gibt es ja gute Argumente für C.

Das einzige Argument ist, dass du mit C-Kentnissen höchst wahrscheinlich 
leichter einen Job findest.

Anonsten: Pascal und C sind aus demselben Sprachparadigama und sind 
selbstverständlich Turing-vollständig. Was man mit der einen Sprache 
machen kann, kann man mit der anderen genauso. Wobei der Umstieg von 
Pascal (wir reden doch von Pascal so wie Wirth sich das im wesentlichen 
vorgestellt hat. Also keine objektorientierten Erweiterungen etc.) auf C 
gar nicht mal so wild ist. Die Syntax ist ein wenig anders, aber so 
radikal verschieden dann auch wieder nicht. Ob man jetzt zuweisungen mit 
:= schreibt und Vergleiche mit = oder wie in C Zuweisungen mit = und 
dafür Vergleiche mit == ist im Grunde Jacke wie Hose. Pascal als 
Lehrsprache hat sich halt für das eine entschieden, während die C-Macher 
pragmatisch vorgegangen sind und sich gefragt haben, was in der 
täglichen Programmierarbeit oft getippt werden muss und diese Dinge 
besonders kurz formuliert haben. Du wirst am Anfang ein paar mal auf 
speziell diese Syntaxunterschiede reinfallen, genso wie ich drauf 
reinfallen würde, wenn ich mal wieder in Pascal programmieren würde. 
Aber letzten Endes ist es reine Gewohnheitssache. Wobei 
zugegebenermassen ein C Compiler vieles akzeptieren muss, weil es 
legales C ist, was ein Pascal Compiler brüsk zurückweisen würde.

Die Programmiersprache ist nur das Werkzeug. Je besser du es beherrscht, 
desto besser kannst du Algorithmen damit umsetzen.


> Ein Projekt von 50000 Zeilen Quellcode ist nicht mal eben so
> umprogrammiert, auch wenn es relativ einfach ist.

Es gibt ja auch Sprachkoverter (auch wenn ich schon lange keinen mehr in 
den Fingern hatte).
Aber logisch. 50000 LOC übersetzt man nicht einfach so von heute auf 
morgen.
Unter diesem Gesichtspunkt wirst du allerdings nie zu einer anderen 
Sprache wechseln. Denn egal was - dieses Problem hast du natürlich 
immer.

von Amateur (Gast)


Lesenswert?

@Rainer

Kennst Du das Prinzip der Schafherde?
Da geht es nur darum, in welche Richtung die Masse läuft.
Es interessiert niemanden, welches der richtige Weg ist. Wobei 20 Leute, 
wahrscheinlich 21 gut begründete Beschreibungen liefern können.

Also egal was Du willst, mittelfristig bleibt dir nur Mäh! (C) zu rufen.

von Karl H. (kbuchegg)


Lesenswert?

Amateur schrieb:

> Es interessiert niemanden, welches der richtige Weg ist.

Weil es bei dieser Fragestellung kein "richtig" oder "falsch" gibt.

Und im Zweifel sagt dir dann schon der nächste Arbeitgeber, welche 
Sprachkenntnisse er von dir erwartet.

von 5-Sterne-Los (Gast)


Lesenswert?

Für C spricht, dass Pascal nie über den Status einer akademischen 
Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 
Jahren), aber ohne Praxisrelevanz.

Allerdings kannst du als reiner Bastler natürlich machen und 
ausprobieren, was du willst.

von G. C. (_agp_)


Lesenswert?

5-Sterne-Los schrieb:
> Für C spricht, dass Pascal nie über den Status einer akademischen
> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20
> Jahren), aber ohne Praxisrelevanz.

Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache. 
Sonst gäbe es wohl kaum solche Software hier:

http://www.diptrace.com/

von cppler (Gast)


Lesenswert?

Also die Programmiersprache ist i.d.R. egal.
Gut Klassiker:
C: "shoot yourself in the foot"
PASCAL: "the compiler wont let you shoot yourself in the foot"
Wenn man C nach sinnvollen Paradigmen programmiert kann man den Code 
auch in PASCAL übersetzen, umgekehrt geht es IMMER !
Also kein Grund sich auf eine Sprache festzulegen.
Wie Karlheinz schon erwähnt hat kommt es auf das Begreifen der Inhalte 
und Zusammenhänge an.
Daher kann man ja auch aktuelle Probleme in "Pseudoprogrammiersprachen" 
packen oder gleich versuchen via UML das ganze einzukapseln.
Meine persönliche Meinung ist daher das Du bei der PASCAL Vorgehensweise 
bleiben solltest und das ganze einfach in C/C++ umsetzen.
Wobei C++ mehr Möglichkeiten bietet als Object-PASCAL !
Aber bis sich C++ auf µCs durchgesetzt hat bist Du mit C als C++ Subset 
gut bedient ;-)

von Rene H. (Gast)


Lesenswert?

cppler schrieb:
> Wobei C++ mehr Möglichkeiten bietet als Object-PASCAL !
> Aber bis sich C++ auf µCs durchgesetzt hat bist Du mit C als C++ Subset
> gut bedient ;-)

Dem muss ich widersprechen, C++ bietet mit nichten mehr Möglichkeiten 
wie Objective-Pascal.

Nur, ist die Wahl der Programmiersprache ein müssiges Thema. Die 
Programmiersprache ist lediglich ein Werkzeug welches für den Zweck 
optimal ausgewählt werden sollte.

Grüsse,
R.

von cppler (Gast)


Lesenswert?

Rene H. schrieb:
> cppler schrieb:
>
> Dem muss ich widersprechen, C++ bietet mit nichten mehr Möglichkeiten
> wie Objective-Pascal.
>


Jein, man kann z.B. Templates in Object-PASCAL nachbilden aber es ist 
nicht so einfach wie in C++ genau wie die Kapselung ansich.
Von den aktuellen Bibliotheken mal abgesehen, aber das hat nichts mehr 
mit µC zu tun ;-)
EIFFEL hat sich ja auch nicht durchgesetzt obwohl da noch "bessere" 
Möglichkeiten implementiert sind als in PASCAL oder C++ !
PASCAL ist ja auch nicht wegen Wirth so populär geworden, sondern wegen 
der Funktionalität von TurboPASCAL, lag also weniger an der Sprache 
sondern den Bibliotheken dafür.
Modulo hat's ja auch nicht geschafft aber C/C++ wird's noch länger 
geben.
Nicht ideal weiß ich, aber besser als BASIC :-P

von Karl H. (kbuchegg)


Lesenswert?

g. c. schrieb:
> 5-Sterne-Los schrieb:
>> Für C spricht, dass Pascal nie über den Status einer akademischen
>> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20
>> Jahren), aber ohne Praxisrelevanz.
>
> Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache.
> Sonst gäbe es wohl kaum solche Software hier:

Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.

von cppler (Gast)


Lesenswert?

Karl Heinz Buchegger schrieb:
 Sonst gäbe es wohl kaum solche Software hier:
>
> Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.

Genau und es gibt eine Programmiersprache die wirklich mathematisch 
bewiesen wurde, wer benutzt die nun deswegen ?
Und COBOL ist gerade wieder voll im kommen, natürlich nur wegen der 
Vorteile von COBOL gegenüber C++ und Konsorten :-P
Könnte man ja auch in C abbilden GOTO und so :-P

von G. C. (_agp_)


Lesenswert?

Karl Heinz Buchegger schrieb:
> g. c. schrieb:
>> 5-Sterne-Los schrieb:
>>> Für C spricht, dass Pascal nie über den Status einer akademischen
>>> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20
>>> Jahren), aber ohne Praxisrelevanz.
>>
>> Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache.
>> Sonst gäbe es wohl kaum solche Software hier:
>
> Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.

Nur verstehe ich deinen Einwand (sollte wohl einer sein oder?) jetzt 
nicht. Es gibt nun mal eine allgemeine Beliebtheit bestimmter 
Programmiersprachen. Dazu kann man jetzt bekannte Indexe befragen oder 
einfach mal hier im Forum sich ein bisschen umhören bzw. Postings lesen, 
gewissermaßen als Stichprobe der Grundgesamtheit. Da wird man dann weit 
überwiegend C, C++, C#, Pascal, Java und verschiedene Skriptsprachen 
finden. Das ganze hat auch sehr stark damit zu tun, wie sich die ein- 
oder andere Sprache dazu eignet Windows-Programme (also GUI-Programme) 
oder Plattform übergreifende Linux<->Windows -Programme (Mac oder andere 
eher selten) zu erstellen. Hierfür sind die Klassenbibliotheken oder 
"Widget Toolkits" als Erweiterungen von Delphi (VCL), Lazarus (gleich 
mehrere wie QT, GTK+, GTK2 ...), Visual Studio C/C++/C# (MFC, .NET 
(Forms oder WPF)), oder freie C++ IDEs, die beispielsweise wxWidget 
einbinden maßgeblich. Da gibt es verschiedenste Tools bzw. 
Kombinationen, die mehr oder weniger komfortabel einzurichten sind. Nur 
taucht da i.d.R. kaum "Prolog" bei auf.

Ich glaube also nicht, dass man "Prolog" da mit einreihen kann. Ebenso 
wenig wie ADA, Brainf*ck, Haskell oder was es alles noch so gibt. 
Objective C wäre vielleicht noch zu den Platzhirschen zu zählen und 
vielleicht auch good old Assembler, wegen seiner großen Fangemeinde, 
auch wenn es praktisch immer mehr durch C verdrängt wird (so mein 
Eindruck). Im Grunde haben doch Borland mit Turbo Pascal, Turbo C(++) 
und MS mit den Visual Studio Produkten hier die Vorlieben vieler damals 
entscheident beeinflusst und das hält bis heute an, wenn auch mit 
verlagerten Gewichten, weil gewisse Firmen es einfach nicht gebacken 
bekommen, den MS Express-Produkten etwas gleichwertiges 
(kommerziell-lizenziertes) entgegenzusetzen, ohne dafür einen Obolus 
seiner Fangemeinde abzupressen. Embarcadero hätte es in der Hand sich 
ein Stück vom Markt zurückzuerobern. Aber nur allein über die 
Geldschiene wird das nicht gelingen. Dazu sind die kostenfreien 
Alternativen zu mächtig geworden.

PS: Brainf*ck kann man hier nicht mal schreiben, ohne dass die 
Forensoftware Spammalarm schlägt. Irgendwie passend. ;)

von Dauergast (Gast)


Lesenswert?

Rene H. schrieb:
> Die Programmiersprache ist lediglich ein Werkzeug

Nein.

Software ist ein lebendes Objekt, das sich ständig gewartet wird, sich 
anpassen muß, von sich ständig ändernden Gruppen bearbeitet wird.

Wenn Du die Analogie zum Handwerk bemühen willst, paßt ein Vergleich der 
Sprache mit dem Material besser. Du wirst ein Bücherregal aus Holz 
schneller und leichter an bauliche Gegebenheiten anpassen können als 
eins aus Stahl oder gar Glas, eben so sinkt die Zahl derer, die solche 
Anpassungen vornehmen können. Du wirst für ein Holzregal deulich mehr 
Beschläge und Schrauben finden als für Stahl oder gar Glas, von den 
Möglichkeiten der Oberflächengestaltung mal ganz abgesehen.

Das Pascal oder Basic üblicherweise nur ein kurzes Lachen auslösen, hat 
nichts mit Arroganz zu tun - es ist einfach angebracht. Wie schon 
andernorts erwähnt, wenn man keinerlei Interaktion mit der Restwelt 
beabsichtigt, kann man problemlos in irgendwas Programmieren. 
Andernfalls eben nicht.

BTW: Ich liebe Delphi. Nützt nur nix.

von Uhu U. (uhu)


Lesenswert?

Dauergast schrieb:
> Software ist ein lebendes Objekt, das sich ständig gewartet wird, sich
> anpassen muß, von sich ständig ändernden Gruppen bearbeitet wird.

Das gilt auch für so manchen Blumengarten und trotzdem sind Rechen und 
Hacke mur Werkzeuge...

von Andreas H. (ahz)


Lesenswert?

Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind 
endlich mal vorbei :/

Karl Heinz Buchegger schrieb:
> Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.

Wird Gründe haben. Versuch doch mal ernsthaft einen High-performance 
backward-chainer zu schreiben^^. Warrens Artikel zu diesem Thema kann ja 
wirklich keiner lesen ;-)

Und btw.: Der Observation scheduler des Hubble Teleskops ist übrigens in 
Lisp geschrieben, wie viel anderes Zeug auch. Auch Fortran erfreut sich 
immer noch groser Beliebtheit.

Gibt vielleicht doch etwas mehr Anwendungen, die wir hier nicht wirklich 
durchblicken ?
Die Leute, die sowas SO programmieren, wie sie es machen, sind ja auch 
nicht gegen den Schrank gelaufen^^

cppler schrieb:
> Und COBOL ist gerade wieder voll im kommen
Ehr nicht, aber ziemlich stabil im Markt, z.B. bei Banken. Die würden ja 
gerne umsteigen aber keine SW Bude traut sich, für ihre 
Neuimplementierung die Hand ins Feuer zu legen.
Pro Tag werden über Forex  ~4000 Mrd/Tag (! kein Witz) gehandelt. Wenn 
Du da dann für, z.B. durch Rundungsfehler entstandene, Schäden haften 
willst ....

Karl Heinz Buchegger schrieb:
> Code ist nur eine
> konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen
> Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben.
Da hast Du prinzipiell recht. Aber Pascal kann z.B. verschachtelte 
Prozedurdefinition. Das heisst insbesondere aber auch, dass eine lokale 
Variable einer Prozedur eine globale Variable einer in diesem Scope 
definierten Prozedur ist. Davon hast Du dann u.U. eine ganze Menge und 
nun viel Spass beim Umsetzen. Geht aber nervt.

Grüße
Andreas

von Paul Baumann (Gast)


Lesenswert?

Andreas schrieb:
>Wenn Du da dann für, z.B. durch Rundungsfehler entstandene, Schäden haften
>willst ....

Dann wirst Du vorher vom Auftraggeber rund gemacht.
;-)
MfG Paul

von Rainer S. (rsonline)


Lesenswert?

Reinhard Kern schrieb:
> Rainer S. schrieb:
>> Die Quellen gebe ich
>> üblicherweise nicht heraus.
>
> Mit anderen Worten, alle deine Software stirbt mit dir und die Kunden
> stehen mit ihrer Fehlinvestition im Regen. Da hast du natürlich recht,
> wenn man die Leute so über den Tisch zieht, kommt es auf C oder Pascal
> auch nicht mehr an. Ich dachte, du wärst ein seriöser Geschäftspartner.
>
> Gruss Reinhard

Sag mal, findest Du das nicht reichlich frech was Du hier so von Dir 
gibst?

Ich habe Dir eine Alternative zu Deinem Delphi genannt, wo Du Dich schon 
ganz erheblich vergallopiert hast. Darauf gehst Du nicht ein.

Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte. 
Oben steht das Wort 'üblicherweise'. Außerdem kennst Du meine 
Firmenstruktur nicht. Und weiter ist es in weiten Teilen üblich, dass 
man die Quellen nicht herausgibt.

Schon mal davon gehört?

Ich denke, wenn Du noch nicht mal auf das eingehst was man Dir praktisch 
vor der Nase hält ist das mit Deinen softwaretechnischen Leistungen 
nicht weit her.

Dauergast schrieb:
> Das Pascal oder Basic üblicherweise nur ein kurzes Lachen auslösen, hat
> nichts mit Arroganz zu tun - es ist einfach angebracht. Wie schon
> andernorts erwähnt, wenn man keinerlei Interaktion mit der Restwelt
> beabsichtigt, kann man problemlos in irgendwas Programmieren.
> Andernfalls eben nicht.
>
> BTW: Ich liebe Delphi. Nützt nur nix.

Es mag sein, dass die ehemals Delphi und jetzt Freepascal Programmierer 
prozentual vielleicht im einstelligen Bereich sind. Sie sind aber ganz 
sicher nicht 'vom Rest der Welt' abgeschnitten.

Ich hoffe noch auf einen Compiler, der Pascal und C kann.
Vielleicht kann Freepascal das irgendwann (zumindest die Header Dateien, 
z.B. die von den STM32 ARM Controllern).

Ebenfalls ist die Firma Mikroelektronika, die C, Basic und 
Pascalcompiler im Angebot haben nicht vom Rest der Welt abgeschnitten, 
ganz im Gegenteil.

http://www.mikroe.com/news/view/577/mikroelektronika-s-ceo-pronounced-entrepreneur-of-the-year-2012-in-our-home-country

von Der Rächer der Transistormorde (Gast)


Lesenswert?

Rainer S. schrieb:
> Ich überlege jetzt evtl. auf C umzusteigen bevor es "zu spät" ist.


Im embedded Bereich ist alles was ich gesehen habe in C (oder 
Assembler). Alle libs, app-note Bespiele, Compiler der Hersteller etc 
pp.

Welche Sprache die tollere ist spielt doch wohl keine Rolle, jede hat 
ihre Macken (und auch jeder compiler).

Auf irgendwas musste man sich halt einigen, durchgesetzt hat sich eben 
C.

Nicht ohne Grund, C macht auf µC's Sinn da es eine Sprache ist die für 
Betriebssysteme designt wurde. Nichts anderes macht man auf einem µC 
ohne OS, man schreibt ein OS.

Zweiter Grund C ist per design "portabel" (was immer man davon halten 
mag).

Das kommt einem zu Gute wenn man von einem Controller auf einen anderen 
umschreibt (auch und gerade innerhalb der selben Herstellermarke) oder 
wenn man 3rd Party code verwendet. Das ist ständig der Fall, es sei denn 
man will jeden USB Stack und jede SD-Card Anbindung unbedingt selbst 
schreiben.

von Mike Krüger (Gast)


Lesenswert?

Dauergast schrieb:
> BTW: Ich liebe Delphi. Nützt nur nix.

Die Frage ist nur: Liebt dein Delphi auch dich?

von Karl H. (kbuchegg)


Lesenswert?

Andreas H. schrieb:
> Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind
> endlich mal vorbei :/
>
> Karl Heinz Buchegger schrieb:
>> Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.
>
> Wird Gründe haben. Versuch doch mal ernsthaft einen High-performance
> backward-chainer zu schreiben^^. Warrens Artikel zu diesem Thema kann ja
> wirklich keiner lesen ;-)
>
> Und btw.: Der Observation scheduler des Hubble Teleskops ist übrigens in
> Lisp geschrieben, wie viel anderes Zeug auch. Auch Fortran erfreut sich
> immer noch groser Beliebtheit.
>
> Gibt vielleicht doch etwas mehr Anwendungen, die wir hier nicht wirklich
> durchblicken ?
> Die Leute, die sowas SO programmieren, wie sie es machen, sind ja auch
> nicht gegen den Schrank gelaufen^^

Natürlich nicht. Das wollte ich damit auch nicht sagen.
Nur werde ich im Umkreis von 200 Kilometer um meinen Standort eher kaum 
einen potentiellen Auftraggeber finden, der sich auf Cobol, Fortran oder 
Prolog versteift. Und diejenigen, die solche Aufträge haben, ... an die 
kommst du als Neuling nicht oder nur sehr schwer ran. Da sitzen die 
Stammprogrammierer drauf, wie die Hennen auf den Eiern.


PS: Mein erster Industriejob war in Fortran. Das war allerdings 1988 und 
die PC-Szene steckte damals noch in den Kinderschuhen. Wenns damals nach 
mir gegangen wäre, wäre sie dort auch geblieben. Mir war die VAX lieber. 
Aber hilft ja nichts. Wenn du 2 Jobs auf einer VAX angeboten kriegst und 
30 auf einem PC, dann muss man auch mal über seinen Schatten springen 
und die Zeichen der Zeit erkennen.

> Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind
> endlich mal vorbei :/

Daraus will ich mich eigentlich auch raushalten.
Zum einen, weil ich sie nicht für zielführend halte, zum anderen weil 
sie einfach Unsinn ist. Wer seine Sprache beherrscht, für den stellt 
sich die Frage nicht.

Allerdings finde ich die Ausgangsfrage nicht fair. Ich kann nicht auf 
der einen Seite fragen, ob man von Pascal auf C wechseln soll und auf 
der anderen Seite dann alles mit dem Argument beiseite wischen, dass man 
ja so eine große Codebasis hätte, die man nicht verwerfen will. Denn was 
anderes kommt da eh nicht raus. Auch C ist kein Wunderwuzzi, mit dem 
alles automatisch gehen würde, was man in Pascal ausprogrammieren muss. 
Da muss ich mich fragen: Mit welcher Erwartungshaltung geht der 
Fragesteller an die Frage heran? Was verspricht er sich von einem 
Wechsel?

> Was spricht für C?
Die einzige vernünftige Antwort, die mir darauf einfällt ist:
Technisch nichts bzw. nicht viel. Praktisch hast du in C sehr 
wahrscheinlich eine größere Community in diversen Newsgroups, Foren und 
Blogs. Und eine größere Nachfrage am Arbeitsmarkt.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Ich hatte mal an der Uni mit Pascal angefangen.

Irgendwann auch C. Es ist erheblich weniger Tipparbeit, ich halte
den Code auch für klarer und besser lesbar. Nebenbei gibt es für
jeden Feld-, Wald- und Wiesenmaschine einen C-Compiler.

Ich mag C ;)

von Rainer S. (rsonline)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Allerdings finde ich die Ausgangsfrage nicht fair. Ich kann nicht auf
> der einen Seite fragen, ob man von Pascal auf C wechseln soll und auf
> der anderen Seite dann alles mit dem Argument beiseite wischen, dass man
> ja so eine große Codebasis hätte, die man nicht verwerfen will. Denn was
> anderes kommt da eh nicht raus. Auch C ist kein Wunderwuzzi, mit dem
> alles automatisch gehen würde, was man in Pascal ausprogrammieren muss.
> Da muss ich mich fragen: Mit welcher Erwartungshaltung geht der
> Fragesteller an die Frage heran? Was verspricht er sich von einem
> Wechsel?

Die große Codebasis ist ein PC Programm, das bleibt wohl auch in Pascal.
Die Mikrocontroller haben eine eher vergleichsweise kleine Codebasis.

Ich habe die AVR's bis vor Kurzem zu 100% in Assembler programmiert. Mit 
dem beigelieferten Assembler von Atmel. Vorher habe ich 8051 Prozessoren 
in Assembler programmiert. Die AVR Assemblerprogramme nach Pascal zu 
migrieren dauert einige Tage/Wochen. Der Pascalcompiler von 
Mikroelektronia arbeitet voll zufriedenstellend und ist einfach in der 
Handhabung.

Ein Umstieg der fertigen AVR Pascalprogramme nach C würde vermutlich 
schneller gehen.

Der Hauptknackpunkt sind halt die Headerdateien für die sehr 
umfangreichen STM32 (und andere) ARM Controller. Langfristig ist ein 
Umstieg auf ARM sicher der sinnvollste Weg. Deswegen kam die Frage auf. 
Mikroelektronika hat hier Pascal-konforme Bibliotheken. Allerdings sind 
diese wohl nur in Binärform vorhanden, aber immerhin.

Ein Aspekt, der hier bei der Diskussion für mich neu aufgekommen ist, 
aber der für mich wohl nicht relevant ist, ist die größere Nachfrage am 
Arbeitsmarkt. Ich hatte nicht unbedingt vor, als Sub Unternehmer für 
eine andere Firma zu arbeiten.

von Uhu U. (uhu)


Lesenswert?

Rainer S. schrieb:
> Ich denke, wenn Du noch nicht mal auf das eingehst was man Dir praktisch
> vor der Nase hält ist das mit Deinen softwaretechnischen Leistungen
> nicht weit her.

Aber wenn du genauso verfährst, ist das in Ordnung, was?

> Ich hoffe noch auf einen Compiler, der Pascal und C kann.

Au weia...

von Andreas H. (ahz)


Lesenswert?

Karl Heinz Buchegger schrieb:
>> Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind
>> endlich mal vorbei :/
>
> Daraus will ich mich eigentlich auch raushalten.
> Zum einen, weil ich sie nicht für zielführend halte, zum anderen weil
> sie einfach Unsinn ist. Wer seine Sprache beherrscht, für den stellt
> sich die Frage nicht.
Ich sehe schon, wir sind einer Meinung :-)

> Mir war die VAX lieber
Mir auch ;-)

Grüße
Andreas

von Reinhard Kern (Gast)


Lesenswert?

Rainer S. schrieb:
> Und weiter ist es in weiten Teilen üblich, dass
> man die Quellen nicht herausgibt.
>
> Schon mal davon gehört?

Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind, 
teilweise mit verlorenen Investionen im Hunderttausender-Bereich. Die 
machen den Fehler, sich dagegen nicht abzusichern, aber nur einmal, beim 
nächsten Projekt fragen sie sehr wohl was aus der Software werden soll, 
wenn der Programmierer stirbt  überlastet ist  in Insolvenz geht / 
grössenwahnsinnig wird oder auch einfach keine Lust mehr hat. Und dabei 
spielt eben auch eine Rolle, in welcher Sprache die Software erstellt 
wurde.

Rainer S. schrieb:
> Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte.

Diese Antwort auf das Problem ist einfach nur eine Frechheit, und zudem 
beweist sie weitgehende Unkenntnis, denn es gibt Tausende alte 
Programme, die aus verschiedensten Gründen unter Windows 7 oder 8 nicht 
mehr laufen. Wenn du deine Kunden so behandeln kannst, deine Sache. Ich 
arbeite eher für internationale Konzerne, das ist eine andere Welt. Z.B. 
deswegen, weil die eine Rechtsabteilung mit unbegrenzten Resourcen zum 
Einsatz bringen können.

Karl Heinz Buchegger schrieb:
> Die einzige vernünftige Antwort, die mir darauf einfällt ist:
> Technisch nichts bzw. nicht viel.

Das ist aber zugleich die Antwort darauf, warum soviel C in der Welt 
ist: C ist so einfach strukturiert, dass es für einen Hersteller eines 
Prozessors mit Abstand am einfachsten ist, einen C-Compiler dafür zu 
erstellen.

Gruss Reinhard

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?


von Dauergast (Gast)


Lesenswert?

Mike Krüger schrieb:
> Liebt dein Delphi auch dich?

Es tut im Prinzip alles, was ich will, wie ich es will, ohne jegliche 
Zickerei - ob man das Liebe nennen kann oder sollte, weiß ich nicht ;-)

Wenn allerdings eine Developer Preview irgendeines OS, eine neue 
Hardware oder eine neues Protokoll irgendwo auftaucht, gibt es C-Header, 
C-Objects bzw. C-Libs, manchmal C-Source ... und ganz sicher nichts, mit 
dem Delphi was anfangen könnte. Ähnlich verhält es sich auf µCs.

von ah. (Gast)


Lesenswert?

Ich hab aufm PC immer mit Delphi gearbeitet, und auf Embedded auch mit 
einem Pascal. Es ist einfach besser selbstdokumentiert. Ich kann den 
Code auch nach 10 Jahren noch schneller lesen und verstehen.

Bisher hatte ich noch nirgends, aeh keiner Firma, Probleme mit Pascal. 
Denn meine Leistung ist nicht Code, sondern ein geloestes Problem. Und 
wenn das Problem geloest ist .. Deckel drauf und Next.
Falls denn irgendwann mal ein Nachfolger den Code anschauen sollte, ist 
er leichter verstaendlich wie ein C. Ist eben so.
Und da dann die Bedingungen drum herum eh sehr anders sind, muss man's 
eh neu schreiben.

Ich sag mir .. das Leben ist viel zu kurz fuer C.

von Karl H. (kbuchegg)


Lesenswert?

Joe G. schrieb:
> etwas Öl ins Feuer...
>
> http://www.bernd-leitenberger.de/pascal-und-c.shtml

Na ja.
Jeder der C einigermassen kennt, sieht da aber recht schnell, dass Bernd 
von C nicht wirklich Ahnung hat, sondern hauptsächlich rummosert. Und 
das zum Teil falsch und zum Teil mit falschen Argumenten.

Dieses Pamphlet kann man nicht wirklich ernst nehmen.
Was nicht heissen soll, dass man an C keine Kritik üben kann/darf. 
Überhaupt nicht. Es gibt genug Kritikpunkte und einige davon spricht 
Bernd sogar an (zb enum). Dafür haut er an anderen Stellen wieder 
dermassen daneben.

Ist ungefähr so, wie wenn ich Prolog kommentieren müsste. Ein bißchen 
Prolog kann ich, aber für eine ernsthafte Kritik reicht es bei weitem 
nicht.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Reinhard Kern schrieb:
> Rainer S. schrieb:
>> Und weiter ist es in weiten Teilen üblich, dass man die Quellen nicht
>> herausgibt. Schon mal davon gehört?
> Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind,
> teilweise mit verlorenen Investionen im Hunderttausender-Bereich. […]

Ich verstehe nicht ganz, warum du Rainer (sogar wiederholt) so heftig 
angreifst, nur weil er nicht den Quellcode seiner Software herausrückt. 
Das tun doch die allerwenigsten Softwarefirmen. Oder bekommst du als 
Käufer von MS-Word, Eagle, Oracle oder SAP etwa immer schön brav den 
Quellcode mitgeliefert? Ich würde das zwar auch gbegrüßen, kann aber 
auch verstehen, dass die Firmen mit Closed-Sorce ihre 
Entwicklungsaufwendungen schützen wollen.

Eine Ausnahme bilden Auftragsentwickler, die  kundenspezifische Software 
entwicklen und vom Kunden nicht für das Produkt, sondern die 
Entwicklungsarbeit bezahlt werden. Da ist es üblich, auch den Quellcode 
auszuliefern, sofern der Kunde das möchte. Aber zu den 
Auftragsentwicklern gehört Rainer wohl eher nicht:

Rainer S. schrieb:
> Ich hatte nicht unbedingt vor, als Sub Unternehmer für eine andere Firma
> zu arbeiten.

von Hans-Georg L. (h-g-l)


Lesenswert?

cppler schrieb:

> PASCAL ist ja auch nicht wegen Wirth so populär geworden, sondern wegen
> der Funktionalität von TurboPASCAL, lag also weniger an der Sprache
> sondern den Bibliotheken dafür.

Da muss ich wiedersprechen, Borland hat damals mit dem TurboPascal die 
Sprache erweitert, weil Pascal eben nicht wie C durch Bibliotheken 
erweiterbar ist.

In Wirths Pascal kannst du z.B. keine Tasten abfragen, weil alle 
Eingaben mit CR abgeschlossen sein müssen. Um die Pfeiltasten an einem 
VT100 damals zu benutzen musste ich auf der VAX ein Fortran Programm für 
die Tasten Abfrage dazu linken ;) Und die Strings nannte man auch damals 
noch varying char of. Und Pascal war nicht Pascal, das Umschreiben eines 
HP
Pascal Programmes in ein DEC Pascal war nicht trivial ;)

Mit Turbo Pascal konnte man wirklich arbeiten aber das gabs damals nur 
auf PC's unter Dos. Leider hat Borland dann weitergemacht und viel zu 
viel an der Sprache weiter herumgebastelt und alles ist nicht genormt, 
deshalb bin ich schon sehr früh auf C umgestiegen und geblieben.

von Hans-Georg L. (h-g-l)


Lesenswert?

Rainer S. schrieb:
> Ich hoffe noch auf einen Compiler, der Pascal und C kann.

Der nennt sich C-Compiler ..

Einfach mit einem Makro {} durch Begin End ersetzen ...

Alles schon gesehen ...

von Hans-Georg L. (h-g-l)


Lesenswert?

Dauergast schrieb:
> BTW: Ich liebe Delphi. Nützt nur nix.

Mike Krüger schrieb:
> Liebt dein Delphi auch dich?

National Instruments liebt Delphi jedenfalls nicht ;)

von Hans-Georg L. (h-g-l)


Lesenswert?

Rainer S. schrieb:
> Und weiter ist es in weiten Teilen üblich, dass
> man die Quellen nicht herausgibt.
>
> Schon mal davon gehört?

Ich sag immer:

Wenn die Konkurrenz die Quelltexte in die Hand bekommt, das wirft die um 
Jahre zurück

von Arc N. (arc)


Lesenswert?

Christian Berger schrieb:
> Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum.
> (Pascal basierend)
>
> C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst
> nach einem Assembler machen. C++ ist eher was für Masochisten, die eine
> Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist.

Wer Softwareentwicklung macht, muss andauernd lernen. Die Sprache ist da 
mittlerweile das kleinere "Übel". Auch wenn ich C++ nicht für die 
"beste" Sprache halte, es ist imo besser als viele Alternativen.
BTW: Sowohl Pascal, als auch C und C++ sind nicht typsicher.

> C# ist halt wie VBA eine reine Microsoftsache und selbst für
> nur-Windows-Projekte eine eher schlechte Wahl.

C# und VBA haben als Gemeinsamkeit nur die Herkunft. Rein Microsoft ist 
da schon lange nichts mehr (ISO/ECMA-Standard, Mono, Xamarin (Android, 
Mac/iOS) etc.). Die einzigen Gründe (für einen Teil eines Projektes) was 
anderes als C# zu nehmen sind heutzutage nur noch, wenn die maximale 
Geschwindigkeit herausgeholt werden soll, dann C bzw. C++ oder wenn das 
Projekt mit einer anderen Sprache begonnen wurde und eine Neuentwicklung 
zu aufwendig wäre.

> Wenn Du C machen willst, lies Dir erst mal "The Art of UNIX Programming"
> durch. http://www.faqs.org/docs/artu/
> Das Buch stellt ein Regelwerk vor, dass Dir für C und andere Sprachen
> helfen kann. Das hilft Dir dabei bessere Softwaresysteme zu entwickeln.

Gerade das Buch würde ich keinem empfehlen, da der Autor mindestens 
genauso ideologisch verblendet "argumentiert" wie rms.

von Frank K. (fchk)


Lesenswert?

Ich habe auch mit Turbo Pascal angefangen - auf CP/M und später dann 
DOS. Dann kam der Amiga, und da gab es 1987 kein Pascal, sondern nur C, 
und die gesamte Dokumentation war für Assembler und Lattice C, und so 
habe ich dann C gelernt und es nie bereut. Auf dem PC wurden Windows und 
OS/2 langsam reif, und auch das war eben C. Irgendwann war Pascal für 
mich einfach gestorben.

Ich finde den Support des jeweiligen Herstellers sehr wichtig. Wenn STM 
Keil, IAR und gcc unterstützen, dann werde ich wenn möglich einen der 
empfohlenen Compiler verwenden, einfach um Risiken zu vermeiden und Zeit 
zu sparen. Wenn Microchip seine Application Libraries nur für die 
hauseigenen Compiler anbietet, dann werde ich einen Teufel tun und den 
Mikroe Compiler verwenden. Wenn dann nämlich irgendwo ein Bug auftritt 
(der kann in der Software oder im Silizium sein), dann will ich meinen 
FAE oder Microchip anpieksen und fragen können, was das soll, und das 
kann ich nur, wenn ich einen der getesteten Compiler verwende. Nur dann 
können die das auch nachvollziehen und mir ggf bestätigen, dass ich 
einen Bug im Silizium gefunden habe, und wie ich den umgehe. Alles schon 
passiert.

Die Programmiersprache ist nur ein Werkzeug. Mit Pascal kann ich genauso 
leben wie mit Occam (kennt das noch jemand?). Und ob die 
Entwicklungsumgebung nun unter Linux läuft, ist mir sowas von egal. 
Meist ist das ganze unter Windows am Besten getestet, und dann nehme ich 
Windows.

Zum OP: Es ist für Dich vielleicht gar nicht schlecht, aus Deiner 
"Komfortzone" herauszukommen und Dich auf etwas neues einzulassen. 
Flexibel bleiben heißt das Zauberwort.

fchk

von Rainer S. (rsonline)


Lesenswert?

Reinhard Kern schrieb:
> Rainer S. schrieb:
>> Und weiter ist es in weiten Teilen üblich, dass
>> man die Quellen nicht herausgibt.
>>
>> Schon mal davon gehört?
>
> Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind,
> teilweise mit verlorenen Investionen im Hunderttausender-Bereich. Die
> machen den Fehler, sich dagegen nicht abzusichern, aber nur einmal, beim
> nächsten Projekt fragen sie sehr wohl was aus der Software werden soll,
> wenn der Programmierer stirbt  überlastet ist  in Insolvenz geht /
> grössenwahnsinnig wird oder auch einfach keine Lust mehr hat.

Was da genau passiert ist schreibst Du leider nicht dabei.
Insofern kann man nur spekulieren.

> Rainer S. schrieb:
>> Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte.
>
> Diese Antwort auf das Problem ist einfach nur eine Frechheit, und zudem
> beweist sie weitgehende Unkenntnis, denn es gibt Tausende alte
> Programme, die aus verschiedensten Gründen unter Windows 7 oder 8 nicht
> mehr laufen. Wenn du deine Kunden so behandeln kannst, deine Sache. Ich
> arbeite eher für internationale Konzerne, das ist eine andere Welt.

Und dann bist Du überfordert, wenn Embarcadero ein paar Tausend Euro 
haben will?
Beitrag "Re: C oder Pascal"
Oder ist das wieder eine andere Welt?

Für Windows programmiere ich schon lange nicht mehr. Mich zwingt auch 
kein Auftraggeber - aus einer anderen Welt - dazu.

> Z.B.
> deswegen, weil die eine Rechtsabteilung mit unbegrenzten Resourcen zum
> Einsatz bringen können.

Dann sollte es ja kein Problem sein, an den Quellcode des Entwicklers zu 
kommen. Für entsprechndes Geld wäre ich natürlich auch bereit das zu 
liefern.

Mir hat mal ein Kunde angeboten eine entsprechende Vereinbarung zu 
unterschreiben bei 100.000 Euro Strafe, wenn er die Sachen weitergeben 
sollte. Der Kaufpreis war erheblich geringer. Habe das abgelehnt. Habe 
dann mit einem Bekannten darüber gesprochen. Er meinte dann der 
Quellcode könnte ja auch z.B. vom Kunden durch irgendwen geklaut 
werden...

Hans-Georg Lehnard schrieb:
> Einfach mit einem Makro {} durch Begin End ersetzen ...

Wenn das so einfach wäre...

ah. schrieb:
> Es ist einfach besser selbstdokumentiert. Ich kann den
> Code auch nach 10 Jahren noch schneller lesen und verstehen.

Ja, genauso. Und wenn man C Quelltexte lesen muss tun einem schon mal 
die Augen weh. :-) Das ist zwar durch die { } Teile hochkomprimiert 
dargestellt. Dadurch muss man aber auch mehr Informationen verarbeiten.

Yalu X. schrieb:
> Ich verstehe nicht ganz, warum du Rainer (sogar wiederholt) so heftig
> angreifst, nur weil er nicht den Quellcode seiner Software herausrückt.

Verstehe ich jetzt auch nicht so ganz.

von Reinhard Kern (Gast)


Lesenswert?

Yalu X. schrieb:
> Oder bekommst du als
> Käufer von MS-Word, Eagle, Oracle oder SAP etwa immer schön brav den
> Quellcode mitgeliefert?

Das ist eine unsinnige Argumentation, denen habe ich ja auch keinen 
Entwicklungsauftrag erteilt. Ich kenne aber einige Leute, die 
Software-Aufträge von 20 kEuro aufwärts vergeben hatten und dann mit 
einer nur so halbwegs funktionierenden Beta-Software und ohne jegliche 
Unterlagen einfach sitzengelassen wurden. Es ist sogar schon 
vorgekommen, dass man mir den Auftrag gern noch mal erteilt hätte, aber 
der gesamte Entwicklungsetat war schon weg für nichts und einfach nicht 
mehr genug Geld da.

Wenn man was auf eigenes Risiko und mit eigenem Geld entwickelt, ist das 
was anderes. Aber Autragsentwicklung von Software ist keineswegs bloss 
eine Ausnahme, längst nicht jede Firma, die ein Gerät entwickelt, hat 
auch eine eigene Softwareabteilung.

Gruss Reinhard

von Andreas H. (ahz)


Lesenswert?

Hans-Georg Lehnard schrieb:
> National Instruments liebt Delphi jedenfalls nicht ;)

Ich hab LabView im Kundenauftrag auch schon mal F90 fressen lassen.
Ging sogar ziemlich unblutig^^

Grüße
Andreas

von Rainer S. (rsonline)


Lesenswert?

Frank K. schrieb:
> Zum OP: Es ist für Dich vielleicht gar nicht schlecht, aus Deiner
> "Komfortzone" herauszukommen und Dich auf etwas neues einzulassen.
> Flexibel bleiben heißt das Zauberwort.

Ich habe schon mal in C++ programmiert.

Auf der embeddedWorld in Nürnberg habe ich Mikroe besucht und die Leute 
haben mich stark beeindruckt. Den Support sehe ich zur Zeit gegeben. 
Wenn das mal irgendwann nicht mehr sein sollte gibt es vielleicht 
Alternativen, die momentan noch nicht reif sind.

Wie gesagt, das beste wäre ein C++ und Pascal Compiler in einem.

Damit könnte ich leben :-)

Reinhard Kern schrieb:
> Es ist sogar schon
> vorgekommen, dass man mir den Auftrag gern noch mal erteilt hätte, aber
> der gesamte Entwicklungsetat war schon weg für nichts und einfach nicht
> mehr genug Geld da.

Da hab' ich aber jetzt nix mit zu tun.

Ich kenne es eher anders herum. Die Kunden wollen nicht genug zahlen. 
Bzw. man muss den Preis so attraktiv machen, dass die Kunden kaufen. Und 
dann soll ich auch noch den Quellcode herausrücken? Außerdem 
interessieren sich nur die wenigsten dafür, geschweige denn dass die 
wissen was ein Quellcode ist.

von Andreas H. (ahz)


Lesenswert?

Reinhard Kern schrieb:
> längst nicht jede Firma, die ein Gerät entwickelt, hat
> auch eine eigene Softwareabteilung.

Es ist leider noch viel schlimmer.

Manche Firma HAT eine eigene Softwareabteilung. Leider ist da auch öfter 
die Qualität unterirdisch. Es reicht eben nicht im Studium einmal eine 
1-Semester Kurs zu machen und dann Applications für Endkunden zu 
entwickeln.

Aber, sieh es positiv. Das sind alles potentielle Kunden für Dich ;-)

Grüße
Andreas

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

Mit dem Support ist nicht der von Mikroe zu ihrem Compiler gemeint, 
sondern dass die Chip-Hersteller die Hardaware und den Compiler 
supporten.

Im Fehlerfall kann das Tage an debugging sparen, weil der Hersteller 
sich drum kümmert.

Der wird sich aber nicht drum scheren, wenn du irgend einen Compiler 
verwendest, kann ja schliesslich an diesem Compiler liegen.

Und m.M.n sind Compiler die vom Hersteller gewartet werden sowie 
OpenSource Lösungen deutlich im Vorteil gegenüber einem Compiler einen 
kleinen Firma, die in den nächsten paar Tagen dicht machen könnte oder 
gar nicht die kapazitäten hat sich zeitnah um die Probleme zu kümmern.

von ABAP (Gast)


Lesenswert?

SAP liefert schon immer Quelltext aus. Früher (R/2) wurden die 
Assemblerquellen erst auf den Kundenrechnern übersetzt, ganz so wie man 
es heute von UNIX OSS Paketen kennt.
Heute gibt's die gesamte ABAP Source der Anwendungen, die dann bei 
erster Benutzung in "ByteCode" übersetzt werden. Nur der C(++)-Kernel 
(inkl. VM) kommt ohne Source.
Soviel zum Gerücht von Xalu X.

von Yalu X. (yalu) (Moderator)


Lesenswert?

ABAP schrieb:
> Nur der C(++)-Kernel (inkl. VM) kommt ohne Source.

Eben. Und was heißt da "nur"? Der Kernel ist, wie der Name schon sagt, 
die zentrale Komponente des Systems, ohne die die ganzen ABAP-Module 
wertlos sind, selbst wenn sie im Quellcode vorliegen.

von Rene H. (Gast)


Lesenswert?

Ich denke ihr redet aneinander vorbei, abgesehen das es nichts zum Thema 
beiträgt. Bei einer Auftragsenwicklung gehört der Code bei, inkl. UML 
und ordentlicher Dokumentation. Punkt. Da gibts nichts zu ändern.

Bei einer Eigenentwicklung kann man, muss man nicht. Ich habe viele 
Sourcen öffentlich freigegeben, nur diejenigen welche mein Geschäft 
ausmachten nicht.

Grüsse,
R.

von Brater (Gast)


Lesenswert?

Joe G. schrieb:
> etwas Öl ins Feuer...
>
> http://www.bernd-leitenberger.de/pascal-und-c.shtml

Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist 
sogar ein Fehler drin :P

> int x;
> x=5;
> --x=(++x)--;
>
> Nein, das Ergebnis ist nicht 4 sondern 6.

Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS 
2010 gab mir Recht. Niemand wird gezwungen so einen Müll zu 
programmieren. Ja es geht - na und? In Cpp geht auch 10fach-Vererbung - 
trotzdem macht das wahrscheinlich kaum einer, weil es sehr hässlich 
werden KANN.

Ich weiß nicht, ob jemand von euch mal in den Geschmack von Oberon 
gekommen ist. Ich fand diese Sprache (auch von Niclaus Wirth) 
schrecklich. Man macht dank ALLER UPPERCASE OPERATOREN seine shift-Taste 
kaputt. Dummerweise waren trotzdem nicht alle Befehle Upercase sodass 
das alles sehr merkwürdig war.

Und ja, ich habe Programmieren auch mal in Pascal gelernt - trotzdem 
gibt es schönere Sprachen und ich könnte heute nicht mehr auf Pascal 
zurück. Aber ich sehe das auch etwas pragmatischer: wenn man einmal über 
10 - 15 Sprachen ausprobiert hat, wird man sich wahrscheinlich diejenige 
aussuchen, die für das entsprechende Problem passt... z.B. C/Cpp für muC 
(weil es schnell ist und an sich gut geht), C# für Windoofs-Sachen (weil 
die GUIs gut gehen und die Software gut wartbar ist), Autohotkey für 
Hack-Gefrickel/Scripting-Kram (weil es einfach ist und damit Simulation 
von Benutzereingaben gut gehen - auch wenn das ebenfalls in C# oder C 
ginge).

von Yalu X. (yalu) (Moderator)


Lesenswert?

Brater schrieb:
> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist
> sogar ein Fehler drin :P
>> int x;
>> x=5;
>> --x=(++x)--;
>> Nein, das Ergebnis ist nicht 4 sondern 6.
> Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS
> 2010 gab mir Recht.

Die Codezeile mit den ++ und -- ist kein korrektes C, deswegen sollte 
der Compiler eine Fehlermeldung ausgeben. GCC tut das auch:
1
test.c:8:12: error: lvalue required as decrement operand

Kar Heinz hat schon recht, wenn er oben schreibt:

Karl Heinz Buchegger schrieb:
> Jeder der C einigermassen kennt, sieht da aber recht schnell, dass Bernd
> von C nicht wirklich Ahnung hat, sondern hauptsächlich rummosert. Und
> das zum Teil falsch und zum Teil mit falschen Argumenten.

In C++ (was aber nicht das Thema des verlinkten Artikels ist) ist der 
Ausdruck prinzipiell erlaubt, liefert aber ein undefiniertes Ergebnis. 
Dabei gibt GCC eine Warnung aus, die auf jeden Fall ernst genommen 
werden sollte:
1
test.c:8:14: warning: operation on ‘x’ may be undefined [-Wsequence-point]

Deswegen braucht auch nicht darüber zu diskutiert werden, ob das 
Ergebnis 4 oder 6 ist. Beides ist gleichermaßen richtig oder falsch. GCC 
liefert übrigens weder 4 noch 6, sondern 5.

von G. C. (_agp_)


Lesenswert?

Yalu X. schrieb:
> Brater schrieb:
>> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist
>> sogar ein Fehler drin :P
>>> int x;
>>> x=5;
>>> --x=(++x)--;
>>> Nein, das Ergebnis ist nicht 4 sondern 6.
>> Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS
>> 2010 gab mir Recht.
>
> Die Codezeile mit den ++ und -- ist kein korrektes C, deswegen sollte
> der Compiler eine Fehlermeldung ausgeben. GCC tut das auch:
>
>
1
> test.c:8:12: error: lvalue required as decrement operand
2
>

Pelles C meckert auch

: error #2088: Lvalue required.

Visual C++ 2008 Express Edition moniert ebenfalls

error C2105: '--' muss ein L-Wert sein
error C2106: '=': Linker Operand muss ein L-Wert sein

allerdings nur dann, wenn der Quellcode als .c compiliert wird.

Als main.cpp geht's fehlerfrei durch. Ergebnis 4.

von Uhu U. (uhu)


Lesenswert?

Brater schrieb:
> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist
> sogar ein Fehler drin :P
1
C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem Entwurf
2
von Programmiersprachen hatten. Es ist sehr unübersichtlich und unlogisch.

Das ist auch niedlich...

von Rainer S. (rsonline)


Lesenswert?

Uhu Uhuhu schrieb:
> Brater schrieb:
>> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist
>> sogar ein Fehler drin :P
> C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem
> Entwurf
> von Programmiersprachen hatten. Es ist sehr unübersichtlich und
> unlogisch.
>
> Das ist auch niedlich...

Das mag etwas übertrieben ausgedrückt sein, aber ich sehe das ähnlich. 
Jedoch ist C doch schon in irgend einer Form logisch. Man braucht halt 
länger um den Code zu verstehen/entschlüsseln. Es sei denn man hat den 
Code selbst geschrieben.

von Andreas H. (ahz)


Lesenswert?

Uhu Uhuhu schrieb:
> C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem
> Entwurf
> von Programmiersprachen hatten. Es ist sehr unübersichtlich und
> unlogisch.

Naja, es hat bei den Entwicklern immerhin für das Dragonsbook gereicht. 
Ich denke schon, dass sie wussten, was sie tun.

Ich vermute eher, das damalige HW Restriktionen ihren Tribut forderten. 
Da ist man ja heute "etwas" verwöhnter.
Aber lass doch mal eine aktuelle JRE auf einer 1MIPS/256K (RAM, nicht 
Cache) Maschine laufen^^

Grüße
Andreas

von Uhu U. (uhu)


Lesenswert?

Andreas H. schrieb:
> Uhu Uhuhu schrieb:
>> C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem
>> Entwurf
>> von Programmiersprachen hatten. Es ist sehr unübersichtlich und
>> unlogisch.

Das habe ich nicht geschrieben, sondern aus dem oben verlinkten 
Pamphlet zitiert.

Wenn du zitierst, dann bitte nicht derart grob entstellen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Andreas H. schrieb:
> Naja, es hat bei den Entwicklern immerhin für das Dragonsbook gereicht.

Die Bücher mit dem Drachen wurden nicht von den C-Entwicklern 
geschrieben. Immerhin hatten sie aber den gleichen Arbeitgeber.

von Andreas H. (ahz)


Lesenswert?

Uhu Uhuhu schrieb:
> Das habe ich nicht geschrieben, sondern aus dem oben verlinkten
> Pamphlet zitiert.
>
Oh, sry. Das war für mich nicht als Zitat erkennbar (wo, sagtst Du, hast 
Du die Quelle angegeben ?)

Viele Grüße
Andreas

von Andreas H. (ahz)


Lesenswert?

Yalu X. schrieb:
> Die Bücher mit dem Drachen wurden nicht von den C-Entwicklern
> geschrieben.

Stimmt. Ich dachte immer, dass das die gleiche Arbeitsgruppe war.

Grüße
Andreas

von Karl H. (kbuchegg)


Lesenswert?

Rainer S. schrieb:

>
> Das mag etwas übertrieben ausgedrückt sein, aber ich sehe das ähnlich.
> Jedoch ist C doch schon in irgend einer Form logisch.

Ich finde C eigentlich gar nicht so schlimm.
Gut, zugegeben, bei manchen Dingen braucht man schon seine Weile, bis 
man die Logik verstanden hat (die oft viel einfacher ist, als man 
ursprünglich dachte), aber im Großen und Ganzen finde ich nicht, dass C 
grob unlogisch wäre.

> Man braucht halt
> länger um den Code zu verstehen/entschlüsseln.

Alles Gewohnheitssache. Die Dichte an Sonderzeichen ist ein klein wenig 
höher (in einem realen Programm, nicht in diesen aufgemotzen 'Ich zeige 
mal was in C noch so alles geht' Beispielen), aber wenn man die 
wichtigsten erst mal intus hat, ist das halb so wild.

Überhaupt muss man gerade bei C sehr aufpassen.
Da werden oft Beispiele präsentiert, mit denen Punkte untermauert werden 
sollen, die tatsächlich ekelhaft sind. Die aber in einem Programm aus 
der realen Welt niemals vorkommen würden und wenn, dann würde der 
Programmierer von seinem Vorgesetzten mit dem nassen Fetzen erschlagen.

Was natürlich stimmt: In C gibt es kein Sicherheitsnetz. Daran muss man 
sich gewöhnen. Array-Out-Of-Bounds Addressierung interessiert weder 
Compiler noch Runtime sondern ist das Bier des Programmierers.

C hat halt die Prämisse "You don't get, what you didn't ask for".

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Uhu Uhuhu schrieb:
> Wenn du zitierst, dann bitte nicht derart grob entstellen.

Das aber auch sowenig Öl sooo lange reicht, das hätte ich jetzt nicht 
gedacht ;-) Also hier etwas "Gegenöl":
http://www.familientherapie-essen.de/PDFe/zwei_Moenche.pdf

von Uhu U. (uhu)


Lesenswert?

Karl Heinz Buchegger schrieb:
> Ich finde C eigentlich gar nicht so schlimm.
> Gut, zugegeben, bei manchen Dingen braucht man schon seine Weile, bis
> man die Logik verstanden hat (die oft viel einfacher ist, als man
> ursprünglich dachte), aber im Großen und Ganzen finde ich nicht, dass C
> grob unlogisch wäre.

Die Pointerarithmetik von C ist sowas von logisch - und wird von 
Halbwissern natürlich entweder nicht registriert, oder nicht 
verstanden...

von Yalu X. (yalu) (Moderator)


Lesenswert?

Uhu Uhuhu schrieb:
> Die Pointerarithmetik von C ist sowas von logisch

Nicht nur die:

Ein Großteil der Sprachelemente erschließen sich einem sofort.

Einige Dinge erscheinen auf den erste Blick seltsam bis unlogisch, sind 
aber nachvollziehbar und gut zu merken, wenn man sich die technischen 
Gründe dafür vor Augen hält (bspw. die Behandlung von Arrays).

Einige Dinge sind zwar logisch, aber für Nutzer anderer 
Programmiersprachen ungewohnt (Syntax von Datentypen).

Einige Dinge sind zwar logisch halbwegs sinnvoll, aber schwer zu merken 
(bspw. die Integer-Promotion).

Ein paar wenige, wirklich schräge Dinge bleiben (bspw. die 
Operatorrangfolge von &, ^ und | im Vergeleich zu == und !=). Die haben 
keine technischen, sondern historische Gründe (Abwärtskompatibilität).

Die Forderung nach Abwärtskompatibilität ist der größte 
Verschmutzungsfaktor in der Evolution von Programmiersprachen, und das 
betrifft nicht nur C, sondern jede Sprache, die älter als etwa 10 Jahre 
ist.

von Rainer S. (rsonline)


Lesenswert?

Yalu X. schrieb:
> Die Forderung nach Abwärtskompatibilität ist der größte
> Verschmutzungsfaktor in der Evolution von Programmiersprachen, und das
> betrifft nicht nur C, sondern jede Sprache, die älter als etwa 10 Jahre
> ist.

Ist bei Freepascal auch ein ganz großes Thema.
Das muss alles kompatibel zu allen möglichen Derivaten sein.

von Timbo1 (Gast)


Lesenswert?


von Klaus W. (mfgkw)


Lesenswert?

Wieso C++?

von Christopher C. (Gast)


Lesenswert?

Free Pascal sieht wirklich nicht schlecht aus, Respekt an die 
Entwickler. Ich hab ein bisschen damit herumgespielt und frage mich ob 
ObjPascal nun automatisierte Destruktoren hat oder warum die bei mir 
nicht funktionieren wollen. Falls es die nicht gibt, wäre das ein großes 
Manko gegenüber C++. RAII ist das was C++ zurzeit so stark macht.

Hier mal der Code:
1
program Test;
2
3
{$mode objfpc}{$H+}
4
5
type
6
  TFish = class
7
  public
8
    constructor Create; override;
9
    destructor Free; override;
10
  end;
11
12
constructor TFish.Create;
13
begin
14
  writeln('blubb');
15
end;
16
17
destructor TFish.Free;
18
begin
19
  writeln('blubb');
20
end;
21
22
var
23
  fish: TFish;
24
begin
25
  fish := TFish.Create;
26
  //fish.Free;
27
end.
Es kommt kein zweites blubb.

Getestet mit:
1
Free Pascal Compiler version 2.6.2 [2013/02/16] for i386
unter Linux x86_64.

von (prx) A. K. (prx)


Lesenswert?


von Christopher C. (Gast)


Lesenswert?

Habe ein bisschen recherchiert, tja einen automatischen Aufruf des 
Destruktors scheint es einfach nicht zugeben. Ach Leute das ist doch 
Scheiße. Man wird ja nicht einmal gewarnt, dass man den Destruktor nicht 
aufruft und, das auch noch wenn die Variable lokal zu einer Funktion 
gehört -.-. Tut mir Leid, auch wenn ich C++ für ein verdammtes Monstrum 
halte, das macht C++ definitiv besser. Damit ist Free Pascal nix für 
mich. Schade.

Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende 
Alternative in der Systemprogrammierung gibts immer noch nicht. In der 
Anwendungsprogrammierung siehts eigentlich auch nicht anders aus, nix 
natives mehr, nur noch dieser over bloated Scheiß wie Java. Und das sage 
ich obwohl ich C# sehr mag, aber warum gibts nicht mal eine Sprache die 
resourcenschonend UND angenehm zu benutzen zugleich ist, natürlich mit 
Zeigerarithmetik und Kontrolle ob nun ein Objekt auf den Stack oder Heap 
landet. Wenn die Sprache einen GCC aufzwingt ists sowieso vorbei, RAII 
ist besser.

von Guido B. (guido-b)


Lesenswert?

Christopher C. schrieb:
> das auch noch wenn die Variable lokal zu einer Funktion
> gehört -.-.

Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern
verstanden hast? Das Objekt wird mit create auf dem Heap angelegt,
ist damit quasi global. Es darf dementsprechend nicht einfach
destroyed werden, wenn eine Prozedur beendet wird. Stell es dir
als einfache Pointerliste vor, die durch so eine Automatik brechen
würde.

von Arc N. (arc)


Lesenswert?

Guido B. schrieb:
> Christopher C. schrieb:
>> das auch noch wenn die Variable lokal zu einer Funktion
>> gehört -.-.
>
> Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern
> verstanden hast? Das Objekt wird mit create auf dem Heap angelegt,
> ist damit quasi global. Es darf dementsprechend nicht einfach
> destroyed werden, wenn eine Prozedur beendet wird.

Das ginge problemlos, wenn feststeht das nichts anderes auf dieses 
Objekt zeigt. Was hier im Beispiel sogar vom Compiler festgestellt 
werden kann und Delphi seit Ewigkeiten für einige interne Typen macht 
und mittlerweile wohl auch darüber hinaus 2). Ansonsten wäre die 
einfachste Methode reference counting (Problem: heap fragmentation, das 
aber für viele Fälle gelöst ist 1)), wie das automatisch funktioniert s. 
z.B. 3)

1) u.a. The Memory Fragmentation Problem: Solved?, Johnstone, Wilson, 
1997
2) 
http://docwiki.embarcadero.com/RADStudio/XE4/de/Automatische_Referenzz%C3%A4hlung_in_mobilen_Delphi-Compilern
3) http://clang.llvm.org/docs/AutomaticReferenceCounting.html

von Guido B. (guido-b)


Lesenswert?

Klar lässt sich das machen, ist die Aufgabe eines
Garbage-Collectors. Aber ohne diesen kann man doch das
Objekt beim Verlassen einer Prozedure nicht einfach
wegräumen?

von Jedem das Seine (Gast)


Lesenswert?

Christopher C. schrieb:
> Falls es die nicht gibt, wäre das ein großes
> Manko gegenüber C++.

Christopher C. schrieb:
> Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende
> Alternative in der Systemprogrammierung gibts immer noch nicht.

Wat ne Laberei: Es werden wieder Äpfel mit Birnen verglichen.
1. C ist nicht C++
2. Pascal ist nicht Delphi
3. In einem anderen Thread zu gleichen Thema wurde ermittelt, dass es 
nur eine Sache in C gibt, die nicht in Pascal umgesetzt werden kann.
Ob das so wichtig ist, möge jeder selbst entscheiden.

von Christopher C. (Gast)


Lesenswert?

Jedem das Seine schrieb:
> Christopher C. schrieb:
>> Falls es die nicht gibt, wäre das ein großes
>> Manko gegenüber C++.
>
> Christopher C. schrieb:
>> Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende
>> Alternative in der Systemprogrammierung gibts immer noch nicht.
>
> Wat ne Laberei: Es werden wieder Äpfel mit Birnen verglichen.
> 1. C ist nicht C++
> 2. Pascal ist nicht Delphi
> 3. In einem anderen Thread zu gleichen Thema wurde ermittelt, dass es
> nur eine Sache in C gibt, die nicht in Pascal umgesetzt werden kann.
> Ob das so wichtig ist, möge jeder selbst entscheiden.

Das ist mir alles bewusst und insofern ist es auch gar nicht die Schuld 
der Sprachen selbst, nur ist die ganze IT Branche (bis auf die 
exotischen Bereiche) total fixiert auf C und C++. Gut C ist jetzt eher 
im Embedded Bereich zu finden und in der Kernelentwicklung, aber die 
meisten kommerziellen Programme sind in C/C++ geschrieben. C# und Java 
haben zwar auch ganz schön aufgeholt, fixieren sich allerdings eher im 
Anwendungsbereich.

Selbst wenn eine neue ultimative Sprache erfunden werden sollte, die 
jeden glücklich machen würde, bräuchte sie ziemlich lang sich zu 
etablieren. Man kann ja schließlich nicht alle Projekte schnell 
neuentwickeln. Und das ist das Dilemma. Neh wir nehmen lieber wieder 
C++, damit haben wir schon immer entwickelt.

Vielleicht irre ich mich ja auch.

von Christopher C. (Gast)


Lesenswert?

Guido B. schrieb:
> Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern
> verstanden hast? Das Objekt wird mit create auf dem Heap angelegt,
> ist damit quasi global. Es darf dementsprechend nicht einfach
> destroyed werden, wenn eine Prozedur beendet wird. Stell es dir
> als einfache Pointerliste vor, die durch so eine Automatik brechen
> würde.

Ja, dass Instanzen von Klassen auf den Heap kommen, habe ich erst danach 
erfahren. Die Frage ist dann halt, warum ist die Variable global? Sie 
gehört doch in den Scope der Prozedur. Es gibt doch schon einen globalen 
Scope.

Das hast du auch richtig erfasst, das ist das erste mal, dass ich mich 
näher mit Pascal bzw. ObjPascal auseinandersetze. Wahrscheinlich denke 
ich zu sehr in C++.

Ich habs auch mit Objekten versucht, genau das gleiche, und das obwohl 
Objekte auf den Stack kommen. Oder verstehe ich da was falsch?

von (prx) A. K. (prx)


Lesenswert?

Christopher C. schrieb:
> Ja, dass Instanzen von Klassen auf den Heap kommen, habe ich erst danach
> erfahren. Die Frage ist dann halt, warum ist die Variable global?

Ist sie nicht. Die Variable ist lokal, ist aber offenbar implizit ein 
Pointer auf ein Klassenobjekt. Der dann, wenn das Objekt wie oben 
angelegt wurde, in den Heap zeigt. Dieses System hat sich wohl 
entschieden, ebenso wie viele anderen OOP Sprachen, Klassenobjekte 
grundsätzlich nicht direkt auf den Stack zu legen.

Ihren vollen Sinn entwickelt eine solche Strategie allerdings erst in 
Verbindung mit Garbage Collection.

Guidos Bezeichnung als "quasi global" ist ziemlich problematisch. Der 
Heap ist vom Scope her weder lokal noch global, sondern genau das was 
man im Einzelfall daraus macht.

von Guido B. (guido-b)


Lesenswert?

A. K. schrieb:
> Guidos Bezeichnung als "quasi global" ist ziemlich problematisch.

Ja, der Heap schwebt irgendwie über den Kontexten. Trotzdem müssen
die Pointerelemente als global angenommen werden, sonst könnte
man nicht von überall im Programm darauf zugreifen (auch wenn sie
jenseits des Horizontes liegen).

von Tombo (Gast)


Lesenswert?

auch wenn es wieder einen Sturm der Entrüstung verursacht :-)
Wollte hier mal ein größeres Pascal Projekt zeigen.
Ich selber vertrete nach wir vor die Meinung das die Programmiersprache 
eigentlich egal ist, aber Pascal durch die strenge Typprüfung einfach 
zuverlässiger ist
http://www.free-erp.de/

Auch wenn der Threat schon älter ist, aber da ich selber viel in Pascal 
mache will ich natürlich die Sprache am Leben halten.
Und dank Lazarus ist es einfach unglaublich portabel von Win zu Linux 
oder MacOS etc

von Andreas H. (ahz)


Lesenswert?

Tombo schrieb:
> auch wenn es wieder einen Sturm der Entrüstung verursacht :-)
> Wollte hier mal ein größeres Pascal Projekt zeigen.

So leid wie es mir tut aber was ich auf der WebSite gesehen habe... Hut 
ab^^

Für sowas gibts keine Haue ;-)

Schönes WE noch

Andreas

P.S: Die Icons im Program sind ja knuffig. Sind die Standardmäßig bei 
Lazarus dabei ?
A.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

@ Tombo

Als alter Delphi/Pascal Hobby-Programmierer nann ich ebenfalls nur 
sagen:
Hochachtung vor Deinem free-erp Projekt!

Gruss Ulrich Albert

von Tombo (Gast)


Lesenswert?

kleines Mißverständnis, ist nicht meins ;-)

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Auch wenn das Projekt schön und gut sein mag, mit ein paar 
Begrifflichkeiten solltest doch vorsichtiger umgehen. ERP ist ein weites 
Feld, unter EDM und PDM verstehen manche etwas anderes (Engineering Data 
Mangement, Product Data Magement)

von Georg (Gast)


Lesenswert?

Albert M. schrieb:
> Als alter Delphi/Pascal Hobby-Programmierer

Da ich schon mit Heimsoeth Turbo Pascal gearbeitet habe, tut mir der 
Niedergang auch sehr leid. An der Sprache liegt das aber weniger, 
sondern am Verhalten der Anbieter, es gibt ja nur einen kommerziellen, 
und der versucht seine Altkunden loszuwerden, um wieder voll abkassieren 
zu können, so dass ich trotz mehr als 30 Jahren Kundentreue jetzt alles 
neu bezahlen müsste. Daher verwende ich Delphi7 privat noch solange wie 
man damit unter Windows noch was zum Laufen kriegt (geht noch ganz gut, 
Kacheln mag ich eh nicht), aber professionell würde ich wegen der nicht 
gegebenen Investitionssicherheit kein Pascal mehr verwenden, nicht für 
ein neues Projekt. Bei C++ kann man immer auf einen anderen Compiler 
ausweichen.

Was Pascal immer gefehlt hat, ist die Konkurrenz durch einen 
ernstzunehmenden 2. Anbieter. PCs haben sich auch nur so schnell 
weiterentwickelt, weil es eben nicht nur IBM gab.

Georg

von Bernd K. (prof7bit)


Lesenswert?

Georg schrieb:
> nicht gegebenen Investitionssicherheit kein Pascal mehr verwenden, nicht
> für ein neues Projekt.
>
> Was Pascal immer gefehlt hat, ist die Konkurrenz durch einen
> ernstzunehmenden 2. Anbieter.

Warst Du die letzten 10 Jahre auf interplanetarer Kreuzfahrt jenseits 
des Asteroidengürtels oder wie kommts dass Du als einziger noch nichts 
von Lazarus und fpc gehört hast?

Oder sollte das ein Trollposting oder ein verkappter flamebait werden?

von Georg (Gast)


Lesenswert?

Bernd K. schrieb:
> dass Du als einziger noch nichts
> von Lazarus und fpc gehört hast?

Das sind eher Absichtserklärungen als fertige Software. Und ich habe 
schon zu viele Free-Projekte sang- und klanglos untergehen sehen um 
darauf längerfristig zu bauen. Da heisst es dann "der XY der das bisher 
gemacht hat, kann aus beruflichen Gründen nicht mehr" und dann kommen 
Weiterentwicklung und Fehlerbeseitigung zum Erliegen und ein paar Jahre 
später gibt es nur noch ein paar Unentwegte, die mit den alten Versionen 
herumspielen. Beispiel CVS, und XFree86 scheint auch ins IT-Nirwana 
einzugehen, und das sind grundlegende Programme.

Ein Begriff wie Investitionsicherheit ist für dich wohl aus einer 
anderen Welt, für einen Bastler sieht das natürlich alles anders aus. 
Privat kann ich ja selbst Lazarus mal testen, wenn Delphi7 nicht mehr 
verwendbar ist und wenn es Lazarus bis dahin noch gibt.

Georg

von Max M. (jens2001)


Lesenswert?

Georg schrieb:
> Da ich schon mit Heimsoeth Turbo Pascal gearbeitet habe, tut mir der
> Niedergang auch sehr leid.

Geht mir genauso!

von Bernd K. (prof7bit)


Lesenswert?

Georg schrieb:
> Ein Begriff wie Investitionsicherheit ist für dich wohl aus einer
> anderen Welt,

Nein, FPC und Lazarus sind Investitionssichertheit, mehr als es eine 
Firma Borland oder irgendeine andere längst untergegangene 3-Mann 
Klitsche je hätte sein können, denn diese Projekte stehen unter der 
(L)GPL und haben ein ein großes breit aufgestelltes internationales 
Entwicklerteam, sind sehr lebendig und werden noch aktiv sein wenn Du 
schon längst in Rente bist.

Im übrigen sind sie schon seit Jahren aus dem Stadium 
"Absichtserklärung" heraus und stellen eine voll nutzbare und aktiv 
gepflegte Toolchain zur Verfügung und der Support der großen (und stetig 
weiter wachsenden) Community ist Exzellent.

Du solltest nach all den Jahren der Ignoranz vielleicht mal wieder wagen 
einen Blick drauf zu werfen, dann würdest Du hier nicht so einen 
haarsträubenden Blödsinn verbreiten über den Zustand von Projekten die 
Du überhaupt nicht kennst.

von Tom (Gast)


Angehängte Dateien:

Lesenswert?

Bin gerade durch zufall auf noch ein kommerzielles Delphi Produkt 
gestoßen :-)
Leidwer aufgrund einer Fehlermeldung :-(
Ist ein Lernprogram mit Spracherkennung..soviel zu Pascal wird im 
Kommerziellen Feld heute nicht mehr eingesetzt ;-)

http://www.amazon.de/digital-publishing-Business-Intensivkurs-Download/dp/B00H2YHIBQ/ref=sr_1_1?ie=UTF8&qid=1423953378&sr=8-1&keywords=Business+Intensivkurs+English+%28Download%29

von Tom (Gast)


Lesenswert?

ach ja, und es war kein Pufferüberlauf :-)
Ich vermute es wird ein Windows 7 Problem sein, auf XP gibt es die 
Meldung nicht..mit Lazarus wäre das wohl nicht passiert ;-)

von Tom (Gast)


Lesenswert?

Hier eine Umfangreiche Lsite von Pascal Programmen :-)
Neben Nero Burning Rom, Skype, WinRAR, PArtition MAgic sind eine Menge 
weitere sehr guter und bekannter Programme dabei
https://jonlennartaasenden.wordpress.com/2014/11/06/famous-software-made-with-delphi/

von Salewski, Stefan (Gast)


Lesenswert?

Tom schrieb:
> Hier eine Umfangreiche Lsite von Pascal Programmen :-)

Nun ja, man kann auch mit einem VW Käfer eine schöne Weltreise machen...

Aber aus dem Käfer kann man den Wackeldackel, die gehäkelte 
Klorollenhaube oder die Blumenvase leicht herausnehmen. Mit dem 'begin' 
Schlüsselwort habes sie es wohl in den 40 Jahren nicht geschafft.

Aber im Ernst -- heute gibt es viele weit schönere und interessantere 
Sprachen als Pascal. Die Portabilität bleibt allerdings ein Argument.

von Tom (Gast)


Lesenswert?

Ohne es mir angesehen zu haben, meisnt zu C#?
Mittlerweile gibt es sogar Pascal für Android converter :-)
Ob man damit brauchbar auf spezielle Funktionen zugreifen kann..k.A. 
aber alleine was die Jungens da alles auf die beine stellen ist einfach 
super.
Das es für ARM Controller auch mit Freepascal bereits in Ansätzen geht 
ist auch cool
http://www.blaisepascal.eu/blaisepascal_37_38/BPM37_38Preview/index.html#14

von Paul B. (paul_baumann)


Lesenswert?

Salewski, Stefan schrieb:
> Aber im Ernst -- heute gibt es viele weit schönere und interessantere
> Sprachen als Pascal.

Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener
und die Quelltexte immer schwerer verständlich. Vielleicht ist das
Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein
Programm umsetzen kann.

Das mußte ich mal sagen.

MfG Paul

von TriHexagon (Gast)


Lesenswert?

Paul Baumann schrieb:
> Salewski, Stefan schrieb:
>> Aber im Ernst -- heute gibt es viele weit schönere und interessantere
>> Sprachen als Pascal.
>
> Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener
> und die Quelltexte immer schwerer verständlich. Vielleicht ist das
> Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein
> Programm umsetzen kann.
>
> Das mußte ich mal sagen.
>
> MfG Paul

C++ ist aber immer noch der König der verworrenen Programmiersprachen, 
wenn man sich die ein oder andere Template-Orgie anschaut.

Die neuen Sprachen sind manchmal auf den ersten Blick etwas kryptisch, 
was aber eher daran liegt, dass diese völlig neue Sprachkonzepte 
aufgreifen und ältere nicht übernehmen. Sieht man sehr gut an Go oder 
Rust. Meistens sind deren Sprachkerne auch sehr minimalistisch und 
überschaubar. Also das was man allgemein an C schätzt.

von Tom (Gast)


Lesenswert?

Hier ein Sehr cool umgesetztes Spiel in PAscal
https://www.youtube.com/watch?v=tox2nYljVfg

von Kim S. (Gast)


Lesenswert?

hier gibts noch mehr davon :-)
http://www.delphigamer.com/main.php

von Bernd K. (prof7bit)


Lesenswert?

Salewski, Stefan schrieb:
> Aber im Ernst -- heute gibt es viele weit schönere und interessantere
> Sprachen als Pascal. Die Portabilität bleibt allerdings ein Argument.

An die industrielle Praxistauglichkeit, Vielseitigkeit und 
unkomplizierte Verwendbarkeit von so mächtigen und ausgereiften 
Komplettpaketen wie Lazarus/FPC oder Delphi müssen deine "interessanten 
Sprachen" erst mal rankommen, und zwar wesentlich näher als die üblichen 
250km Distanz zwischen Theorie und Praxis, ansonsten bleiben es nur 
schöne Elfenbeintürme am fernen Horizont die in der Abendsonne glänzen.

von dicker, länger, härter (Gast)


Lesenswert?

Ganz schön abgedriftet, das Thema ist: C oder Pascal.

C ist nicht C++ und Pascal ist nicht Delphi.

C != C++;     Pascal <> Delphi;

von Bernd K. (prof7bit)


Lesenswert?

dicker, länger, härter schrieb:
> Pascal ist nicht Delphi.

Pascal ist die in Delphi verwendete Sprache, die selbe Sprache wie auch 
bei FPC.

Und wenn Du jetzt kommst mit "Pascal so wie man es heute verwendet 
(Delphi oder FPC) ist nicht mehr das selbe Ur-Pascal aus Großvater 
Wirths Zeiten" dann sage ich das selbe kann man auch für C oder C++ 
sagen.

von Kim S. (Gast)


Lesenswert?

so schauts nämlich aus :-)
Viele der C Programmierer haben seit JAhren nicht den Blick zur Seite 
gewagt, es hat sich über all die Jahre einiges! getan.
Schon Turbo Pascal hat mit dem was hier oft als Beispiele gegen Pascal 
gebracht wird, so überhaupt nichts mehr zu tun, bzw treffen die 
Argumente schon seit über 20 jahren nicht mehr zu!
Turbo PAscal 6 bzw 7 war schon nicht umsonst damals sehr!! erfolgreich, 
der einzgie Grund das es vermasselt wurde, war damals die 
Weiterentwicklung für Windows, Turbo Pascal für Windows war einfach nur 
furchtbar da kamen dann C und Basic und übernahmen den MArkt.
Heute hat FPC bzw Delphi aufgeholt, aber leider unbemerkt vom Mainstream

von dicker, länger, härter (Gast)


Lesenswert?

Dann ist nach deiner Meinung C die in C++ verwendete Sprache.

Merkst du wie du daneben liegst?

von Kim S. (Gast)


Lesenswert?

nein, ist es nicht, schau Dir mal Lazarus bzw FPC an....bis auf das 
Visual, kann FPC alles was die Visuel Version dafür auch kann

von dicker, länger, härter (Gast)


Lesenswert?

@Kim
Mit Windows wurde auf Objekte umgestellt. Es wurde nicht mehr in C, 
sondern C++ entwickelt. Bei Pascal nannte man es Objekt Pascal. Man darf 
es nicht gleich setzen.

Im Vergleich von C und Pascal gibt es kaum Unterschiede. Das haben wir 
hier schon öfter diskutiert.

von Kim S. (Gast)


Lesenswert?

aber vieles was in c++ geht bzw. dort gibt, kennt doch C nicht-oder?

von Salewski, Stefan (Gast)


Lesenswert?

Paul Baumann schrieb:
> Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener
> und die Quelltexte immer schwerer verständlich. Vielleicht ist das
> Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein
> Programm umsetzen kann.
>
> Das mußte ich mal sagen.

Nun ja, bei C++ habe ich das auch manchmal gedacht...

Bei Python und Ruby ist das aber sicher nicht der Fall, und Go soll ja 
auch sehr weit in Richtung "Einfachheit" gehen. Julia ist durch seine 
Anlehnung an Matlab ja von der Syntax auch recht einfach.

Aber die Forschung hat in den letzten zwei Jahrzehnten auch viele neue 
Konzepte entwickelt, von denen vieles dann eben in Sprachen wie Haskell, 
Rust und Nim einfließt. Und man muss ja nicht gleich alles verstehen.

von dicker, länger, härter (Gast)


Lesenswert?

Viele, was in Delphi oder Lazarus geht oder dort gibt, kennt Pascal doch 
nicht, oder?

von Kim S. (Gast)


Lesenswert?

doch eben doch, das meinte ich ja.
Sonst wäre Dephi ja was anders..
LAzarus ist ja eigentlich nur eine grafische Oberfläche zum Arbeiten für 
Freepascal.
Freepascal steckt aber immer drunter...

von Bernd K. (prof7bit)


Lesenswert?

dicker, länger, härter schrieb:
> ann ist nach deiner Meinung C die in C++ verwendete Sprache.

Nein, dieser Satz ergibt auch keinen Sinn. Beides sind entfernt 
verwandte Programmiersprachen, die neuere wurde von der älteren 
inspiriert, überlebt haben beide und werden beide unabhängig voneinander 
bis heute noch häufig verwendet, die Programmierparadigmen sind sehr 
unterschiedlich.

Delphi ist ein Stück Software. Und darin wird unter anderem auch eine 
Programmiersprache verwendet und die nennt sich "Object Pascal" und das 
ist der heute gängige und evolutionär aus der Pascal-Ur-Suppe 
hervorgegangene Hauptzweig (der dickste Ast mit Abstand und auch 
weitgehend senkrecht) der Pascal Ahnenreihe, ich würde sagen der 
legitime Träger des Namens "Pascal" und unangefochtene Thronerbe

Es gibt keine Pascal und Pascal++ die parallel von einander entwickelt 
und überlebt haben es gibt nur einen senkrecht gewachsenen Hauptstamm 
(Delphi und FPC verwenden ihn) mit viel Grün, gesund und tragfähig, und 
noch ein bisschen dünnes vertrocknetes Seitengeäst viel weiter unten, 
jedoch angesichts des kräftigen Hauptstammes kaum noch der Rede wert.

von dicker, länger, härter (Gast)


Lesenswert?

Kim Schmidt schrieb:
> doch eben doch, das meinte ich ja.

Also kennst du Pascal überhaupt nicht und sprichst wie der Blinde von 
der Farbe. :-(

Dann Vergleich weiter Äpfel mit Kürbissen. :-(

von dicker, länger, härter (Gast)


Lesenswert?

Bernd K. schrieb:
> dicker, länger, härter schrieb:
> ann ist nach deiner Meinung C die in C++ verwendete Sprache.
>
> Nein, dieser Satz ergibt auch keinen Sinn. Beides sind entfernt
> verwandte Programmiersprachen, die neuere wurde von der älteren
> inspiriert, überlebt haben beide und werden beide unabhängig voneinander
> bis heute noch häufig verwendet, die Programmierparadigmen sind sehr
> unterschiedlich.
>
> Delphi ist ein Stück Software. Und darin wird unter anderem auch eine
> Programmiersprache verwendet und die nennt sich "Object Pascal" und das
> ist der heute gängige und evolutionär aus der Pascal-Ur-Suppe
> hervorgegangene Hauptzweig (der dickste Ast mit Abstand und auch
> weitgehend senkrecht) der Pascal Ahnenreihe, ich würde sagen der
> legitime Träger des Namens "Pascal" und unangefochtene Thronerbe
>
> Es gibt keine Pascal und Pascal++ die parallel von einander entwickelt
> und überlebt haben es gibt nur einen senkrecht gewachsenen Hauptstamm
> (Delphi und FPC verwenden ihn) mit viel Grün, gesund und tragfähig, und
> noch ein bisschen dünnes vertrocknetes Seitengeäst viel weiter unten,
> jedoch angesichts des kräftigen Hauptstammes kaum noch der Rede wert.

Was für ein Schwachsinn!

Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C. 
Grundlegende Syntaxelemnte sind identisch, aber die objektorientierten 
Sprachen haben erhebliche Erweiterungen, die mit der strukturierten 
Sprache nicht gemeinsam sind.

Ein C++ Compiler frisst problemlos C Code, oder? (Den richtigen Einsatz 
von Datentypen setze ich voraus: wg. Typeprüfung)

von Stefan R. (srand)


Lesenswert?

dicker, länger, härter schrieb:
> Ein C++ Compiler frisst problemlos C Code, oder?

Nein. Nicht jeden.

von Kim S. (Gast)


Lesenswert?

siehst Du völlig falsch.
Du könntest eins zu eins Code aus Delphi ins DOS Freepascal 
kopieren..hättest lediglich Probleme mit den fehlenden Units wir Forms, 
FileUtils etc alles was halt für die graphische Oberfläche ist!
Genau deshalb denke ich, wenn viele wüßten, wie genial PAscal eigentlich 
aufgebaut ist und über all die Jahre gewachsen ist, würden es auch viel 
mehr benutzen!

Eine Sprache wurde entwickelt und bis heute erweitert und verbesser  so 
wie es eigentlich sein sollte, anstatt jedesmal das Rad neu zu erfinden, 
wenn es gar nicht erforderlich ist.

ICh denke auch, das einfach zu wenig Öffentlichkeitsarbeit seitens der 
Pascal Community stattfindet, das ist ein großer Fehler

von TriHexagon (Gast)


Lesenswert?

dicker, länger, härter schrieb:
> Ein C++ Compiler frisst problemlos C Code, oder? (Den richtigen Einsatz
> von Datentypen setze ich voraus: wg. Typeprüfung)
1
int* ptr = (int*)malloc(sizeof(int));

Wenn man das sieht, weiß man bescheid ;)

von Kim S. (Gast)


Lesenswert?

gleich als erstes auf der Lazarus Seite steht auch...
"Lazarus is a Delphi compatible !!! cross-platform IDE for Free 
Pascal.!!!  It includes LCL which is more or less compatible with 
Delphi's VCL. Free Pascal is a GPL'ed compiler that runs on Linux, 
Win32, OS/2, 68K and more. Free Pascal is designed to be able to 
understand and compile Delphi syntax, which is OOP. Lazarus is the part 
of the missing puzzle that will allow you to develop Delphi like 
programs in all of the above platforms. Unlike Java which strives to be 
a write once run anywhere, Lazarus and Free Pascal strives for write 
once compile anywhere. Since the exact same compiler is available on all 
of the above platforms it means you don't need to do any recoding to 
produce identical products for different platforms."

von Yalu X. (yalu) (Moderator)


Lesenswert?

Vielleicht mal kurz zur Namensentwirrung:

Die in diesem Zusammenhang relevanten Programmiersprachen heißen C, C++,
Pascal und Object Pascal.

C++ und Object Pascal sind die weitgehend abwärtskompatiblen
objektorientierten Erweiterungen von C bzw. Pascal. C und Pascal haben
keine spezifische Unterstützung für objektorientierte Programmierung.

Es gibt ein offizielles C (ISO/IEC 9899:2011), ein offizielles C++
(ISO/IEC 14882:2014), ein offizielles Pascal (ISO/IEC 7185:1990), aber
mehrere Object-Pascal-Dialekte¹.

Delphi und Lazarus sind Entwicklungsumgebungen für Object Pascal.

Delphi wird manchmal (nicht ganz korrekterweise) auch als Bezeichnung
für den in dieser Entwicklungsumgebungen verwendeten Object-Pascal-
Dialekt verwendet.

Free Pascal ist ein Compiler für Object Pascal, der in Lazarus verwendet
wird.

———————————
¹) In der 90er Jahren gab es einen Vorstoß, auch Object Pascal zu
   standardisieren, der allerdings allerdings auf Grund mangelnden
   Interesses und des Fehlens einer Referenzimplementation scheiterte.

: Bearbeitet durch Moderator
von Bernd K. (prof7bit)


Lesenswert?

dicker, länger, härter schrieb:
> Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C.

Delphi und Lazarus verwenden Pascal. Das moderne Pascal, die langsam und 
geradlinig gewachsene Weiterentwicklung der selben Sprache. Irgendwann 
zu Borlands Zeiten noch und da war es schon die dominante Variante hat 
man es dann auch als "Object Pascal" bezeichnet um der über die Zeit 
gewachsenenen Mächtigkeit auch im Namen gerecht zu werden.

Das alte Ur-Pascal das Du ständig aus dem Grab hervorholen und 
klrampfhaft mit C assoziieren willst nur damit Du ein Pascal-Äquivalent 
für diese unsägliche C/C++-Dualität herbeireden kannst existiert nicht. 
Diese Dualität existiert nicht! Niemand verwendet außerhalb des Museums 
noch die alte Ur-Version, das heutige industrielle Pascal ist das von 
Delphi oder FPC.

: Bearbeitet durch User
von Kim S. (Gast)


Lesenswert?

wie gesagt, ich denke wenn das mehr bekannt wäre, würde Pascal /Lazarus 
wieder erheblich erfolgreicher sein...
Ein Marketingproblem :-(

von dicker, länger, härter (Gast)


Lesenswert?

Kim Schmidt schrieb:
> gleich als erstes auf der Lazarus Seite steht auch...
> "Lazarus is a Delphi compatible !!! cross-platform IDE for Free
> Pascal.!!!  It includes LCL which is more or less compatible with
> Delphi's VCL. Free Pascal is a GPL'ed compiler that runs on Linux,
> Win32, OS/2, 68K and more. Free Pascal is designed to be able to
> understand and compile Delphi syntax, which is OOP. Lazarus is the part
> of the missing puzzle that will allow you to develop Delphi like
> programs in all of the above platforms. Unlike Java which strives to be
> a write once run anywhere, Lazarus and Free Pascal strives for write
> once compile anywhere. Since the exact same compiler is available on all
> of the above platforms it means you don't need to do any recoding to
> produce identical products for different platforms."

Lazarus und Delphi bauen auf Pascalsyntax auf, haben aber wesentliche 
Erweiterungen!!!
http://www.moorecad.com/standardpascal/standards.html

Wenn du den Blödsinn immer wiederholt, muss ich daraus ableiten, dass 
für dich C++ und C auch das Gleiche sind! :'(

von dicker, länger, härter (Gast)


Lesenswert?

Bernd K. schrieb:
> dicker, länger, härter schrieb:
> Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C.
>
> Delphi und Lazarus verwenden Pascal. Das moderne Pascal, die langsam und
> geradlinig gewachsene Weiterentwicklung der selben Sprache. Irgendwann
> zu Borlands Zeiten noch und da war es schon die dominante Variante hat
> man es dann auch als "Object Pascal" bezeichnet um der über die Zeit
> gewachsenenen Mächtigkeit auch im Namen gerecht zu werden.
>
> Das alte Ur-Pascal das Du ständig aus dem Grab hervorholen und
> klrampfhaft mit C assoziieren willst nur damit Du ein Pascal-Äquivalent
> für diese unsägliche C/C++-Dualität herbeireden kannst existiert nicht.
> Diese Dualität existiert nicht! Niemand verwendet außerhalb des Museums
> noch die alte Ur-Version, das heutige industrielle Pascal ist das von
> Delphi oder FPC.

Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P

In diesem Thread gind es um Pascal oder C für uC. Da gibt es z. Bsp. was 
von Mikro...Elekt... . Das dürfte mit Delphi ganz wenig zu tun haben. 
;-)

: Wiederhergestellt durch Moderator
von Kim S. (Gast)


Lesenswert?

nein, Freepascal die aktuelle version hat erweiterungen zur 
vorgängerversion..das ist richtig, und nichts anderes wir hier ide ganze 
Zeit gesagt
aber z.b den Cardinal Typ kannst Du unter Dos genauso wie unter Windows 
nutzen.
Den gab es in der Turbo PAscal 7 Version noch nicht z.B:

von Kim S. (Gast)


Lesenswert?

@ dickerlängerhärter

Also bisslang bezogen sich die letzten Posts auf Delphi udn Free Pascal 
offenbar hast Du da was verpasst ;-)

von Kim S. (Gast)


Lesenswert?

das was Du jetzt anführst mit µc und Mikroe.com  stimmt.
Liegt aber auch daran das es nicht um einen Standard geht.
Auch das wurde bereits erwähnt das die Standatisierungsbemühungen damals 
nicht fruchteten

von Bernd K. (prof7bit)


Lesenswert?

dicker, länger, härter schrieb:
> Wenn du den Blödsinn immer wiederholt, muss ich daraus ableiten, dass
> für dich C++ und C auch das Gleiche sind! :'(

Nein. Aber C und C++ werden heute beide noch verwendet, also muss man 
sie unterscheiden und braucht verschiedene Namen dafür.

Bei Pascal wird heute nur noch die aus der Borland-Linie hervorgegangene 
Variante verwendet, die von Delphi und FPC implementiert werden, alle 
anderen älteren Dialekte sind ausgestorben oder liegen im Sterben. 
Außerden hat es nie so einen scharfen Cut und Rewrite und 
Paradigmenwechsel und grundlegende Änderungen der Grammatik wie zwischen 
C und C++ gegeben, die Erweiterungen sind eher langsam und natürlich 
reingewachsen und fügen sich ein als wären sie von Anfang an so geplant 
gewesen. Das ist der Unterschied.

: Bearbeitet durch User
von ?!? (Gast)


Lesenswert?

dicker, länger, härter schrieb:
> Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P
>
> In diesem Thread gind es um Pascal oder C für uC. Da gibt es z. Bsp. was
> von Mikro...Elekt... . Das dürfte mit Delphi ganz wenig zu tun haben.
> ;-)

Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die 
ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu 
tun hat?
So viel zum Thema "begrenzter Horizont" :-)

von Kim S. (Gast)


Lesenswert?

hmm..schade aber irgendwie kannst Du nicht diskutieren..daher ziehe ich 
mir hier raus bis gleichwertige Gesprächspartner sich beteiligen.

Und ja, da siehst Du mal wir cool FPC ist, das geht tatsächlich!
Allerdings ist das meines wissen s noch sehr eingeschränkt kann aber 
auch an fehlenden units liegen.
Derzeit nutzt man für µc überwiegen mikroe oder elab..
aber wie gesagt, diese Art der Konversation ist mir zu blöd, lerne dich 
entsprechend zu artikulieren oder geh auf Deine C Spielwiese und finde 
Programmfehler ;-) oder die Tippfehler in meinen Texten wenn es Dir Spaß 
macht :-)

von dicker, länger, härter (Gast)


Lesenswert?

Bernd K. schrieb:
> Bei Pascal wird heute nur noch die aus der Borland-Linie hervorgegangene
> Variante verwendet

darum

dicker, länger, härter schrieb:
> Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P

Yalu hat freundlicherweise ein wenig aufgeräumt

Yalu X. schrieb:
> Die in diesem Zusammenhang relevanten Programmiersprachen heißen C, C++,
> Pascal und Object Pascal.
>
> C++ und Object Pascal sind die weitgehend abwärtskompatiblen
> objektorientierten Erweiterungen von C bzw. Pascal. C und Pascal haben
> keine spezifische Unterstützung für objektorientierte Programmierung.
>
> Es gibt ein offizielles C (ISO/IEC 9899:2011), ein offizielles C++
> (ISO/IEC 14882:2014), ein offizielles Pascal (ISO/IEC 7185:1990), aber
> mehrere Object-Pascal-Dialekte¹.

Un der entscheidende Satz:

Yalu X. schrieb:
> Delphi und Lazarus sind Entwicklungsumgebungen für Object Pascal.

@Kim und Bernd
Ihr vergleicht C mit Objekt Pascal und das ist wie Äpfel und Kürbisse!

Und um noch einaml auf den Eingangspost zu kommen, es geht um:
http://www.mikroe.com/mikropascal/arm/
Ob der Delphi-Programme übersetzt? ;-)

von dicker, länger, härter (Gast)


Lesenswert?

?!? schrieb:
> Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die
> ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu
> tun hat?

Und Java läuft auch auf einem Cortex. Oh man .... :-(((

von Bernd K. (prof7bit)


Angehängte Dateien:

Lesenswert?

Oder ums mal anders auszudrücken:

Wenn ich sage "ich nehm dem Wagen, das geht schneller als zu Fuß" dann 
muss natürlich in einer Welt in in der C und C++ bis zum heutigen Tage 
beide überlebt haben korrekterweise dazu sagen dass ich den Kraftwagen 
meine und nicht den Pferdewagen.

Wenn wir jedoch im Jahre 2015 von Pascal sprechen dann wird doch aus dem 
Zusammenhang schon klar daß ich mit mit dem Antigrav-Landspeeder in die 
Stadt fahren will und nicht mit dem Pferdewagen, das muss man doch nicht 
extra dazuschreiben, oder?

von ?!? (Gast)


Lesenswert?

dicker, länger, härter schrieb:
> ?!? schrieb:
>> Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die
>> ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu
>> tun hat?
>
> Und Java läuft auch auf einem Cortex. Oh man .... :-(((

Vielleicht hast du es nicht verstanden. Man kann unter Lazarus direkt 
native Software für die gesamte ARM-Familie compilieren. Ich spreche 
hier nicht von einem Cortex, auf dem Linux läuft, unter Linux dann Java 
und auf dem Java kann man dann Programme laufen lassen. Ich spreche von 
direkt ausführbaren Programmen nativ auf dem ARM.

von npn (Gast)


Lesenswert?

dicker, länger, härter schrieb:
> ?!? schrieb:
>> Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die
>> ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu
>> tun hat?
>
> Und Java läuft auch auf einem Cortex. Oh man .... :-(((

Toll. Ein C-Programm, welches auf einem Cortex läuft. Wer hätte das 
gedacht. Und ich dachte, hier geht es um Pascal/Delphi/Lazarus für einen 
µC (bsp Cortex)

von Crazy Harry (crazy_h)


Lesenswert?

Ich progge uCs (Mega/XMega) in Pascal :o)

Und ich habe keinen Bock mit knapp 50 Jahren noch C zu lernen. Pascal 
war in meiner Ausbildung ein Steckenpferd unseres Ausbilders und deshalb 
hatten wir eine ausführliche Pascal-Einführung. Ich hab dann, da mit die 
Sprache gefällt, privat damit weiter gemacht. Seit aber Pascal dann 
richtung Windows ging war es mir zu blöd ..... zumal ich sehr lange mit 
OS/2 gearbeitet habe (Dual-Boot DOS - OS/2).

von dicker, länger, härter (Gast)


Lesenswert?

Crazy H. schrieb:
> Ich progge uCs (Mega/XMega) in Pascal

Wecher Compiler?

von Crazy Harry (crazy_h)


Lesenswert?

dicker, länger, härter schrieb:
> Crazy H. schrieb:
> Ich progge uCs (Mega/XMega) in Pascal
>
> Wecher Compiler?

AVRCo

von Nase (Gast)


Lesenswert?

Crazy H. schrieb:
> dicker, länger, härter schrieb:
>> Crazy H. schrieb:
>> Ich progge uCs (Mega/XMega) in Pascal
>>
>> Wecher Compiler?
>
> AVRCo

Och Gott, du Armer Kerl.

AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch 
mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es 
seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von 
"Title of this help project" umzubenennen...

Sorry, ich habe jetzt lange genug mit AVRCo und MikroPascal arbeiten 
müssen. Die Codequalität, die diese Compiler hervorbringen, ist 
lächerlich: Das Assembly besteht praktisch aus unoptimierte Primitiven.

Ich habe zuletzt ein Projekt in C umgesetzt, welches mit GCC und MikroC 
(dürfte ja dasselbe Backend wie MikroPascal sein) übersetzt wurde. Und 
selbst mit strammster Optimierung brauchte MikroC etwa drei bis viermal 
soviel Flash...

(1) http://www.e-lab.de/AVRco/DOC_de/DocuReference.pdf

von Crazy Harry (crazy_h)


Lesenswert?

Nase schrieb:
> AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch
> mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es
> seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von
> "Title of this help project" umzubenennen...
Ich merke schon: keine Ahnung

von Tom (Gast)


Lesenswert?

ich war damals von AVRco weg, nachdem mich der Coadmin aus dem Forum 
geworden hatte, mit den Worten "Du nervst" weil ich zu viele 
Anfängerfragen gestellt hatte.
Mittlerweile vertreibe ich kommerzielle Produkte mit Mirkoe und hätte 
die große AVRco erworben, aber AVRCo hatte bei mir nach dieser Aktion 
verschissen.
Ich hatte mich dazu damals beim Rolf beschwert, ohne jegliche Reaktion.
Wenn die glauebn ohne die Einsteiger und Anfänger auszukommen, dann 
bitte, sollen die mal alle schön zu Mirkoe rüber, darf Rolf nur nicht 
maulen nachher!

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Mich würde tatsächlich mal der Vergleich AVRCo/Mirkoe zu LunaAVR 
interessieren. Habt ihr das mal tatsächlich in Erwägung gezogen und 
probiert?

von Tom (Gast)


Lesenswert?

LunaAVR hatte ich mal ausprobiert.
War damlas noch eine sehr junge Version und war damals schon sehr gut!
Einzi,g das kein ARM geplant ist hat mich zu Mikroe getrieben.
Der Support von LunaAvr ist ebenfalls Klasse.
Fehler melden und meist  weniger Tage oder am selben Abend behoben!!
Aber LunaAVR ist ja kein richtiges Pascal, eher eine Symbiose aus Basic, 
PAscal und C was aber keinesfalls schlecht ist!
Auf meine Intention hin, wurde die Xmega Untetrstützung damals 
vorgezogen

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Vielen Dank für die Rückmeldung!
Ich hatte vor geraumer Zeit Mikroe ausprobiert und bin Aufgrund der 
damaligen sehr frühen Version bei AVRCo gelandet. Im Prinzip recht 
ordentlich, doch einfach zu teuer für gelegentliche Projekte als 
Hobbyanwender. Jedes Jahr 25%, ich weiß nicht…
Nun schwanke ich, zurück und nochmals Mikroe oder LunaAVR.

von Tom (Gast)


Lesenswert?

das ist der Punkt, laut Rolf muss es das Hobby ja wert sein 'röfl'
Also zu meinen reinen Hobbyzeiten wäre es mir das nicht!! wert gewesen, 
und jetzt Beruflich schon, aber da AVRco nicht sonderlich begeistert von 
Anfängern ist, müssen sie halt mit den Stammkungen überleben die sie 
noch haben, großartig neue dazukommen werden bei dem Geschäftsmodell 
wohl keine emhr und wenn Rolf mal gesundheitlich Probleme haben 
sollte...dann passiert da gar nichts mehr.
Wie gesagt eigentlich schade, hatte mit AVRco angefangen und fand das 
damals eigentlich nicht schlecht

von Pandur S. (jetztnicht)


Lesenswert?

Ich verwende seit Jahren schon AVRCo Pascal, und bin eigentlich recht 
zufrieden damit. Anfaenglich hatte ich die Profiversion, bis ich dann 
merkte, dass die Standard auch genuegt. Natuerlich ohne Wartung, denn 
die Updates sind mir zu muehsam und machen, dass verschiedene Projekte 
verschiedene Versionen des Compilers verwenden. Teilweise sind die 
Aenderungen recht drastisch. dh man muss dann den Code anpassen. Die 
meisten Projekte sind nach einer Anfangsphase, nach ein paar Iterationen 
stabil und muessen eher nicht angepasst werden. Wenn ein Produkt 
draussen ist, wollen die Kunden auch keine Aenderungen mehr. Meist sind 
die Geraete dann durch eine Zertifizierung durch und somit eingefroren. 
Da wird dann 10..15 Jahre produziert bis ein Nachfolger kommt.
Die Programmiersprache war nie ein Thema, das interessiert niemanden.

Was ich muehsam an AVRCo finde ist das Treiberkonzept. Darauf werden 
viele Resource bei E-Lab verbraten. Ich verwende keinen einzigen. Denn 
diese sogenannten Treiber sind closed Source und machen irgendwas. Dabei 
ist es nicht allzu schwierig das Datenblatt eines peripheren Chips zu 
lesen, und umzusetzen, sodass es in ein eigenes Konzept passt. Ich 
haette lieber den compiler verbessert, zB 64 bit Variablen. Und smartere 
Optimierungen.

Und..alle 6..7 Jahre kaufe ich mir eine neue Version, zusammen mit einem 
neuen Notebook.

: Bearbeitet durch User
von Crazy Harry (crazy_h)


Lesenswert?

Ich habe mit der freien Mega8-Version von AVRCo angefangen und nachdem 
der uC ausgereizt war die Profiversion gekauft .... 100% Hobby !

@nicht jetzt: es gibt 64Bit-Variablen

von Nase (Gast)


Lesenswert?

Crazy H. schrieb:
> Nase schrieb:
>> AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch
>> mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es
>> seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von
>> "Title of this help project" umzubenennen...
> Ich merke schon: keine Ahnung
Blah.

von Postkunde (Gast)


Lesenswert?

Meine Version hat leider noch kein 64bit float...

von Tom (Gast)


Lesenswert?

Offensichtlich hat Pascal ein großes soziales Problem¹. Nach Lektüre 
dieses Threads würde ich schon deshalb kein Pascal-Projekt anfangen, 
weil zu befürchten ist, dass der in 3 Jahren zur Unterstützung 
eingestellte Pascal-Programmierer in meiner Firma so auftritt wie die 
Pascal-Fanbois hier im Thread.

¹ wie z.B. auch Lisp, dessen Beherrschung entweder unerträgliches 
Klugscheißen hervorzurufen scheint oder von vornherein nur 
unterträglichen Klugscheißern zu gelingen scheint.

von Tom (Gast)


Lesenswert?

na dann sähe es ja für C ganz Schlecht aus...ich finde dafür geht es 
hier noch sehr sachlich  zu.
Das hier einzelne etwas unangenehm auffallen, ist nunmal 
microxontroxler.xxx üblich...
Offenbar sind Elektroniker/Programmierer selten Sozial integriert, aber 
irgendwie ist das ja auch hinlänglich bekannt :-)
Aber solange die genug Tippfehler finden andenn die sich hochziehen 
könnnen oder eine einzige winzige Funktion finden, die PAscal nicht 
efüllen kann sind die auch glücklich :-)

von Harry (Gast)


Lesenswert?

Postkunde schrieb:
> Meine Version hat leider noch kein 64bit float...

Das nennt sich auch Fix64: 32Bit Zahl + 32Bit Exponent

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Joe G. schrieb:
> Nun schwanke ich, zurück und nochmals Mikroe oder LunaAVR.

Ich hab mal ein altes AVRCo Projekt auf die Demoversion von mikroPascal 
PRO portiert. Absolut problemlos! Meine Entscheidung ist gefallen :-)

von Arni (Gast)


Lesenswert?

bin gerade durch Zufall auf eine liste an Pascal Compilern gestoßen die 
hier sicher gut plazeirt ist
http://www.pascaland.org/pascall.htm

von Georg (Gast)


Lesenswert?

Arni schrieb:
> liste an Pascal Compilern

Schöne Fleissarbeit. Was ich vermisse ist jeweils das Datum der letzten 
Version, ein Compiler für PDP11 ist sicher nicht von 2015. Ich schätze 
mal fast alle sind uralt, das eben ist das Problem mit Pascal.

Georg

von Arni (Gast)


Lesenswert?

na da kenne ich aber auch genug C Compiler Empfehlungen im Netz die 
schon ewig nicht mehr existieren ;-)
Das Problem gibt es also auch odrt ;-)

von Masl (Gast)


Lesenswert?

Arni schrieb:
> na da kenne ich aber auch genug C Compiler Empfehlungen im Netz
> die
> schon ewig nicht mehr existieren ;-)
> Das Problem gibt es also auch odrt ;-)

Macht nix, der gcc und clang haben sich halt durchgesetzt, und das zu 
recht.
Klar gibt es noch paar Bastelcompiler (Peles etc.) aber im großen und 
Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander 
als wie Vorteile.

von Arni (Gast)


Lesenswert?

das stimmt, bei Pascal sind das ja auch nur noch mikro und e-lab und für 
den PC free pascal (hoffentlich auch in zukunft mit voller unterstützung 
für die kleinem arm)

von mehr ist mehr (Gast)


Lesenswert?

Masl schrieb:
> Arni schrieb:
> Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander
> als wie Vorteile.

Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und 
Wartburg. :-(

von Falk B. (falk)


Lesenswert?

@ mehr ist mehr (Gast)

>> Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander
>> als wie Vorteile.

>Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und
>Wartburg. :-(

Da ist was dran! Monokultur ist selten gut. Aber die haben wir nun weiß 
Gott nicht. Es gibt einige freie wie auch kommerzielle Kompiler, die 
sich schon einen gescheiten Wettbewerb liefern. Irgendwann ist es aber 
auch mal gut mit der Artenvielfalt, denn im kommerziellen Umfeld muss 
man seine Entwicklungskosten auch irgendwann mal wieder reinholen. Das 
können nicht hunderte von Firmen auf dem Markt. So verschenderisch wie 
Mutter Natur kann man im Kapitalismus nicht sein. Ausserdem ist der 
immer auf Kostenminimierung und Effizienzsteigerung aus, Mutter Natur 
nicht so ganz.

Schau dir das Feld der PCs an. Vor 30-40 Jahren gabe es unzählige 
Start-Ups mit ihren Homecomputer. Die meisten (fast alle) sind schon 
lange Geschichte. Heute gibt es ausser MAC und Wintel-PC kaum noch was 
anderes. Smartphones und Tablets sind neue Geräteklassen!
Auch die ehrwürdigen Workstation von Sun & Co fristen nur noch ein 
Schattendasein.

von Guido B. (guido-b)


Lesenswert?

Falk Brunner schrieb:
> Schau dir das Feld der PCs an. Vor 30-40 Jahren gabe es unzählige
> Start-Ups mit ihren Homecomputer. Die meisten (fast alle) sind schon
> lange Geschichte. Heute gibt es ausser MAC und Wintel-PC kaum noch was
> anderes. Smartphones und Tablets sind neue Geräteklassen!
> Auch die ehrwürdigen Workstation von Sun & Co fristen nur noch ein
> Schattendasein.

Und nach 30 Jahren startet miteinmal ARM durch, auch im Serverbereich.
Wer hätte das gedacht, Totgesagte leben halt doch als arg lang.

von Masl (Gast)


Lesenswert?

mehr ist mehr schrieb:
> Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und
> Wartburg. :-(

Das ist Ansichtssache.

Ich nehme für jedes Target und jede Sprache Eclipse als IDE, und wenn 
GUI mal nicht geht eben den vim.
Wieso soll ich jedesmal auf eine neue IDE umsteigen?

Als Compiler ist der gcc gesetzt, wenn er für die Sprache und das Target 
verfügbar ist.
Wieso soll ich jedesmal neue cli-Parameter lernen?

von Wecker (Gast)


Lesenswert?

Du sollst dir keine 20 Autos in die Garage stellen, aber 20 Leute müssen 
nicht alle das gleiche Auto fahren. ;-)

von rogger (Gast)


Lesenswert?

>C++ ist eher was für Masochisten, die eine Sprache andauernd lernen wollen

es sei denn man will nur c mit klassen. so wie arduino das macht...

von W.S. (Gast)


Lesenswert?

(...wegen Artenvielfalt...)
Falk Brunner schrieb:
> Da ist was dran! Monokultur ist selten gut. Aber die haben wir nun weiß
> Gott nicht. Es gibt einige freie wie auch kommerzielle Kompiler, die
> sich schon einen gescheiten Wettbewerb liefern. Irgendwann ist es aber
> auch mal gut mit der Artenvielfalt, denn im kommerziellen Umfeld muss
> man seine Entwicklungskosten auch irgendwann mal wieder reinholen.

Ähem.. du machst hier einen Denkfehler. Es geht nicht wirklich um 
Dutzende von C-Compilern, sondern eigentlich um eine Artenvielfalt unter 
den Programmiersprachen. Das ist ein dezenter Unterschied.

Mittlerweile bin ich der Meinung, daß die derzeitige C-Monokultur etwas 
sehr schlechtes ist - nicht im Moment aber auf lange Sicht, denn C ist 
ja durchaus benutzbar und Abertausende von jungen Leutchen benutzen C 
und kennen inzwischen nix anderes mehr.

Aber genau das ist der Knackpunkt.

C ist eigentlich sehr altertümlich und überhaupt nicht gut reformierbar 
und das ist ein sicheres Zeichen dafür daß es mit dieser Sprache in 
Zukunft mehr Probleme geben wird als bisher.

Schau nur mal auf die Datentypen: Außer char und int kennt diese Sprache 
eigentlich nix, denn alles was danach kommt, ist aufgepfropft: long ist 
eigentlich "long int" und all die neumodichen uint32_t und Konsorten 
sind ebenfalls nur per typedef aus den zugrundeliegenden Typen gemacht.
Und was wird irgendwann mal aus einem 128 Bit Integer? long long long 
int? Bei Pascal wäre das kein Problem, da würde man einfach nen int128 
als neuen echten Datentyp kreieren und fertig.

An solchen Details sieht man das Maß an Reformierbarkeit von 
Programmiersprachen. Und genau deshalb empfinde ich es als wirklich sehr 
dringend, auch Pascal und auch Basic am Leben zu halten und nicht dem 
kurzsichtigen Blick auf verfügbare Compiler zu opfern.

Allerdings sollte man Leuten wie Mikroe durchaus mal ne Predigt halten. 
Im Prinzip wäre es ja für einen Compiler für ARM nur wichtig, welche CPU 
drinnen werkelt und welche Maschinenbefehle man deswegen benutzen kann. 
Den ganzen Rest wie Speicherlayout und Peripherie-Register könnte man ja 
den Anwendern selbst überlassen, das Wort 'absolute' ware da extrem 
hilfreich. Aber bei Mikroe macht man's kompliziert und das schränkt die 
Anwendung auf wenige µC Typen ein und läßt alle anderen Interessenten im 
Regen stehen.

W.S.

von Mario (Gast)


Lesenswert?

Pascal oder Delphi, Altium sucht sicher Leute die ihre Bugs fixen und 
Altium ist auch in Delphi geschrieben.

von Salewski (Gast)


Lesenswert?

W.S. schrieb:
> C ist eigentlich sehr altertümlich
[...]
> dringend, auch Pascal und auch Basic am Leben zu halten

Das gibt für mich wenig Sinn. Basic und Pascal sind in etwa gleich alt. 
C wurde aber zum Programmieren entwickelt, Basic eher für Kinder, und 
Pascal für Studenten im erstem Semester.

Interessante moderne Sprachen gibt es ja genügend.

>Den ganzen Rest wie Speicherlayout und Peripherie-Register könnte man ja
>den Anwendern selbst überlassen,

Nu ja, der Anwender, wie er in diesem Forum und auch sonst grassiert, 
will eben alles vorgekaut haben.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> Und was wird irgendwann mal aus einem 128 Bit Integer?
> ...
> Bei Pascal wäre das kein Problem, da würde man einfach nen int128
> als neuen echten Datentyp kreieren und fertig.

Rein technisch wäre es auch in C kein größeres Problem als in Pascal,
int128 als vordefinierten Datentyp einzuführen. Man würde damit
allerdings in Kauf nehmen, dass alter Quellcode, der selber einen
Datentyp namesn int128 deklariert, nicht mehr ohn weiteres kompilierbar
ist.

In der C-Philosophie ist die Abwärtskompatibilität neuerer zu älteren
Standards eines der obersten Ziele. In Pascal wird offensichtlich die
Abwärtskompatibilität als nicht so wichtig erachtet, was natürlich mehr
Möglichkeiten für Erweiterungen offen lässt. Ob das eher ein Vorteil
oder ein Nachteil ist, mag jeder für sich entscheiden.

Das hat aber nichts mit der Reformierbarkeit der Sprache zu tun, sondern
mit der Abwägung der Sprachentwickler, welchen Kompromiss aus neuen
Features und den damit evtl. verbundenen Inkompatibilitäten sie für den
jeweiligen Anwender der Sprache als sinnvoll erachten.

> long long long int?

Diese Syntax, auch wenn sie hässlich erscheint, wäre jedenfalls voll
abwärtskompatibel. Ein neuer Typ namens int128 wäre es nicht, weder in C
noch in Pascal.

von die drei ? (Gast)


Lesenswert?

Wenn eine Sprache erweitert wird, können alte Programme immer übersetzt 
werden. Das geht bei Pascal problemlos und sollte bei C auch gehen, 
wenn sich an ein paar Regeln gehalten wird.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Salewski schrieb:
> und
> Pascal für Studenten im erstem Semester.

Das hat Apple aber nicht gehindert, Pascal zu dem Standard bei der 
Entwicklung der Mac Software bis Mac OS 9 zu machen. Manche erinnern 
sich vermutlich noch an MPW.
Erst mit Mac OS X wurde dann umgeschwenkt auf C, und das war erst zur 
Jahrtausendwende, bzw. 2001.

: Bearbeitet durch User
von Arni (Gast)


Lesenswert?

:-) Was zeigt, das Apple damals immer schon etwas weiter dachte als die 
anderen ;-)
Böse Zungen behaupten auch, das  das noch zu Zeiten war, als MACOs 
richtig stabil lief ;-)

Nur Spaß, macht daraus jetzt nicht gleich wieder trashing :-)

von Arni (Gast)


Lesenswert?

und nein, ich habe auch k.A: ob MAC OS damals besser lief als heute ;-)

von W.S. (Gast)


Lesenswert?

Salewski schrieb:
> Das gibt für mich wenig Sinn. Basic und Pascal sind in etwa gleich alt.
> C wurde aber zum Programmieren entwickelt, Basic eher für Kinder, und
> Pascal für Studenten im erstem Semester.

Schon wieder ne Verwechslung. ich meinte nicht ALT sondern 
Altertümlich. Fortran ist noch viel älter - und doch wird es auch 
heutzutage immer noch (allerdings in modernisierter Form) für 
Berechnungen benutzt von Leuten, sie sowas brauchen.
Dein Beitrag klingt nach: Basic ist was für Kinder, Pascal für dumme 
Jungen und nur C ist was für "richtige Männer". Ieks bah.



Yalu X. schrieb:
> Das hat aber nichts mit der Reformierbarkeit der Sprache zu tun, sondern
> mit der Abwägung der Sprachentwickler, welchen Kompromiss aus neuen
> Features und den damit evtl. verbundenen Inkompatibilitäten sie für den
> jeweiligen Anwender der Sprache als sinnvoll erachten.

Nee, das siehst du falsch.
Das ewige Argument der angeblich lebensnotwendigen Abwärtskompatibilität 
ist sowas von strunzfalsch, daß es mir auf die Nerven geht. In Pascal 
geht all das problemlos, wo du Kompromisse vermutest. Das liegt an der 
sehr weitsichtigen Grundkonstruktion von Pascal. C ist hingegen damals 
sehr kurzsichtig konstruiert worden und am häßlichsten sieht man das an 
den attributorientierten Variablen. Das ist aber nur ein Aspekt von 
vielen. Sowas kommt davon, wenn Praktiker und keine Akademiker eine 
Programmiersprache konstruieren wollen:
attribute grundtyp name [feldangabe]; oder
attribute grundtyp indirektionsmarker name;
sind eben eine ausgesprochen BLÖDE Art, etwas zu deklarieren. So etwas 
MUSS einem irgendwann auf die Füße fallen. Da ist ein
var
  name : typverweis;
deutlich klarer strukturiert und deshalb besser handhabbar und auch 
besser erweiterbar. Auch besser kompilierbar, eben weitsichtiger 
entworfen. Und genau DAS ist der Punkt, auf dem ich hier herumreite.


Yalu X. schrieb:
> Rein technisch wäre es auch in C kein größeres Problem als in Pascal..
Da widerspreche ich dir vehement. Sämtliche Erweiterungsversuche in C 
sind tatsächlich ein größeres Problem. Jedenfalls haben wir es in der 
Vergangenheit genau so erleben müssen.



Und weil wir hier im Mikrocontroller-Forum sind: Denk mal über den 
Unsinn von printf nach. Bei Pascal hat man mit str und write / writeln 
einen satz von Pseudofunktionen, die der Compiler selbst auflöst. Da 
kommt reiner, der aktuellen Funktion angepaßter Maschinencode heraus. 
Bei C braucht man einen Formatstring und einen Textinterpreter in der 
Firmware, der selbigen dekodieren soll und der natürlich garnix darüber 
weiß, was er denn so alles vorgesetzt bekommen wird, obendrein braucht 
man auch noch solche halsbrecherischen Sachen wie va_arg - und das in 
einem Mikrocontroller. Kein Wunder, daß nach immer dickeren µC gerufen 
wird.

Oder denk mal über Formulierungen nach wie diese:
#define VICFIQStatus   (*(volatile unsigned long *) 0xFFFF0004)

In Pascal würde das heutzutage etwa so gehen:
var
 VICFIQStatus : dword absolute $FFFF004;

Versuche mal spaßeshalber ein Array oder einen Record oder gar ein 
Objekt in C auf einer bestimmten Adresse mit #define zu definieren. Also 
das Gegenstück zu
var
 MyObject : TMyObject absolute $4000FF10;

Viel Spaß.

W.S.

von Tombo (Gast)


Lesenswert?

gerade passend dazu gefunden :-)
http://www.lowlevel.eu/wiki/Pascal

von Le X. (lex_91)


Lesenswert?

Man könnte jetzt wieder ewig auf die einzelnen Punkte eingehen und 
Gegenbeispiele konstruieren, aber wieso?
Tatsache ist einfach, C hat gewonnen, Pascal hat verloren*, da hilft 
auch alles lamentieren nichts.

*Da ändern auch die 1-2 größeren Projekte, die alle Jubeljahre mal mit 
Pascal oder einer seiner gefühlten 100 Nachfolgesprachen umgesetzt 
werden, nichts daran.

von Salewski (Gast)


Lesenswert?

W.S. schrieb:
> Das liegt an der
> sehr weitsichtigen Grundkonstruktion von Pascal.

Nun ja. Schon wenige Jahre nach der Vorstellung von Pascal hatte Wirth 
Modula 1 und 2, und später Oberon kreiert. Soweit ich mich errinnere war 
Wirth mit dem Erfolg von Turbo-Pascal nicht wirklich glücklich. Pascal 
sollte eigentlich einfach eine einfache Lehrsprache sein. Sicher hätte 
Wirth kommeriellen Erfolg von Modula oder Oberon lieber gesehen. Aber 
der blieb ja doch weitgehend aus, was u.a. wohl auch an der Namensgebung 
lag. Basic. Pascal und C schleppen viele hässliche Dinge mit. Bei Pascal 
etwa das "Begin". Von den vielen Basic-Dialekten oder den Delphi 
Erweiterung weiss ich allerdings nicht viel. Jedenfalls gefallen mir 
einige der modernen Sprachen wie etwa Nim, D, Rust, Haskell, Julia, 
Ruby, Python doch deutlich besser, auch wenn ich einige davon nur 
oberflächlich kenne. Dass ich C und C++ nicht liebe ist ja wohl bekannt, 
aber mit C kann ich für Mikrocontroller oder auch kleine 
Anwendungsprogramme leben.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> Das ewige Argument der angeblich lebensnotwendigen Abwärtskompatibilität
> ist sowas von strunzfalsch, daß es mir auf die Nerven geht.

Nein, falsch ist nur deine Ausdrucksweise: Du persönlich empfindest das
Argument der Abwärtskompatibilität als unwichtig. Das ist dein gutes
Recht, und deine Meinung wird sogar von prominenten Programmierpsrache-
entwicklern wie Guido van Rossum (Python) geteilt. Deswegen ist das
Argument aber noch lange nicht falsch.

> Das liegt an der sehr weitsichtigen Grundkonstruktion von Pascal.

Ich schließe mich diesem Kommentar an:

Salewski schrieb:
> Schon wenige Jahre nach der Vorstellung von Pascal hatte Wirth
> Modula 1 und 2, und später Oberon kreiert.

Wenn Pascal tatsächlich so weitsichtig konstruiert war und so problemlos
erweiterbar ist, wie du behauptest, warum hat er nicht einfach Pascal
weiterentwickelt? Dadurch hätte er Pascal eine sehr viel höhere Chance
gegeben, sich zu etablieren.

> C ist hingegen damals sehr kurzsichtig konstruiert worden und am
> häßlichsten sieht man das an ...

Die Punkte, die du ab da anführst, mögen aus der Sicht eines Schöngeists
richtig sein. Da sie hier im Forum aber schon zur Genüge diskutiert
wurden, möchte ich sie hier nicht weiter kommentieren.


> Sowas kommt davon, wenn Praktiker und keine Akademiker eine
> Programmiersprache konstruieren wollen:
> ...

Da du hier C mit Praktikern und Pascal mit Akademikern verbindest: Das
gilt nicht nur für die Programmiersprachenentwickler, sondern weitgehend
auch für die Anwender. Dies wiederum erklärt, warum C – ganz im
Gegensatz zu Pascal – auch heute noch stark im Rennen ist: Der Praktiker
sucht die Kontinuität und findet sie bei C, während der Akademiker immer
das Neueste mit einem Maximum an Eleganz und Mächtigkeit sucht, das
Pascal aber schon lange nicht mehr repräsentiert, nicht einmal mit den
vielen Erweiterungen, die es seither erfahren hat.

von Guido B. (guido-b)


Lesenswert?

Yalu X. schrieb:
> Wenn Pascal tatsächlich so weitsichtig konstruiert war und so problemlos
> erweiterbar ist, wie du behauptest, warum hat er nicht einfach Pascal
> weiterentwickelt? Dadurch hätte er Pascal eine sehr viel höhere Chance
> gegeben, sich zu etablieren.

Hat er doch! Hinter Oberon steckt immer noch Pascal mit denselben
Sprachelementen und Strukturen. Die wurden im Wesentlichen nur
erweitert, Änderungen waren nur geringfügig und sind zum Teil wohl
recht pragmatisch entstanden ("auf Wunsch der Anwender").

So ist beispielsweise die von Stephan kritisierte Flut von "BEGIN"
schon in Modula nicht mehr nötig, das 5 Jahre vor Turbo-Pascal
entstanden ist. Hierbei wurde gleichzeitig das irritierende "kein
Semikolon vor ELSE" mitentsorgt.

Das Problem war eigentlich nur, dass der Platzhirsch (Borland) solche
Sachen ignoriert hat (Praktiker statt Akademiker) und stattdessen
vieles falsch gemacht hat.

von Falk B. (falk)


Lesenswert?

@ W.S. (Gast)

>Und was wird irgendwann mal aus einem 128 Bit Integer?

>long long long int?

Ey maaaan, led me dell you this way

[reggae]
Ive been coding C
a lalalala long
a lalalala long
a lalalala long long le long long long
C'mon
[/reggae]

jamaikanische Grüße
Falk ;-)

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Falk Brunner schrieb:
> [reggae]
> Ive been coding C
> a lalalala long
> a lalalala long
> a lalalala long long le long long long
> C'mon
> [/reggae]

Great!

von Technikman (Gast)


Lesenswert?

Wusste ich es doch:
C ist was für Künstler und nichts für Techniker. ;-) ;-) ;-)

von Quappenkaul (Gast)


Lesenswert?

Falk Brunner schrieb:
> @ W.S. (Gast)
>
>>Und was wird irgendwann mal aus einem 128 Bit Integer?
>
>>long long long int?
>
> Ey maaaan, led me dell you this way
>
> [reggae]
> Ive been coding C
> a lalalala long
> a lalalala long
> a lalalala long long le long long long
> C'mon
> [/reggae]

Standing across the room
I saw you compile
Said I want to unit test-test-test
For a little while
But before I make my move
My emotions start running wild
My fingers get tied
And that's no lie
Looking at your eye
Looking at your big black eye
Ooh yeah
And I've got this to say to you
Hey!

Computer I want to make you sweat
Sweat till you can't sweat no more
And if you beep
I'm gonna push it some, more, more
Computer I want to make you sweat
Sweat till you can't sweat no more
And if you hiss
I'm gonna push it
Push it, push it some more

A la la la la long, a la la la la long long li long long long
C'mon
A la la la la long, a la la la la long long li long long long

So I said to myself
Does it link or not?
But the dreads done know
That executable is his to get
With a little bit of this
And a little bit of that
My lyric goes on the attack
My fingers gets tied
And that's no lie
Looking at your eye
Looking at your big black eye
Ooh computer
And I've got this to say to you
Hey!

A la la la la long, a la la la la long long li long long long
Yeah
A la la la la long, a la la la la long long li long long long
Push it push it some more
A la la la la long, a la la la la long long li long long long
Alright
A la la la la long, a la la la la long long li long long long
Push it, push it some more

von Salewski (Gast)


Lesenswert?

Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist 
bei weitem am umständlichsten:

http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort#Delphi

von Guido B. (guido-b)


Lesenswert?

Salewski schrieb:
> Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist
> bei weitem am umständlichsten:

Sieht aber aber auch verständlicher aus als andere Kameraden.
Schreib die Oberon-Lösung (Threads mit Sleep?)! ;-)

von Tombo (Gast)


Lesenswert?

sieht bei bubble sort schon wieder anders aus...
http://rosettacode.org/wiki/Bubble_Sort#Pascal

von Robert L. (lrlr)


Lesenswert?

Salewski schrieb:
> Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist
> bei weitem am umständlichsten:
>
> http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort#Delphi

und auch nur weil die 
http://docwiki.embarcadero.com/RADStudio/XE7/en/Using_TTask_from_the_Parallel_Programming_Library 
nicht verwendet wurde..

von W.S. (Gast)


Lesenswert?

Ach, wenn man hier mal nach einiger Zeit wieder reinschaut, grinst einen 
nur "lala long di long" an. Wirklich grandiose Argumente.


Yalu X. schrieb:
> Da du hier C mit Praktikern und Pascal mit Akademikern verbindest:

Nein, so wie du es breit redest, wird es sinnentstellend. Aber das 
Gefasel über C oder Pascal anhand von Beispielen, wie jemand mit C 
glücklich ist, führt zu nix. Nichtmal zu einer qualitativen 
Einschätzung.

Yalu X. schrieb:
> Der Praktiker sucht die Kontinuität und findet sie bei C,

Schau doch mal in dieses Forum: Hier suchen die C-Leutchen nicht nach 
Kontinuität, sondern einfach nur nach irgend einem Weg, das in C 
hinschreiben zu können, was sie eigentlich bezwecken wollen - und das 
fällt ihnen sichtbar schwer, so schwer, daß sie händeringend nach Hilfe 
schreien.

Reicht dir das als Indiz nicht?

Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu 
verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch 
mit einem modernen Pascal-Compiler übersetzen, weil dort all die 
neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach 
nicht vorkommen. Aber bei einer attributorientierten Sprache wie C ist 
das anders, ich habe ja nicht ohne Grund das "long long long int" als 
anschauliches Beispiel zur Diskussion gestellt. Weite Teile von C sind 
eben NICHT renovierbar und bleiben als Bremsklotz für die Zukunft 
erhalten - nenn es Kontinuität wenn du willst, wenngleich das falsch 
ist. Denk mal an den unsäglichen Krampf von uint32_t und Konsorten und 
die erwiesene Unfähigkeit, selbst sowas endlich mal vom Kopf auf die 
Füße zu stellen. Wieviele Argumente willst du denn noch ignorieren?

Dein Argument, daß Pascal ja das Rennen gemacht hätte, wenn es besser 
gewesen wäre, gilt nicht, denn du vernachlässigst ganz andere aber 
durchaus schwer wiegende Gründe. Pascal war und ist so gebaut, daß man 
es bei einigermaßen sauberer Quelle auch als Laie fast sofort lesen und 
verstehen kann - und genau DAS war und ist einer ganzen Zunft 
berufsmäßiger Programmierer allzeit ein Dorn im Auge, denn sie fürchten 
um ihre Existenzberechtigung, falls ihr jeweiliger Chef mal ne Quelle 
liest und dabei zum Schluß kommt "das kann ja jeder, das kann ja sogar 
ICH lesen". Eine nicht ganz unberechtigte Befürchtung meine ich, 
wenngleich auch auf einer vermuteten Fehleinschätzung seitens des CHEFFE 
beruhend. Tja, außertechnische Gründe haben oftmals ein nicht zu 
unterschätzendes Gewicht.

Aber immer nur zu schreiben "wir machen aber alle C - deswegen ist es ja 
viel besser als der Rest der Welt" finde ich albern. Es beinhaltet keine 
Analyse der betreffenden Programmiersprache auf ihre tatsächliche 
Qualität, eben keine Ernsthaftigkeit.

Das Argument von den Fliegen kennst du ja.

Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen 
bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie 
etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo 
der Vorteil liegen soll, wenn man alle nase lang immer neue 
"grandiosere" Sprachen wie die genannten erfindet. Gibt's dafür morgen 
früh auch nen guten Compiler für die Cortex M4 oder PIC16? Bei BASIC bin 
ich mir ziemlich sicher, daß es die Zeitläufte überstehen wird - auch 
wenn es nicht grad mein Fall ist und sämtliche C-Leute darüber die Nase 
rümpfen.

W.S.

von NSA (Gast)


Lesenswert?

W.S. schrieb:
> Schau doch mal in dieses Forum: Hier suchen die C-Leutchen nicht nach
> Kontinuität, sondern einfach nur nach irgend einem Weg, das in C
> hinschreiben zu können, was sie eigentlich bezwecken wollen - und das
> fällt ihnen sichtbar schwer, so schwer, daß sie händeringend nach Hilfe
> schreien.

Achso und in Pascal hätten sie diese Probleme nicht gehabt?

W.S. schrieb:
> Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu
> verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch
> mit einem modernen Pascal-Compiler übersetzen, weil dort all die
> neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach
> nicht vorkommen.

Also ich weiß nicht recht was ich davon halten soll (Quelle Wikipedia):

> Es gibt drei Standards, die sich auf Pascal beziehen:

> Standard Pascal: ANSI/IEEE770X3.97-1993 oder ISO 7185:1990;
> Extended Pascal: ANSI/IEEE770X3.160-1989 oder ISO/IEC 10206:1991;
> sowie einen Entwurf zu „Object-Oriented Extensions to Pascal“.
> Allerdings sind – wie bei den meisten anderen Programmiersprachen auch –
> nur die wenigsten Compiler zu diesen Standards vollständig kompatibel.
> Diese Tatsache verleitete Scott A. Moore zu der bissigen Bemerkung „Pascal
> is, unfortunately, very much a great improvement on its successors“
> („Pascal ist > leider so ziemlich eine große Verbesserung seiner
> Nachfolger“ – damals bereits ein geflügelter Satz).

> Selbst großen Compilern wie Delphi oder Free Pascal fehlen bis heute einige
> Elemente aus Standard Pascal, während Extended Pascal von kaum einem
> unterstützt wird. Lediglich Prospero Pascal ist vollständig kompatibel zu
> Extended Pascal, während auch GNU Pascal vollständige Kompatibilität
> anstrebt.

Sieht nicht so gut aus. Bei C kann man sich mind. auf ANSI C verlassen.

W.S. schrieb:
> Denk mal an den unsäglichen Krampf von uint32_t und Konsorten und
> die erwiesene Unfähigkeit, selbst sowas endlich mal vom Kopf auf die
> Füße zu stellen.

Und wo ist da jetzt das Problem mit stdint.h? Entweder man benötigt 
gewisse Zahlenräume -> int... oder gewisse Datentypengrößen -> uintx_t? 
Wenn es auf der Platform kein uintx_t der benötigen Größe gibt, gibt der 
Compiler einen Fehler aus. Also?

W.S. schrieb:
> Pascal war und ist so gebaut, daß man
> es bei einigermaßen sauberer Quelle auch als Laie fast sofort lesen und
> verstehen kann - und genau DAS war und ist einer ganzen Zunft
> berufsmäßiger Programmierer allzeit ein Dorn im Auge, denn sie fürchten
> um ihre Existenzberechtigung,

Sag mal glaubst du an Märchen?

W.S. schrieb:
> Aber immer nur zu schreiben "wir machen aber alle C - deswegen ist es ja
> viel besser als der Rest der Welt" finde ich albern. Es beinhaltet keine
> Analyse der betreffenden Programmiersprache auf ihre tatsächliche
> Qualität, eben keine Ernsthaftigkeit.

Und einige Leute sollten aufhören Pascal als den heilgen Gral der 
Programmiersprachen zu verkaufen...

von physiker (Gast)


Lesenswert?

W.S. schrieb:
> Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen
> bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie
> etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo
> der Vorteil liegen soll, wenn man alle nase lang immer neue
> "grandiosere" Sprachen wie die genannten erfindet.
Na ja, manche von denen implementieren andere Paradigmen wie Prozedural 
und Objektorientiert, z.B. Haskell funktional und LISP listenorientiert.

von Yalu X. (yalu) (Moderator)


Lesenswert?

W.S. schrieb:
> Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu
> verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch
> mit einem modernen Pascal-Compiler übersetzen, weil dort all die
> neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach
> nicht vorkommen.

Wie oft muss ich noch wiederholen, dass das nicht stimmt?

Prominentes Gegenbeispiel:

  http://www.moorecad.com/standardpascal/p4.html
  http://www.moorecad.com/standardpascal/pcom.pas

Da wirst du sogar noch ein paar Dinge mehr als nur den Typnamen
operator ändern müssen, um das Programm mit einem neueren
Pascal-Compiler (wie z.B. Free Pascal) zum Laufen zu bekommen.

> Aber bei einer attributorientierten Sprache wie C ist das anders, ich
> habe ja nicht ohne Grund das "long long long int" als anschauliches
> Beispiel zur Diskussion gestellt.

Wie oft muss ich noch wiederholen, dass diese Datentypbezeichnung zwar
nicht besonders schön, dafür aber völlig konfliktfrei zum bestehendem
C-Code ist?

Da die Sequenz "long long long int" nach aktuellem C-Standard ein Fehler
ist, wird man sie in keinem C-Quellcode finden. Folglich könnte man
einen Datentyp mit dieser Bezeichnung in einen zukünftigen C-Standard
aufnehmen, ohne irgendwelche Inkompatibilitäten befürchten zu müssen.

von Georg (Gast)


Lesenswert?

NSA schrieb:
> denn sie fürchten
>> um ihre Existenzberechtigung,
>
> Sag mal glaubst du an Märchen?

Ich habe im Lauf von einigen Jahrzehnten genug Programmierer 
kennengelernt, deren Primärziel es war, Code zu schreiben, den ausser 
ihnen niemand in der Firma versteht (was nebenbei bemerkt für mich ein 
klarer Entlassungsgrund wäre). Dir fehlt da wohl die praktische 
Berufserfahrung. Zugegebenermassen ist der Typ im Lauf der Zeit und mit 
der industriellen "Produktion" von Software seltener geworden.

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).

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, und 
deswegen hat die immer noch immense Bedeutung, auch wenn sie in Foren 
wie diesem hier konsequent totgeschwiegen wird.

Georg

von Karl Käfer (Gast)


Lesenswert?

Hallo Rainer,

Rainer S. schrieb:
> Was spricht für C?

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. Und das ist dann auch für Hobbyprogrammierer wichtiger als 
viele glauben.

Liebe Grüße,
Karl

von Karl Käfer (Gast)


Lesenswert?

Hallo Christian,

Christian Berger schrieb:
> Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum.
> (Pascal basierend)
>
> C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst
> nach einem Assembler machen. C++ ist eher was für Masochisten, die eine
> Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist.

Man merkt sofort: da spricht der Fachmann.

Liebe Grüße,
Karl

von Karl Käfer (Gast)


Lesenswert?

Hi g.,

g. c. schrieb:
> 5-Sterne-Los schrieb:
>> Für C spricht, dass Pascal nie über den Status einer akademischen
>> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20
>> Jahren), aber ohne Praxisrelevanz.
>
> Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache.
> Sonst gäbe es wohl kaum solche Software hier:
>
> http://www.diptrace.com/

Das ist die berühmte Ausnahme, die die Regel bestätigt. Wenn Du der 
einen Ausnahme die große Vielfalt ähnlicher Programme gegenüberstellst, 
die nicht in Delphi/Lazarus geschrieben worden sind, erhälst Du eine 
ziemlich genaue Annäherung, was mit "nie über den Status einer 
akademischen Sprache hinaus gekommen" gemeint ist. Nix für ungut! ;-)

Liebe Grüße,
Karl

von Karl Käfer (Gast)


Lesenswert?

Hallo cppler,

cppler schrieb:
> Also die Programmiersprache ist i.d.R. egal.
> Gut Klassiker:
> C: "shoot yourself in the foot"
> PASCAL: "the compiler wont let you shoot yourself in the foot"

Die praktische Erfahrung lehrt, daß man sich mit jeder 
Programmiersprache in den Fuß schießen kann. Denn immer, wenn Du etwas 
idiotensicher gemacht hast, kommt die Natur und erfindet bessere 
Idioten.

Liebe Grüße,
Karl

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

Karl Käfer schrieb:
> nämlich die breite Verfügbarkeit von sehr
> leistungsfähigen, gut getesteten und dokumentierten Werkzeugen und
> Bibliotheken. Und das ist dann auch für Hobbyprogrammierer wichtiger als
> viele glauben.

und jetzt meinst Du das sei ein Alleinstellungsmerkmal für C?
Für Pascal/Delphi trifft das im gleichen Masse zu, insbesondere für 
techn./wissenschaftl. Anwendungen.

Aus Erfahrung weiss ich dass C/C++ Programmierer für umfangreiche 
Applikationen ca. die 3 bis 10 fache Zeit als Delphi Programmierer 
benötigen. Ich hatte mal ein Dutzend von Beiden als Angestellte, daher 
kann ich mir dazu ein Urteil erlauben. In C/C++ wurde nur dann 
programmiert, wenn ein Kunde das unbedingt so wollte.

Und was meinst Du wovon Embarcadero ( http://www.embarcadero.com/de ) 
mit seinen neuesten Delphi-Versionen (Rad Studio) noch existiert. Es 
gibt jede Menge grosser Industrie-Software die auch heute noch in Delphi 
geschrieben wird. Das hat wohl seinen Grund.

Wo sind denn hier im Forum die C/C++ Programme (ich meine jetzt nicht 
Embedded für MC's)? Die Projekte hier sind in allem möglichen 
Programmiersprachen geschrieben, C/C++ hat man darunter nur spärlich 
entdeckt. Hat wohl auch seinen Grund.

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

Hallo,

TriHexagon schrieb:
>
1
> int* ptr = (int*)malloc(sizeof(int));
2
>
>
> Wenn man das sieht, weiß man bescheid ;)

Ja, ich weiß Bescheid: wer sowas schreibt, sollte Bäcker werden. Dann 
kann er den Mist, den er macht, wenigstens essen.

Liebe Grüße,
Karl

von Karl Käfer (Gast)


Lesenswert?

Hallo mehr,

mehr ist mehr schrieb:
> Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und
> Wartburg. :-(

http://en.wikipedia.org/wiki/List_of_compilers

Liebe Grüße,
Karl

von Andreas H. (ahz)


Lesenswert?

W.S. schrieb:
> Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen
> bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie
> etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo
> der Vorteil liegen soll, wenn man alle nase lang immer neue
> "grandiosere" Sprachen wie die genannten erfindet.

Also Lisp als neu erfundene (!!) ''"grandiosere" Sprache'' aufzulisten 
ist mutig aber lustig.

Kurzer WikiCheck wann folgende Sprachen entwickelt wurden:

Fortran 1957,
Lisp 1958,
C 1972

Natürlich gibt es immer neue Sprachen. Man entwickelt ja auch neue 
Sprach-/Implementierungskonzepte. Und die sind ja meist "per definition" 
schon nicht mehr abwärtskompatibel.

Und willst Du wirkich heute noch Fortran IV hacken ?

/regards
Andreas

von Teslaspule (Gast)


Lesenswert?

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?

von Adrian (Gast)


Lesenswert?

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 ;-)

von Robert L. (lrlr)


Lesenswert?

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

: Bearbeitet durch User
von Teslaspule (Gast)


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

>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..)

von W.S. (Gast)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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?

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von zapotek (Gast)


Lesenswert?

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

von Adrian (Gast)


Lesenswert?

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 :-)

von Bastler (Gast)


Lesenswert?

Damit ist es also klar: nur das Beste setzt sich nicht durch ;-)

von zapotek (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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)

von Karl Käfer (Gast)


Lesenswert?

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

von Adrian (Gast)


Lesenswert?

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.

von Walter (Gast)


Lesenswert?

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.

von Adrian (Gast)


Lesenswert?

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 ;-)

von Adrian (Gast)


Lesenswert?

iN PASCAL ist dann auch ein Trhat selten länger als 5 Posts, in C 
dagegen...
Dadurch sehen die C Foren immer sehr viel besser besucht aus :-)

von Bernd K. (prof7bit)


Lesenswert?

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.html
http://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.

von Salewski, Stefan (Gast)


Lesenswert?

Übrigens, wer nun doch nicht C oder Pascal für die ultimative Sprache 
hält, kann ja mal das hier lesen:

http://eev.ee/blog/2015/02/28/sylph-the-programming-language-i-want/

von Adrian (Gast)


Lesenswert?

naja, wie gesagt, es sollte die Sprache auch für µc geben, und da bleibt 
eben nur PAscal, C und Basic

von Adrian (Gast)


Lesenswert?

ach ja und vielleicht noch LunaAvr

von Salewski, Stefan (Gast)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

Ich habe gerade mal nachgeschaut: MSP430 und PIC16 wird von LLVM wohl 
immerhin unterstützt.

http://de.wikipedia.org/wiki/LLVM#Unterst.C3.BCtzte_Architekturen

von Adrian (Gast)


Lesenswert?

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

von TriHexagon (Gast)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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.

von Adrian (Gast)


Lesenswert?

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

von Adrian (Gast)


Lesenswert?

solche Diskussionen wirst Du in Pascal Foren wirklich schwehrlich 
finden!

von Guido B. (guido-b)


Lesenswert?

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

: Bearbeitet durch User
von Salewski, Stefan (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Lukas K. (carrotindustries)


Lesenswert?

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
int main(void) {
4
  volatile char *s = "Hallo Welt";
5
  printf("%s\n", s);
6
  return 0;
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.

von Andreas H. (ahz)


Lesenswert?

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

von Le X. (lex_91)


Lesenswert?

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 :-)

von Karl Käfer (Gast)


Lesenswert?

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

von Robert L. (lrlr)


Lesenswert?

>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 ;-) )

von Karl Käfer (Gast)


Lesenswert?

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

von Kim S. (Gast)


Lesenswert?

"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

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

1 Seite Pascal = 1 Zeile C.

Das war für mich schon Grund genug auf C umzuschwenken.
Bereut habe ich das nie.

von Karl Käfer (Gast)


Lesenswert?

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

von Kim S. (Gast)


Lesenswert?

"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

von Helmut L. (helmi1)


Lesenswert?

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. :=)

von X4U (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

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.

von TriHexagon (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von X4U (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Karl Käfer (Gast)


Lesenswert?

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

von Robert L. (lrlr)


Lesenswert?

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

von Robert L. (lrlr)


Lesenswert?

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

von TriHexagon (Gast)


Lesenswert?

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++.

von Karl Käfer (Gast)


Lesenswert?

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

von Karl Käfer (Gast)


Lesenswert?

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

von Robert L. (lrlr)


Lesenswert?

>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 ;-)

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

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

von Kai M. (kai_mauer)


Lesenswert?

"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

von TriHexagon (Gast)


Lesenswert?

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.

von Walter S. (avatar)


Lesenswert?

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)

von Kai M. (kai_mauer)


Lesenswert?

Walter S. schrieb:
> 1x darfst du raten was ich an der Uni gelernt habe und was ich heute
> programmiere ...

Kein Interesse...

von Walter S. (avatar)


Lesenswert?

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

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

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

von TriHexagon (Gast)


Lesenswert?

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
int size = 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
char str[50];
2
int size = 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.

von TriHexagon (Gast)


Lesenswert?

Typischer Copypaste-Fehler. NULL ist da fehl am Platze.
1
char str[50];
2
int size = snprintf(str, 50, "%u", 1000);
3
if (size >= 50) //wenn Puffer zu klein
4
...

von Rolf M. (rmagnus)


Lesenswert?

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.

von bal (Gast)


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

>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 ;-)

von Karl Käfer (Gast)


Lesenswert?

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ß:
1
int len_int(int num) {
2
    int neg = 1;
3
    if(num < 0) {
4
  num *= -1;
5
  neg += 1;
6
    }
7
    for(int i = 1; i < 10; ++i) {
8
  if( num < pow((double)10, (double)i) ) {
9
      return i + neg;
10
  }
11
    }
12
    return 0;
13
}

Liebe Grüße,
Karl

von LachtÜberC (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Fragezeichen? (Gast)


Lesenswert?

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.

von Hier (Gast)


Lesenswert?

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;

von Hier (Gast)


Lesenswert?

Sorry, das obige war an Fragezeichen? (Gast) gerichtet

von Fragezeichen? (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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:
1
Variable vom Typ AnsiString:
2
  Zeiger auf einem Heap-Chunk:                            4 Bytes
3
4
Heap-Chunk:
5
  Größeninformation des Chunks:                           4 Bytes
6
  Referenzzähler (für automatische Speicherbereinigung):  4 Bytes
7
  Längeninformation des Strings:                          4 Bytes
8
  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.

von Georg (Gast)


Lesenswert?

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

von Fragezeichen? (Gast)


Lesenswert?

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.

von Oldtimer (Gast)


Lesenswert?

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

von Fragezeichen? (Gast)


Lesenswert?

@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 :-)

von Karl Käfer (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Oldtimer,

Oldtimer schrieb:
> Fragezeichen? schrieb:
>> Turbo-Zeiten
>
> Ja, ja, ja, die guten alten Turbo Zeiten. :-)))

Hach ja, lang, lang ist's her...

Liebe Grüße,
Karl

von Fragezeichen? (Gast)


Lesenswert?

Ich kannte schon das Turbo-Pascal für CP/M. War das eine Wohltat 
gegenüber M80 :-))

von Georg (Gast)


Lesenswert?

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

von Fragezeichen? (Gast)


Lesenswert?

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!

von Oldtimer (Gast)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von bal (Gast)


Lesenswert?

Georg schrieb:
> da träumt mancher heutige Editor davon.

Welcher?

von Fragezeichen? (Gast)


Lesenswert?

Was damals noch Sache des Anwendungsprogramms war, macht heute das 
unterliegende Betriebssystem. Nennt sich Paging :-)

von Georg (Gast)


Lesenswert?

bal schrieb:
> Georg schrieb:
>> da träumt mancher heutige Editor davon.
>
> Welcher?

Notepad? Immerhin der wohl meistbenutzte Editor auf unserem Planeten.

Georg

von Rolf M. (rmagnus)


Lesenswert?

Georg schrieb:
> Notepad? Immerhin der wohl meistbenutzte Editor auf unserem Planeten.

Und auch so ziemlich der schlechteste Editor des Planeten.

von Karl Käfer (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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.

von Ben (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Walter (Gast)


Lesenswert?

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!

von Tombo (Gast)


Lesenswert?

"- 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 ;-)

von Ben (Gast)


Lesenswert?

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

von Tombo (Gast)


Lesenswert?

warum willst Du es denn besser wissen?!
Wie gesagt ich verdiene mein Geld mit Pascal und ich kenne einige Firmen 
die ebenfalls damit arbeiten..

von TriHexagon (Gast)


Lesenswert?

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

von Bernd K. (prof7bit)


Lesenswert?

Karl Käfer schrieb:
> Und es wird Pascal auch nicht wieder zum Leben erwecken.

Wieso, es lebt doch und erfreut sich bester Gesundheit, warum erwecken?

von Bastler (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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]);

Pascal:
1
  writeln('| ', i:2, ' | ', a[i]:7:3, ' | ', b[i]:7:3, ' |');

Fortran:
1
       PRINT 111, I, A(I), B(I)
2
111    FORMAT ('| ', I2, ' | ', F7.3, ' | ', F7.3, ' |')


Jetzt soll die gleiche Ausgabe in eine Datei ausgegeben werden. Das
sieht nicht sehr viel anders aus:

C:
1
  fprintf(fp, "| %2d | %7.3f | %7.3f |\n", i, a[i], b[i]);

Pascal:
1
  writeln(fp, '| ', i:2, ' | ', a[i]:7:3, ' | ', b[i]:7:3, ' |');

Fortran:
1
       WRITE(10, 111), I, A(I), B(I)
2
111    FORMAT ('| ', I2, ' | ', F7.3, ' | ', F7.3, ' |')


Oftmals möchte man die formatierte Zeile nicht sofort ausgeben, sondern
zur weiteren Verarbeitung in eine Stringvariable schreiben.

C:
1
  sprintf(s, "| %2d | %7.3f | %7.3f |\n", i, a[i], b[i]);

Fortran:
1
       WRITE(S, 111), I, A(I), B(I)
2
111    FORMAT ('| ', I2, ' | ', F7.3, ' | ', F7.3, ' |')

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
1
  writeln(s, '| ', i:2, ' | ', a[i]:7:3, ' | ', b[i]:7:3, ' |');

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
1
  format(s, '| ', i:2, ' | ', a[i]:7:3, ' | ', b[i]:7:3, ' |');

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:
1
  str(i:2, s1);
2
  str(a[i]:7:3, s2);
3
  str(b[i]:7:3, s3);
4
  s := '| ' + s1 + ' | ' + s2 + ' | ' + s3 + ' |'#10;

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:

1
  s := format('| %2d | %7.3f | %7.3f |'#10, [i, a[i], b[i]]);

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.

von Mark B. (markbrandis)


Lesenswert?

Immer wieder herrlich, wenn ein Yalu X. kommt und urbane Legenden 
entschärft. :-)

von Arc N. (arc)


Lesenswert?

@Yalu:
Wie wär's mit WriteStr
http://www.freepascal.org/docs-html/rtl/system/writestr.html
"WriteStr is defined in the ISO Extended Pascal standard" (1990)
Im Standard
http://www.pascal-central.com/docs/iso10206.pdf
ist definiert wie sich WriteStr verhalten soll:
rewrite(f);
writeln(f, ...);
reset(f);
read(f, str);

von Robert L. (lrlr)


Lesenswert?

>writeln

jemand der aktuell! Pascal programmiert, wird wohl nur SEHR selten mit 
diesem Befehl in Berührung kommen..

von Rolf Magnus (Gast)


Lesenswert?

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?

von Adrian (Gast)


Lesenswert?

"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

von TriHexagon (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Adrian (Gast)


Lesenswert?

Bewirb dich doch einfach mal mit Ref als Pascal Pogrammierer..Du wirst 
überrascht sein ;-)

von Adrian (Gast)


Lesenswert?

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?

von Adrian (Gast)


Lesenswert?


von Blup (Gast)


Lesenswert?

Adrian schrieb:
> Wird für den PC noch so viel in C geschrieben?

Nein, natürlich nicht. Man muss eine Statistik nur deuten können:
http://de.wikipedia.org/wiki/TIOBE-Index

von Bernd K. (prof7bit)


Lesenswert?

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!

von hash tag (Gast)


Lesenswert?

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

von Kenner (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von Gerhard Z. (germel)


Lesenswert?

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

von Possetitjel (Gast)


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

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

von Jürgen (Gast)


Lesenswert?

Hier beschreibt einer diverse Sprachen (unter anderem auch Pascal):

https://www.proggen.org/doku.php?id=start:language

von Robert L. (lrlr)


Lesenswert?

>geschrieben im August 2008

das "fazit" von damals ist wohl nicht mehr aktuell ...

von Yalu X. (yalu) (Moderator)


Lesenswert?

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]
2
   b = i;

von Kenner (Gast)


Lesenswert?

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.

von Django (Gast)


Lesenswert?

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!

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.