Ich bin gerade durch Zufall auf einer Schulungsseite gestoßen und war überrascht, das sogar noch aktiv Schulungen für FreePAscal/Lazaraus/ Turbo Pascal(Borland Pascal) angeboten werden für Firmen etc. https://www.medienreich.de/trainings?query=pascal&type=public Auch die Kursteilnehmer: 55 Kunden besuchten bereits diesen Kurs. Sony, VW, itelligence, EADS, Sanyo, Sage Und Geld verdienen offenbar auch einige damit. https://www.andre-winkelmann.de/ "Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ vergleichbar ist. Als großer Vorteil gegenüber anderen Sprachen gilt gemeinhin die bessere Lesbarkeit des Codes. "
Gegeg J. schrieb: > angeboten werden für Firmen etc. Da hat irgendwer mal ein Projekt mit Pascal aufgebaut, was dann nur noch gewartet werden muss, was billiger ist, als alles neu zu schreiben. Bei EADS geht es ja auch um sicherheitsrelevante Software. Die ersetzt man nicht einfach mal so. Gegeg J. schrieb: > "Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus > Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ > vergleichbar ist. Als großer Vorteil gegenüber anderen Sprachen gilt > gemeinhin die bessere Lesbarkeit des Codes. " Objektorietierte Pascal gibt es schon seit den 1990ern. Es war "leserlicher" als C++.
Es gibt halt auch noch Dinge neben C und allen C-lastigen Abkömmlingen. Und man sollte es kaum glauben man kann mit (Objekt)Pascal gute Software schreiben, deren Quelltexte sogar meist gut lesbar sind.
Wow, da geistern Zombies in der Daemmerung herum. Und pruegeln sich mit Altsprachen wie C um die besten Plaetze in der Zombie Liga. Die moderne Welt will moderne Sprachen. Wie zB Python, wo ein Blank ueber sein oder nichtsein entscheidet. Ein Gross-Klein Tipp Fehler und eine neue Variable wird erzeugt, waehrend ich glaube es waere dieselbe. Schoene neue Debugwelt. Ich mach immer noch alles mit Delphi.
Joggel E. schrieb: > Die moderne > Welt will moderne Sprachen. Wie zB Python, wo ein Blank ueber sein oder > nichtsein entscheidet. Ein Gross-Klein Tipp Fehler und eine neue > Variable wird erzeugt, waehrend ich glaube es waere dieselbe. > Ich mach immer noch alles mit Delphi. Ich auch. Aber: laß das hier mal die Richtigen lesen, dann wirst Du des Lebens nicht mehr froh...
Gegeg J. schrieb: > "Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus > Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ > vergleichbar ist. Als großer Vorteil gegenüber anderen Sprachen gilt > gemeinhin die bessere Lesbarkeit des Codes. " Borland Pascal/Delphi ist imo eine der besten Entwicklungsumgebungen die es gibt. Das ist jetzt ohne Eigeninteresse da ich es selber nicht Nutze. In den Softwareprojekten wo es im Einsatz war liefen aber viele Dinge deutlich runder und wesentlich schneller. C für OS und embedded, Delphi für die Anwendungsseite ist imo eine super Kombi. Es gibt natürlich auch noch andere, keine Frage.
STK500-Besitzer schrieb: > Bei EADS geht es ja auch um sicherheitsrelevante Software. Die ersetzt > man nicht einfach mal so. Bloß weil EADS auf dem Türschild steht heißt es noch lange nicht das dort alle Software sicherheitsrelevant ist. Da gibt es auch genug interne Software die keine höheren Anforderungen hat als in jeder anderen Firma auch. STK500-Besitzer schrieb: > Da hat irgendwer mal ein Projekt mit Pascal aufgebaut, was dann nur noch > gewartet werden muss, was billiger ist, als alles neu zu schreiben. > Genau das ist der Punkt! Irgendwelche Tool die von Mitarbeitern mal eben schnell für eine einmalige Verwendung zusammengeschustert wurden und die sich dann aus so gut und Hilfreich erweisen das sie 20 Jahre Später immer noch im Einsatz sind und regelmäßig angepasst werden müssen. Der Aufwand so was mal eben schnell in einer anderen Programmiersprache neu zu entwickeln ist da oftmals viel zu hoch und wenn alles gut geht hat man am ende genau das selbe wie vorher, nur mit viel Arbeit bis es Funktional wieder identisch ist. Der Einsparungseffekt bei anschließenden Pflegeaufwand geht auch eher gegen null - wenn man den jemand hat der die verwendete Sprache einigermaßen kann. Hier sieht man ganz gut das es eben "Die Programiersprache" nicht gibt: https://news.efinancialcareers.com/de-de/248049/die-angesagtesten-programmiersprachen-in-banking-finance Und auch ganz alte Dino-Sprachen leben aus genau diesen gründen noch: https://www.wiwo.de/alte-programmiersprache-banken-holen-it-veteranen-aus-dem-ruhestand/19690034.html
Gegeg J. schrieb: > Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus > Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ > vergleichbar ist Wirklich! C++ ist eine extrem komplexe Sprache. Zu den größten Stärken zählen die mächtigen Möglichkeiten zur Metaprogrammierung. Wie geht das in Object Pascal? Habe dazu auf die Schnelle nichts gefunden.
Gegeg J. schrieb: > Ich bin gerade durch Zufall auf einer Schulungsseite gestoßen und war > überrascht, das sogar noch aktiv Schulungen für FreePAscal/Lazaraus/ > Turbo Pascal(Borland Pascal) angeboten werden für Firmen etc. Für mich wenig überraschend ist, dass es noch sehr viel mehr professionelle Cobol-Schulungen gibt. > Auch die Kursteilnehmer: > 55 Kunden besuchten bereits diesen Kurs. > Sony, VW, itelligence, EADS, Sanyo, Sage Du kannst davon ausgehen, dass auch die Teilnehmer von Cobol-Kursen nicht von kleinen Klitschen kommen. > Und Geld verdienen offenbar auch einige damit. > https://www.andre-winkelmann.de/ Auch Cobol macht kaum einer zum Spaß, sondern um damit ordentlich Kohle einzufahren. > "Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus > Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ > vergleichbar ist. Als großer Vorteil gegenüber anderen Sprachen gilt > gemeinhin die bessere Lesbarkeit des Codes. " Die Lesbarkeit von Object Pascal ist nichts gegenüber der Lesbarkeit von Cobol. Diese Sprache ist wirklich sprechend, und wenn man möchte, kann man auf die von Anfängern viel gescholtenen Sonderzeichen praktisch völlig verzichten. Also wenn mich mein Arbeitgeber vor die Wahl stellen würde, entweder einen Object-Pascal- oder einen Cobol-Kurs zu besuchen, würde ich mich, ohne lange nachzudenken, für letzteren entscheiden. Nützen würden mir beide Kurse nichts, aber mir dem Cobol-Kurs hätte ich sehr viel mehr Spaß.
Dr. Sommer schrieb: > Zu den größten Stärken > zählen die mächtigen Möglichkeiten zur Metaprogrammierung Hust, IMHO ist das eine der größten Schwächen wo sich C++ hin entwickelt hat. Wer SFINAE und CTAD verstanden hat sieht das anders ;-) Und richtige Metaprogrammierung kommt wohl erst nach C++20 wo auch Reflection möglich ist. Aber Leute es besteht Hoffnung, Mr. Stroustrup arbeitet daran die Sprache einfacher zu machen... P.S. Wer was schönes über C++ lesen will, suche mal im Web nach "Spaceship operator"....
loeti2 schrieb: > P.S. Wer was schönes über C++ lesen will, suche mal im Web nach > "Spaceship operator".... Ich bin nun überhaupt nicht qualifiziert über die Feinheiten von c++ zu reden. Aber mein Eindruck beim lesen war "Spätestens ab C++32 muss sich der "Programmierer" überhaupt keine Gedanken mehr über diese komplizierte Programmiersache machen, da besteht dann die Entwicklungsumgebung aus einigen niedlichen Bildchen die der "Programierer" mittels Touchscreen hin und herschiebt. Der Compiler macht denn daraus dann schon irgendwie irgendwas". Kapiert irgendjemand überhaupt noch was das codemässig passiert? Braucht man so etwas zur normalen Anwendungsentwicklung?
loeti2 schrieb: > Hust, IMHO ist das eine der größten Schwächen wo sich C++ hin entwickelt > hat. Wenn du Features als Schwäche siehst... viel andere Alleinstellungsmerkmale hat C++ nicht. Ohne Metaprogrammierung wäre das ziemlich witzlos. loeti2 schrieb: > Und richtige Metaprogrammierung kommt wohl erst nach C++20 wo auch > Reflection möglich ist. Wo gibt es denn sonst "richtige" Metaprogrammierung mit statischer (!) Reflektion? test schrieb: > Kapiert irgendjemand überhaupt noch was das codemässig passiert? Ja. test schrieb: > Braucht man so etwas zur normalen Anwendungsentwicklung? Man "braucht" nicht mehr als das was Brainfuck bietet. Aber hilfreich sind zusätzliche Hilfestellungen schon.
Dr. Sommer schrieb: > Wenn du Features als Schwäche siehst... viel andere > Alleinstellungsmerkmale hat C++ nicht. Ohne Metaprogrammierung wäre das > ziemlich witzlos. Ich meine ja nicht die Metaprogrammierung an sich, aber wie sie implementiert ist. IHMO ist SFINAE, enable_if etc. nicht wirklich programmiererfreundlich. In C++20 geht es ja mit Concepts schon ein bisschen in die richtige Richtung, aber lt. youtube-Video Stroustup wird die Implementierung eines Templates nicht gegen die Concepts geprüft, d.h. obwohl die aktuellen Typen die Concepts einhalten können immer noch ominöse Compilerfehler tief in irgendwelchem Templatecode auftreten. Und wie dann damit vernünftig Modules implementiert werden sollen, wo ja nur das Interface dem Verwender zugänglich ist nicht die Implementierung weiß auch keiner.
Muss einmal im Monat jemand am Wochende einen Pascal-Thread lostreten? Ihr wisst doch alle genau wie das wieder endet! Es ist Wochenende verdammt nochmal! Ich will mich entspannen und erholen und nicht mich schon wieder aufregen und mit erhobener Faust dem Bildschirm drohen müssen während ich lautlos innerlich brülle vor Wut, noch lange bevor der Montag überhaupt erst begonnen hat! Bedenkt das!
:
Bearbeitet durch User
Bla, bla, bal, was der Bauer nicht kennt ... Der Wintermann und der der IchSteheÜberAllenModerator kennen Dephi nur vom Namen. Ich werde zu C und C++ gezwungen und korrigiere täglich Fehler, die sich aus der Schwäche dieser Sprachen ergeben. Mit Delphi hätte ich mehr Freizeit, aber weniger Geld. ;>
Delphi ist doch ein Zombie. Embarcadero sind die Entwickler weggelaufen, nicht mal Bugfixing beherrscht der Rest. So wird alle paar Monde eine neue Version rausgehauen mit den ewig gleichen Bugs. Wer setzt denn auf so eine Leichenplatform die schon sehr streng riecht? Lazurus ist noch schlimmer: Die Doku ist ein zusammengewürfelter Müllhaufen und damit schon sofort raus. Spielzeug für Frickler und Leute die in den 90ern steckengeblieben sind. Ich kenne hier ne Bude die strickt schon seit einem Jahr ihre alten delphibasierten Inhouseanwendungen auf Webanwendungen um, das Delphigerümpel vermisst dort kein Mensch.
Es war irgendwann Anfang der 2000er auf der OOP-World in München, als Stroustrup sagte: Wenn ich gewusst hätte was aus C++ wird, hätte ich es nicht angefangen. Mal als Anregung für alle Sprachkritiker ein Buch: Literate Programming von D. Knuth. Ansonsten, geht heute mal spazieren gehen. Das Wetter ist angenehme (hier im Münchner Hinterland). Auf eine der zahlreichen Bänke am Waldrand setzen und den Himmel und die Landschaft anschauen. Aber kein Handy mitnehmen. Nick
Prima Klima schrieb: >> Ich mach immer noch alles mit Delphi. > > Ich auch. Aber: laß das hier mal die Richtigen lesen, dann wirst Du des > Lebens nicht mehr froh... Bei manchen Antworten ist es echt schwierig, den Inhalt der Tasse in der Hand (Wasser, Kaffe) und im Mund zu behalten..
loeti2 schrieb: > Ich meine ja nicht die Metaprogrammierung an sich, aber wie sie > implementiert ist. Welche Sprache macht es denn richtig, und zwar alles statisch zur compiletime? Man könnte LISP anführen, aber das ist kaum vergleichbar. > IHMO ist SFINAE, enable_if etc. nicht wirklich programmiererfreundlich. Ja, aber freundlicher als wenn es gar nicht existieren würde.
Ich sehe gerade, der Double Commander fuer Linux ist auch in Freepascal / Lazarus Pascal geschrieben
STM32prog ist ebenfalls in PAscal geschrieben und nutzt dTS und RTS etc um Boot0 und Reset anzusteuern Beitrag "STM32Fxxx Bootlader Programmer STM32Prog"
Noch eins in Pascal/Delphi Diptrace http://www.oem-pcb.com/info/diptrace-basic-features-custom-design-circuit-2953984.html
Dr. Sommer schrieb: > Wirklich! C++ ist eine extrem komplexe Sprache. Zu den größten Stärken > zählen die mächtigen Möglichkeiten zur Metaprogrammierung. Wie geht das > in Object Pascal? Habe dazu auf die Schnelle nichts gefunden Eine kleine Hilfe für dich: http://vschart.de/vergleich/delphi-programming-language/vs/c-plus-plus
Tany schrieb: > Eine kleine Hilfe für dich: > http://vschart.de/vergleich/delphi-programming-language/vs/c-plus-plus Wo in dieser endlosen Liste an für Programmiersprachen völlig irrelevanten Eigenschaften ("Autofokus"? "Infrarotschnittstelle"? Wtf?) steht wie man in "Object Pascal" Metaprogrammierung macht? Bei C++ steht "dynamische Typisierung"... Haha! Diese Liste ist kompletter Unsinn.
Tany schrieb: > Dr. Sommer schrieb: >> Wirklich! C++ ist eine extrem komplexe Sprache. Zu den größten Stärken >> zählen die mächtigen Möglichkeiten zur Metaprogrammierung. Wie geht das >> in Object Pascal? Habe dazu auf die Schnelle nichts gefunden > > Eine kleine Hilfe für dich: > http://vschart.de/vergleich/delphi-programming-language/vs/c-plus-plus Ohje ... Mal davon abgesehen, dass der Link keine Antwort auf die Frage gibt, ist der Inhalt doch eher fragwürdig.
mh schrieb: > Mal davon abgesehen, dass der Link keine Antwort auf die Frage gibt, ist > der Inhalt doch eher fragwürdig. Das war einfach keine Frage. Er hat bewusst eine Stärke zur Provokation hervorgehoben.
Tany schrieb: > Na klardo! Alles, was dir nicht passen, sind Unsinn. Du würdest also sagen dass es korrekt ist, dass C++ gleichzeitig dynamische und statische Typisierung nutzt? Und dass Delphi eine Infrarotschnittstelle hat? Und man so etwas wie das Facade Pattern mit C++ nicht umsetzen kann? Und dass C das Backend für C++ ist? Dass beide Sprachen eine 3,5mm-Klinken-Buchse bieten? Dass C++ einen Datentyp namens "SMALL INT" hat? Dass "I like it" und "Makes you angry" und "wtf mode" und "WillGetYouLaid" gültige Kriterien sind? Aber gut zu wissen dass Delphi "Von Affen geschrieben" ist und Haarausfall bewirkt! Tany schrieb: > Er hat bewusst eine Stärke zur Provokation > hervorgehoben. Wieso ist das eine Provokation? C++ bietet etwas, was ein guter Grund sein kann, sich für C++ zu entscheiden. Anmerken, dass andere Sprachen das nicht können, ist legitim.
Tany schrieb: > Dr. Sommer schrieb: >>...kompletter Unsinn. > > Na klardo! Alles, was dir nicht passen, sind Unsinn. Ok dann fang mal an ein paar Fragen zu dieser Liste zu beantworten. Aber beachte bitte, dass Programmiersprachen verglichen werden. Was ist mit Mehrbenutzersystem und Autofokus und Pingback gemeint? Wofür braucht Delphi 2GB Arbeitsspeicher? Worauf genau bezieht sich Extension/Plug-in? Was ist mit Bildprozessor und "from c" gemeint? Warum ist der Status C++ bei Mehrsprachiger Inhalt nur bedingt? Was genau fehlt für ein "Ja"? Was ist mit Transaktionen gemeint? Wie wird Energieverbrauch gemessen? Delphi hat nen eingebauten WYSIWYG-Editor oder wird in einem entickelt? Was sind Multiple Projekten? Um welchen Standard geht es wenn von Standardkonform gesprochen wird? Was sind Externe Seiten bei einer Programmiersprache? Delphi führt Benutzer-Statistiken? Und für wen, die NSA? C++ hat Map and reduce. Wenn das gemeint ist, was ich denke. Die Sprache C++ ist Versioniert. Delphi ist isoliert? Wovon? Wie skaliert man C++ horizontal? Was genau ist mit "Any you want" als Template Language gemeint? Die STL ist eine Template Language? ...
Hör bitte auf, andauernd irgendeine Programmiersprache zu "vergöttern" und anders denkende zu erniedrigen. Viele Wege führen nach Rom, für welchen Weg man entscheidet, hängt doch von vielen Faktoren ab.
Leute don't feed the troll. Es fällt auf, dass hier seit kurzem ein paar Pascal-Anhänger unterwegs sind und mit ihrer "wenn du nicht für uns bist, bist du gegen uns"-Attitüde in mehreren Threads provozieren. Wahrscheinlich steckt da nur eine einzige Person dahinter. Nutzt Delphi/Pascal/Swift und seid glücklich, aber nehmt es Leuten nicht übel wenn sie sich für eine andere Sprache entscheiden.
Dr. Sommer schrieb: > Aber gut zu wissen > dass Delphi "Von Affen geschrieben" ist und Haarausfall bewirkt! Das mit den Affen ist eine böswillige Unterstellung und entspricht nicht der Wahrheit, aber daß es Haarausfall bewirkt kann als gesichert gelten, bei mir ist mittlerweile oben rum alles blank.
Joggel E. schrieb: > Die moderne > Welt will moderne Sprachen. Wie zB Python, wo ein Blank ueber sein oder > nichtsein entscheidet. Ein Gross-Klein Tipp Fehler und eine neue > Variable wird erzeugt, waehrend ich glaube es waere dieselbe. > Schoene neue Debugwelt. > > Ich mach immer noch alles mit Delphi. Ich habe auf der Arbeit auch schon Delphi programmiert, aber auch C# und VB. Für einen kleinen Konverter nehm ich schon mal Python zur Hand oder Bash... Für µC Basteleien zuhause programmiere ich in C oder C++ habe aber auch schon mit Bascom und Arduino experimentiert. Wenn man mal von dem denken der "besten Programmiersprache" wegkommt und man begreift das das ganze immer Anwendungs und Situationsabhängig ist lebt sichs gleich viel entspannter. Aber manche Leute haben halt recht kleine Teller...
Tek schrieb: > Aber manche Leute haben halt recht kleine Teller... ...aber schönen Teller, der schönsten Teller der Welt. :-)
Joggel E. schrieb: > Ein Gross-Klein Tipp Fehler und eine neue > Variable wird erzeugt Diese Sprache von der Du sprichst heißt Lua und diesen kapitalen Designfehler gibts zum Glück in keiner anderen relevanten Sprache.
:
Bearbeitet durch User
Bernd K. schrieb: > Joggel E. schrieb: >> Ein Gross-Klein Tipp Fehler und eine neue >> Variable wird erzeugt > > Diese Sprache von der Du sprichst heißt Lua und diesen kapitalen > Designfehler gibts zum Glück in keiner anderen relevanten Sprache. Doch, in Javascript. Nicht relevant? Naja, Du nutzt es jeden Tag, so wie jeder andere Internetnutzer.
Bernd K. schrieb: > Joggel E. schrieb: >> Ein Gross-Klein Tipp Fehler und eine neue >> Variable wird erzeugt > > Diese Sprache von der Du sprichst heißt Lua und diesen kapitalen > Designfehler gibts zum Glück in keiner anderen relevanten Sprache. PHP...
Tek schrieb: > Aber manche Leute haben halt recht kleine Teller... Ne, eher viel zu große. Da liegt der Rand dann schon so weit hinterm Horizont, daß sie nicht mehr drüber gucken können.
Bernd K. schrieb: > Bedenkt das! Halte es doch lieber so: rbx schrieb: > Bei manchen Antworten ist es echt schwierig, den Inhalt der Tasse in der > Hand (Wasser, Kaffe) und im Mund zu behalten.. Zum Thema: Ich finde Lazarus/Objektpascal super. C auch. Je nachdem was ich programmieren will. Yalu X. schrieb: > Also wenn mich mein Arbeitgeber vor die Wahl stellen würde, entweder > einen Object-Pascal- oder einen Cobol-Kurs zu besuchen, würde ich mich, > ohne lange nachzudenken, für letzteren entscheiden. Einen Cobol Kurs durfte ich mir auch mal antun. Da war mir definitiv zu viel Geschwafel. Überlege Dir das gut.
Tany schrieb: > Eine kleine Hilfe für dich: > http://vschart.de/vergleich/delphi-programming-language/vs/c-plus-plus Leute, laßt mal stecken. Besagte Seite ist nicht wirklich ernstzunehmen. Und nochwas: Es war schon immer völliger Murks, eine Entwicklungsumgebung (Delphi, Lazarus) mit einer Programmiersprache (C++) vergleichen zu wollen. Das Umgekehrte wäre QT mit Objectpascal zu vergleichen. Eben immer Äpfel mit Birnen. Ein richtiger Vergleich wäre zwischen C++ und Objectpascal. Oder zwischen den diversen Component-Libs von Delphi, Lazarus, QT, C#, Java usw. mh schrieb: > Was ist mit... Garnix. Vesuche doch mal, jemanden aus eurer Werbeabteilung für einen Vergleich zwischen deinem Auto und dem Mobiltelefon deiner Frau anzustellen: RÄDER: ja nein VIERECKIG: nein ja GLAS VORN: ja ja DISPLAY: ja ja usw. W.S.
Nop schrieb: > Doch, in Javascript. Nicht relevant? Naja, Du nutzt es jeden Tag, so wie > jeder andere Internetnutzer. Nein, wenn ich mich recht erinnere bekomme ich bei JS einen Fehler wenn ich auf eine Variable zugreifen will die nicht existiert. Nur bei Lua verschweigt er das und tut so als wäre nichts, so einen Krampf hab ich bis jetzt noch nirgendwo anders beobachtet.
Yalu X. schrieb: > Also wenn mich mein Arbeitgeber vor die Wahl stellen würde, entweder > einen Object-Pascal- oder einen Cobol-Kurs zu besuchen, würde ich mich, > ohne lange nachzudenken,... ..dich für eine Sorte Dienstreise-Tourismus entscheiden, wo du vornehmlich mit BWL- und reinen Geld-Leuten zusammenkommst und dich das Ganze so wenig wie möglich angeht. Hauptsache, das Tagungshotel bietet ein nettes Ambiente. Aber deine Chefs haben's bislang nicht getan. Kein Wunder, gelle? W.S.
Bernd K. schrieb: > Nur bei Lua > verschweigt er das und tut so als wäre nichts, so einen Krampf hab ich > bis jetzt noch nirgendwo anders beobachtet. Das stimmt so nicht! Zumindest bei der aktuellen Version 5.3 kommt es zu einem Fehler/Abbruch wenn man versucht eine Variable weiterzuverarbeiten die nil (=NULL) ist. Und eine nicht vorhandene/deklarierte Variable ist nil...
bitte lasst den Faden hier jetzt nicht völlig ins absurde laufen U d niemand will den C Fans das Programmieren von C madig machen! Eigentlich brauchen die hier nicht mal mitlesen, da es eher darum geht zu zeigen wie aktiv PAscal noch ist..nichts weiter..ich werde meine Liste hier weiter fortsetzten, wenn immer ich mal wieder auf ein bekanntes Pascal Programm stoße. Gerade unter Linux scheint mir sogar sehr viel mehr mit Pascal geschrieben zu werden als ich unsprünglich dachte, das hat selbst mich überrascht
Gegeg J. schrieb: > Noch eins in Pascal/Delphi > Diptrace Weiß eigentlich jemand, warum es von Diptrace keine native Linux-Version (ohne Wine) gibt? Wenn ich das richtig verstanden habe, müsste der Hersteller seinen Quellcode doch nur durch den Linux-FPC jagen, und schon wäre die Linux-Version fertig. Das gleiche gilt für Altium, von dem für Linux leider nur ein Cloud- Client verfügbar ist. Damit hätten die Linux-User Zugriff auf zwei weitere gute EDA-Programme, und die Hersteller könnten mit minimalem Aufwand ihren Kundenkreis noch etwas erweitern. Warum tun sie das nicht einfach? Gerade eine Linux-Version von Altium könnte ich beruflich sehr gut gebrauchen.
Yalu X. schrieb: > Wenn ich das richtig verstanden habe, müsste der Hersteller seinen > Quellcode doch nur durch den Linux-FPC jagen, und schon wäre die > Linux-Version fertig. Aber auch die Bibliotheken und das geht nicht (z.B. die gesamte Grafik von Windows auf Linux übertragen). Es gab ja mit Kylix den Versuch Delphi auf Linux zu bringen, ist aber gescheitert. Es gibt also kein Delphi für Linux.
Guido B. schrieb: > Aber auch die Bibliotheken und das geht nicht (z.B. die gesamte > Grafik von Windows auf Linux übertragen). Ich hatte irgendwie im Hinterkopf, dass Delphi über ein eigenes Framework auf das Win32-API zugreift, und ein dazu API-kompatibles Framework auch in Lazarus implementiert ist, das je nach Plattform wahlweise Win32-API, GTK oder Qt nutzen kann.
Bernd K. schrieb: > Nein, wenn ich mich recht erinnere bekomme ich bei JS einen Fehler wenn > ich auf eine Variable zugreifen will die nicht existiert. Wenn Du einer Variable einen Wert zuweist, aber dabei deren Variablennamen verkehrt schreibst, wird die Variable nicht bloß automatisch neu angelegt anstatt einer Fehlermeldung, was an sich schon für viel Spaß beim Debuggen sorgt - sie wird obendrein als globale Variable angelegt, auch wenn Du das in einer Funktion tust.
Yalu X. schrieb: > Ich hatte irgendwie im Hinterkopf, dass Delphi über ein eigenes > Framework auf das Win32-API zugreift, Vor 20 Jahren war das so, ob das heute noch gilt weiß ich nicht. Yalu X. schrieb: > und ein dazu API-kompatibles > Framework auch in Lazarus implementiert ist, Das ist mir nicht bekannt, vielleicht war ich aber zu blöd das zu finden. Ich habe schon probiert Anwendungen für beide Systeme zu schreiben. Das macht aber keinen Spaß, das geht schon mit den Fonts los, die einem das Layout zerhauen (keine MS-Fonts unter Linux) und wenn noch eine Schnittstelle ins Spiel kommt, muss man eh getrennt für beide Syteme entwickeln. Was sehr gut geht sind Konsolenanwendungen mit FPC, die kann ich unter Linux und Wine auch sehr einfach für Windows kompilieren. Mit Kylix damals war es schön, aber halt nur sehr kurz.
:
Bearbeitet durch User
Yalu X. schrieb: > Ich hatte irgendwie im Hinterkopf, dass Delphi über ein eigenes > Framework auf das Win32-API zugreift, und ein dazu API-kompatibles > Framework auch in Lazarus implementiert ist, das je nach Plattform > wahlweise Win32-API, GTK oder Qt nutzen kann. Ein CAD-Programm wie Altium benutzt aus Performancegruenden vermutlich nicht die Windows-Standard-Komponenten zum Zeichnen der Oberflaeche. Auch wird in Delphiprogrammen gerne mal 'windowsnah' programmiert mit Win-API-Hacks, abfangen von Messages usw. In Lazarus gibt es in der Hinsicht eine bessere Abstrahierung und dadurch eine gute Portierbarkeit. Einige Funktionalitaeten sind aber nicht implementiert und muessen auch in Lazarus plattformabhaengig ueber direkte API-Aufrufe geloest werden. D.h. ein Programm, das nicht von Anfang an auf Lazarus setzt, ist schwerer auf Linux zu portieren.
Guido B. schrieb: > Was sehr gut geht sind Konsolenanwendungen mit FPC, die kann > ich unter Linux und Wine auch sehr einfach für Windows kompilieren. Portable Konsolenanwendungen sind aber nun wirklich kein herausragendes Merkmal. Das geht in so ziemlich jeder Sprache.
Guido B. schrieb: > Ich habe schon probiert Anwendungen für beide Systeme zu schreiben. > Das macht aber keinen Spaß, das geht schon mit den Fonts los, die > einem das Layout zerhauen (keine MS-Fonts unter Linux) und wenn > noch eine Schnittstelle ins Spiel kommt, muss man eh getrennt für > beide Syteme entwickeln. Klar ist es ein zusaetzlicher Aufwand, aber dafuer, dass man tatsaechlich beide Systeme (Windows/Linux) nativ abdecken kann, ist es genial einfach. Von welchen Schnittstellen sprichst du? Die Serielle und Ethernet (TCP, UDP...) sind in Multiplattformbibliotheken verfuegbar, funktioniert dann in der Anwendung genau gleich. Eigentlich ist Lazarus/Freepascal gerade fuer kleinere Tools im Elektronikbereich praedestiniert, z.B. als Diagnose-GUI fuer ein Geraet. Anpassungen fuer Linux oder Windows sind dann eigentlich nur in der Darstellung noetig, also die angesprochenen Fonts, breite von Scrollbars usw. Achso, und das Dateisystem ist nat. unterschiedlich (Slash/Backslash). Das sind aber beides Kleinigkeiten.
Guido B. schrieb: > Das macht aber keinen Spaß, das geht schon mit den Fonts los, die > einem das Layout zerhauen (keine MS-Fonts unter Linux) Seit Win 7 hat man selbst mit Delphis Defaultfont (MS Sans Serif) massive Probleme unter Probleme, weil die Skalierung nicht funktioniert. Ich benutze seit dem Tahoma als Font, womit es keine Probleme gibt, egal ob unter Win, Linux oder Mac. Schwierig wird es halt bei systemnahen Sachen. Mit einem vernünftigen Konzept bekommt man aber auch das in den Griff.
TriHexagon schrieb: > Nutzt Delphi/Pascal/Swift und seid glücklich, aber nehmt es Leuten nicht > übel wenn sie sich für eine andere Sprache entscheiden. Ach, darf man hier nur C und C++ diskutieren? Du musst jetzt sehr tapfer sein: das C in µC-Forum steht nicht für die Programmiersprache.
Jajaja, es geht schon, ich schrieb ja auch nur, dass es keinen Spaß macht. ;-) Der Zusatzaufwand ist schon groß, kein Wunder, dass Borland sein Projekt Kylix wieder eingestellt hat. Mit Schnittstellen meine ich schon serielle und Dateien. Klar gibt es da Wrapper, aber wenn es ans Eingemachte geht (sind schon 14 Bytes eingetroffen, melde sofort wenn ein Byte kommt) kann man die selten nutzen. Und klar, dass Konsolenanwendungen auch unter anderen Sprachen sehr gut Crossentwickelt werden können, insbesondere mit den interpretierten. Ich wollte nur erwähnen, dass mit FPC und Wine auch Crosscompiling ohne Änderungen am Quellcode funktioniert.
:
Bearbeitet durch User
Guido B. schrieb: > z.B. die gesamte > Grafik von Windows auf Linux übertragen Wenn man das von vornherein richtig programmiert hat, nimmt man für die Bedienelemente diejenigen, die die Gui zur Verfügung stellt, und dann ist es (fast) egal, ob das Win oder Linux und WinApi oder Qt oder GTK ist. Und Schematic und Board zeichnet man in ein Paint-Element, da ist es dann auch wieder egal, ob das von WinAPI oder Ot oder GTK. Wenn man allerdings versucht, die gesamte Gui selbst zu zeichnen - ja dann könnte das schiefgehen. Guido B. schrieb: > Das macht aber keinen Spaß, das geht schon mit den Fonts los, die > einem das Layout zerhauen (keine MS-Fonts unter Linux) Natürlich gibt es MS-Fonts für Linux, wenn man das will. Allerdings sollte man für die Gui eines Programmes auf die als default eingestellten Fonts zurückgreifen. Was ist, wenn jemand ein besonders kontrastreiches Bildschirmschema mit großer Schrift eingestellt hat, weil er ne dicke Brille braucht? Oder wenn MS in der nächsten Version wieder andere Lieblingsschriften für den Desktop hat? Und ja, GTK unter Linux sieht scheisse aus, völlig unabhängig ob das in C oder Pascal genutzt wird. Deswegen versucht man auch nicht, Elemente absolut zu positionieren, sondern relativ zueinander, und dann wachsen die zum Beispiel bei größerer Schrift oder fetten Elemente mit dicken Rand mit. > noch eine Schnittstelle ins Spiel kommt, muss man eh getrennt für > beide Syteme entwickeln. Häh? Meine Programme laufen sowohl unter Windows als auch unter Linux mit dem exakt gleichen Code für RS232 oder TCP/IP, Codeschalter entscheiden ob die RS232 "COM" oder "ttyS0", "ttyUSB0" heisst. Einzig die GPIOs des Raspi finde ich unter Windows auf dem PC leider nicht. Maxe schrieb: > Anpassungen fuer Linux oder Windows sind dann eigentlich nur in der > Darstellung noetig, also die angesprochenen Fonts, breite von Scrollbars Auch das überlasse ich der Api - oder frage die entsprechenden Werte ab. Das muss man aber auch unter Windows only, schon die Umschaltung von Aero in Normal oder gar Klassik unter Windows 7 sorgt für unterschiedliche Fenster, Menu, Toolbarmaße. Und von 7 auf 10 ist es dann wieder anders. > usw. Achso, und das Dateisystem ist nat. unterschiedlich > (Slash/Backslash). PathDelim ist dein Freund.
Guido B. schrieb: > Der Zusatzaufwand ist schon groß, kein Wunder, dass Borland sein > Projekt Kylix wieder eingestellt hat. Der Zusatzaufwand in den Bibliotheken (z.B. LCL) ist gross, aber nicht fuer den Anwendungsprogrammierer. > Mit Schnittstellen meine ich schon serielle und Dateien. Klar gibt > es da Wrapper, aber wenn es ans Eingemachte geht (sind schon 14 > Bytes eingetroffen, melde sofort wenn ein Byte kommt) kann man > die selten nutzen. Also Synaser und LazSerial sind die Standardbibliotheken fuer die Serielle (letztere basiert auf ersterer) und natuerlich kann man da einzelne Bytes mit sofortiger* Rueckmeldung verarbeiten. Und das nicht nur auf x86 Win/Linux sondern auch auf ARM-Linux, also dem Raspberry z.B. Dateinamen... klar, aber das liegt halt am OS, da kann man nichts machen. Kann das sein, dass du dich noch nicht so lange mit Lazarus beschaeftigt hast? Einfache GUI-Programme gehen doch so schnell, dass man Konsolenanwendungen eigentlich nur noch macht, wenn man die Funktionalitaet explizit braucht. *was das BS eben zulaesst.
Maxe schrieb: > Achso, und das Dateisystem ist nat. unterschiedlich (Slash/Backslash). Slash geht auch unter Windows – mindestens seit MS-DOS 3.x. Muss man also nicht unbedingt unterscheiden.
Maxe schrieb: > Also Synaser und LazSerial sind die Standardbibliotheken fuer die > Serielle (letztere basiert auf ersterer) und natuerlich kann man da > einzelne Bytes mit sofortiger* Rueckmeldung verarbeiten. Ja schon, aber wann kommt die Rückmeldung (unterschiedliche Behandlung des FIFO?). Maxe schrieb: > klar, aber das liegt halt am OS, da kann man nichts > machen. Eben! Maxe schrieb: > Kann das sein, dass du dich noch nicht so lange mit Lazarus beschaeftigt > hast? Seit ich Kylix in die Tonne getreten habe, den rest erledigt Google. :-)
Guido B. schrieb: > den rest erledigt > Google Genau so siehts aus: Ein Google-Ekschbärde. Guido B. schrieb: > aber wann kommt die Rückmeldung (unterschiedliche > Behandlung des FIFO?) Ich polle das mit einem Timer. Prinzipiell bekommt man unter Linux schneller eine Rückmeldung, weil man mit 1msec Zeitslots arbeiten kann, Windows hat nur 10msec oder so. Praktisch ist das aber unsinnig, wenn das OS dein Programm jederzeit mehrere 100msec zurückstellen kann. Und wenn der USB-seriell-Wandler eh undefiniert Zeitverzögerungen reinbringt. Da reichen Timer-Abfragen alle 25 bis 100msec. Echtzeit-Pinwackeln ist eh schon seit Win98 tot, und mit USB-seriell-Wandlern erst recht. Das ist aber völlig egal, ob man das mit C, Pascal oder Basic programmiert.
:
Bearbeitet durch User
Karl K. schrieb: > Ich polle das mit einem Timer. Das ist ja furchtbar ineffizient. Mittels WaitForMultipleObjects (Windows) und epoll (Linux) kann man sich asynchron benachrichtigen lassen wenn Daten vorliegen oder gesendet wurden. Gute Frameworks wie Gtk/Glib haben das so integriert dass man da ähnlich wie GUI-events drauf reagieren kann, in dem das von der Main loop des Framework abgearbeitet und abstrahiert wird. Kann Pascal das etwa nicht?
NA es beginnt damit das es in Delphi und nicht mit Freepascal entwickelt ist...dann sollte es von Anfang an mit der Absicht Programmiet worden sein, portiert zu werden, was ganz sicher auch nicht gemacht wurde..dann wen interessiert Linux? kein Scherz Linux ist noch weit entfernt von einem Massenprodukt..meine Homebankingsoftware wurde auch nie portiert, da die Access als Datenbank nutzen..somit hat sich das mit dem schnellen portieren sowieso erledigt.. Aber mal im Ernst..die paar Frickler und Bastler die auf Linux setzten, wozu sollten man da jetzt den Aufwand treiben? Die, die wirklich damit arbeiten und bereit sind so viel Geld auszugeben werde größteteils Windows nutzen. SIe hätten also erhebliche Kosten für 0,8% mehr Umsatz. Wie in C++ ist es halt auch in Freepascal schlecht, wenn man nicht von Anfang an , mit der Absicht der Porotierung schreibt
Maxe schrieb: > Also Synaser und LazSerial sind die Standardbibliotheken fuer die > Serielle https://sourceforge.net/projects/comport/
Dr. Sommer schrieb: > Das ist ja furchtbar ineffizient Schuld ist nicht immer die Programmiersprache, das weißt du auch? Dr. Sommer schrieb: > Gute Frameworks wie > Gtk/Glib haben das so integriert dass man da ähnlich wie GUI-events > drauf reagieren kann, in dem das von der Main loop des Framework > abgearbeitet und abstrahiert wird. Kann Pascal das etwa nicht? Pascal nicht aber Delphi...oder Lazarus. Wusste ich doch, dass du Delphi nur von den Namen her kennst. :-)
Tany schrieb: > Schuld ist nicht immer die Programmiersprache, das weißt du auch? Ja. Das habe ich auch nicht behauptet. Es wäre die Schuld des Frameworks, wenn es so etwas nicht könnte, was meine Frage war. Tany schrieb: > Pascal nicht aber Delphi...oder Lazarus. Damit wäre die Frage beantwortet. Dann nutzt Karl es einfach nur falsch. Tany schrieb: > Wusste ich doch, dass du Delphi nur von den Namen her kennst. :-) Falsch gewusst. Ich habe tatsächlich mit Borland C++ angefangen und dann ein bisschen mit Delphi gespielt. Dann ist mir Visual C++ über den Weg gelaufen und dann habe ich nicht mehr zurück geblickt...
Dr. Sommer schrieb: > Dann ist mir Visual C++ über den Weg > gelaufen und dann habe ich nicht mehr zurück geblickt... Das hatte ich noch gar nicht auf dem Schirm. Ist es da tatsächlich genauso leicht wie in Lazarus eine mittelschwere GUI-Anwendung nach Linux oder Mac zu portieren indem man einfach auf den Kompilieren-Button klickt? Ich kanns grad nicht im Ubuntu Repository finden, wie installiere ich das?
:
Bearbeitet durch User
Witzbold. Damals hatte ich nur mit Windows-Programmierung zu tun; über ein 56k-Modem eine Linux-CD herunterladen war damals irgendwie nicht so dolle. Die erwähnten IDEs hatte ich aus Buch-CDs aus der Stadtbibliothek. Linux auf dem Familien-PC zu installieren hätte auch lustige Folgen gehabt.
Nun, dann können wir ja schön sehen daß die Meßlatte anhand derer wir das vergleichen in einem vieldimensionalen Raum liegt und Lazarus in einigen Dimensionen die für bestimmte Anwendungen wichtig sind klar vorne liegt.
Yalu X. schrieb: > Wenn ich das richtig verstanden habe, müsste der Hersteller seinen > Quellcode doch nur durch den Linux-FPC jagen, und schon wäre die > Linux-Version fertig. Nö. Das hast du nämlich falsch verstanden. Windows bietet im krassen Gegensatz zu all den verschiedenen Linux-Geschmacksrichtungen nämlich eine verläßliche Infrastruktur mit wohldefiniertem API für Grafik und UI. Und das ist ausgearbeitet und stabil, so daß man mit der selben Anwendung auf verschiedenen Windows-Versionen arbeiten kann. Und genau das fehlt bei Linux vollständig - da gibt es gefühlte 1000 Varianten und Versiönchen und das nervt ganz erheblich. Linux ist OK für Kommandozeilentools, weil die keine Berührung mit einem grafischen UI haben. Aber für alles, wo das grafische UI essenziell ist, müßte man sich entweder auf nur eine einzige Distribution beschränken und dabei auch nur auf einen einzigen Versionsstand oder man müßte sich mit all dem Zeugs, was da so herumfliegt und sebstverständlich hie und da inkompatibel ist zur nächsten Variante, befassen und wiederum gefühlte 1000 Programmversionen erzeugen. Glaubst du, wer Anwendungen schreibt, macht sowas freiwillig? Nö. Wenn irgendwann Linux mal eine einzige grafische Oberfläche haben sollte, die auch noch so gut ausgearbeitet ist, daß deren API auf 15..20 Jahre voll gültig bleibt und alles bisherige abdeckt (einschließlich DirectX), dann (ja DANN..) sähe das anders aus. Guck dir bloß mal den Werdegang von Lukas' Horizon an. Ich schätze, er hat den Kampf gegen sein OS im Juni aufgegeben. Hätte er Horizon unter Windows und für Windows und mit DirecX geschrieben, dann hätten wir jetzt ein fertiges und benutzbares EDA-Tool mehr gehabt. konjunktiv mal wieder. W.S.
Yalu X. schrieb: > Damit hätten die Linux-User Zugriff auf zwei weitere gute EDA-Programme, > und die Hersteller könnten mit minimalem Aufwand ihren Kundenkreis noch > etwas erweitern. Warum tun sie das nicht einfach? Weil es für einen kommerziellen Anwender weitaus billiger ist, sich einen PC mit Windows drauf zu kaufen. Man kauft in solchem Falle die Hardware+OS nach dem Bedarf der Anwendung - schließlich ist es diese, die den Nutzen für die Firma bringen soll. Der Fußabtreter darunter ist Nebensache. Der Rest der Welt ist nicht so Linux-orientiert wie du selbst. Das ist der entscheidende Punkt. W.S.
W.S. schrieb: > Windows bietet im krassen Gegensatz zu all den verschiedenen > Linux-Geschmacksrichtungen nämlich eine verläßliche Infrastruktur mit > wohldefiniertem API für Grafik und UI. Das ach so verlässliche Win32-API mit seinen Steuerelementen im Windows95-Stil benutzt aber auch keiner mehr. Stattdessen wird z.B. C# + .net mit seinen diversen inkompatiblen Versionen benutzt. W.S. schrieb: > einschließlich DirectX DirectX existiert nur weil Microsoft die zuvor sogar bessere und portable Alternative OpenGL aktiv sabotiert hat, um zu verhindern, dass Spiele portabel werden - nachdem Microsoft zu Beginn sogar daran mitgewirkt hat! W.S. schrieb: > Der Rest der Welt ist nicht so Linux-orientiert wie du selbst. Das ist > der entscheidende Punkt. Schonmal was von Android gehört?
Maxe schrieb: > Ein CAD-Programm wie Altium benutzt aus Performancegruenden vermutlich > nicht die Windows-Standard-Komponenten zum Zeichnen der Oberflaeche. oh doch. Gerade eben das mit dem nötigen Verstand benutzte Windows-API ergibt die Performance. > Auch wird in Delphiprogrammen gerne mal 'windowsnah' programmiert mit > Win-API-Hacks, abfangen von Messages usw. Wie sollte das sonst gehen? Delphi baut direkt auf dem API des OS auf - und dazu gehört eben auch, daß man in die Message-Distribution eingeklinkt wird. Eigentlich kann man das ganz einfach verstehen: Jedes grafische Element mit einem Handle IST eine von Windows verwalteter Prozeß - entweder mit einer eigenen oder einer von Windows abgeleiteten Fensterprozedur (windowproc). Wahrscheinlich sind sich Linuxer garnicht bewußt, wie umfänglich die Multitasking-Verwaltung bei Windows ist und denken, daß das grafische UI bloß ein Aufsatz sei wie bei Linux. Programmiere du mal was für Windows oder WindowsCE mit VC oder EVC, dann weißt du, was du da an Message-Handling selbst und zu Fuß zu tun hast. Sowas wie die VCL nimmt einem diese Arbeit weitgehend ab. Also, das sind keine "Windows-Hacks", sondern das ist ein Teil des Windows-API, das man benutzen muß, um überhaupt Programme mit grafischem UI zu schreiben. W.S.
Dr. Sommer schrieb: > mit seinen Steuerelementen im > Windows95-Stil benutzt aber auch keiner mehr Du hast wie immer rein garnix verstanden. Nicht einmal Android hast du kapiert. Ich sag's dir: Android ist ein eigenes OS und es benutzt Linux nur als LowLevel-Treiber, sozusagen als Fußabtreter. W.S.
W.S. schrieb: > Eigentlich kann man das ganz einfach verstehen: Jedes grafische Element > mit einem Handle IST eine von Windows verwalteter Prozeß Ach, echt? Jeder Button und jedes Eingabefeld hat einen eigenen Prozess? Warum tauchen die dann nicht alle im Task-Manager auf? W.S. schrieb: > oder einer von Windows abgeleiteten Fensterprozedur > (windowproc). Selbst Programme mit mehreren Fenstern (z.B. Gimp) tauchen nur 1x im Task Manager auf, wo sind die anderen Prozesse? W.S. schrieb: > Wahrscheinlich sind sich Linuxer garnicht bewußt, wie umfänglich die > Multitasking-Verwaltung bei Windows ist Auch Linux ist Multitasking-Fähig (und war es auch schon immer, im Gegensatz zu den DOS-Wurzeln und dem Pseudo-Multitasking von Win3.11). W.S. schrieb: > Programmiere du mal was für Windows oder WindowsCE mit VC oder EVC, dann > weißt du, was du da an Message-Handling selbst und zu Fuß zu tun hast. Windows hat halt gemäß dem "The Blob"-Antipattern alles im Kernel. Unter Linux/Unix sind solche Dinge getrennt, und die Message Loop kommt in die Anwendung bzw. das GUI-Framework. Wenn man ein Embedded System oder Server ohne GUI hat lässt man das einfach weg, was problemlos möglich ist weil nicht Teil des Kernels. W.S. schrieb: > Du hast wie immer rein garnix verstanden. Danke für die Blumen. Komisch, dass wenn ich dein Unverständnis aufzeige immer noch Belege mitliefere, du nur Beleidigungen. W.S. schrieb: > Android ist ein > eigenes OS Kann man so sehen. Aber es steckt noch sehr viel Linux drin. W.S. schrieb: > und es benutzt Linux nur als LowLevel-Treiber Treiber, singular? DER Treiber für Prozessor und das gesamte Drumherum? Ein einziger 20 MLoC Treiber? Achso. W.S. schrieb: > sozusagen als > Fußabtreter. Der Fußabtreter ist aber der einzige, der das ganze System erst möglich macht. Es gibt nichts, was an Flexibililtät und Universalität da heran reicht. Wenn man ein OS für einen SoC braucht, ist die Antwort fast immer Linux. Mal eben Windows auf so ein System zu packen ist fast außer Frage...
W.S. schrieb: > Yalu X. schrieb: >> Wenn ich das richtig verstanden habe, müsste der Hersteller seinen >> Quellcode doch nur durch den Linux-FPC jagen, und schon wäre die >> Linux-Version fertig. > > Nö. Dann habe ich mich wohl zu sehr von überbegeisterten Lazarus-Usern beschwatzen lassen, die Lazarus immer wieder als Delphi-kompatible Open-Source-Implementation darstellen, wobei nach deren Aussage diese Kompatibilität insbesondere auch die GUI-Programmierung einschließt. Du sagst jetzt, das stimmt überhaupt nicht. Ok, wenn sogar du das sagst, dann glaube ich das sofort, denn eigentlich hätte ich von dir folgende Antwort erwartet: "Ja, natürlich geht das mit minimalstem Aufwand. Wenn sich die Hersteller von Altium um Diptrace dennoch gegen eine Linux-Version ihrer Software entschieden haben, hat das keine technischen, sondern ausschließlich politische Gründe." Ich verstehe es ja, dass ein Delphi-Programm nicht mehr portierbar sein kann, wenn es Windows-spezifische, nicht in Object-Pascal geschriebene Bibliotheken oder systemnahe Funktionen nutzt. So würde ich bspw. nicht erwarten, dass ein Festplattendefragmentierprogramm ohne weiteres von Windows nach Linux portiert werden kann. Aber wozu sollte eine reine Anwendersoftware wie Diptrace oder Altium, die nur aus GUI, Algorithmen und etwas Networking besteht, solche Windows-spezifischen Bibliotheken benutzen? Ein GUI-Framework bringt Delphi selber mit (m.W. heißt es dort VCL), die Algorithmen sollten sich vollständig in Object-Pascal (ohne externe C++-Module) implementieren lassen, und für die Netzwerkgeschichten gibt es ebenfalls Delphi-Module. Ich bin bisher davon ausgegangen, dass in Lazarus/FPC nicht nur die Sprache selbst, sondern auch alle wichtigen Standardmodule von Delphi (dazu gehört insbesondere auch das GUI-Framework) in kompatibler Weise implementiert sind. Sollte dies nicht der Fall sein, dann beschränkt sich die Kompatibilität zu Delphi auf die Programmiersprache. Das ist natürlich besser als überhaupt keine Kompatibilität, aber auch nichts Besonderes, denn Kompatibilität auf Sprachebene gibt es schon seit Algol und Fortran. Programmiersprachen, die sowohl für Windows als auch für Linux verfügbar sind, gibt es wie Sand am Meer. Also irgendwie verstehe ich die riesige Begeisterung der Lazarus-Nutzer für ihr Entwicklungssystem nicht, wenn die wenigen Vorteile, die dieses aus der Sicht einiger Nutzer bietet, durch andere wieder in Abrede gestellt werden. Aber vielleicht muss ich das auch gar nicht verstehen.
STK500-Besitzer schrieb: > Bei EADS geht es ja auch um sicherheitsrelevante Software. Die ersetzt > man nicht einfach mal so. oder da hängen viele rum, die sich nicht umstellen können ich kenne da auch eine firma, die z.B. von dot.net und C# noch nichts gehört hat und externe holen muss, wenn sie den code wieterbearbeiten wollen, den ein praktikant veranstaltet hat
Yalu X. schrieb: > Aber wozu sollte eine reine Anwendersoftware wie Diptrace oder Altium, > die nur aus GUI, Algorithmen und etwas Networking besteht, solche > Windows-spezifischen Bibliotheken benutzen? Weil sie wahrscheinlich DirectX benutzen oder irgendwelche Schweinereien direkt in der Windows-API machen anstatt sauber über die Abstraktionen von LCL und FCL zu gehen. Wenn ich mir in der LCL einen Canvas besorge und da drauf male oder Bitmap-Operationen mache geht das hinterher ohne Änderung auf jedem System, wenn ich mir aber direkt über die Windows-API einen Devicecontext besorge um genau das selbe zu tun dann hab ich jegliche spätere Portierbarkeit schon im Ansatz in die Tonne getreten.
:
Bearbeitet durch User
Bernd K. schrieb: > Wenn ich mir in der LCL einen Canvas besorge und da drauf male oder > Bitmap-Operationen mache geht das hinterher ohne Änderung auf jedem > System, wenn ich mir aber direkt über die Windows-API einen > Devicecontext besorge um genau das selbe zu tun dann hab ich jegliche > spätere Portierbarkeit schon im Ansatz in die Tonne getreten. Aber warum sollte jemand so etwas tun? Da verlässt jemand freiwillig den Komfortlevel der LCL/VCL (für den Lazarus/Delphi ja so berühmt ist), um sich stattdessen mit dem antiquierten C-API von Windows herumzuquälen? Das wäre ja vergleichbar mit einem Qt-Programmierer unter Linux, der immer wieder mal direkt auf die X11-Bibliotheken zugreift, nur, um sich das Leben unnötig schwer zu machen. Ich gehe mal davon aus, dass 99% der Qt-Programmierer die X11-APIs nicht einmal kennen.
@Autor: Yalu X. (yalu) (Moderator) noch mal für Dich Linux interessiert im Kommerziellen Umfeld niemanden ernsthaft! Und JA man könnte es zu Linux portieren, aber nicht mit einem Klick..warum wurde oft genug gesagt. Selbst wenn die Portierung nur wenige tausend Euro kosten würde...wozu?!?! Linux ist ein feuchter Pups in Desktop Segment. Akzeptier das doch einfach. Delphi ist auch nicht so verbreitet wie C..warum können wir das zugeben und akzeptieren aber die Linux User verstehen nicht das sie eine absolute Minderheit sind?! Stell doch diese Frage einfach mal ins Diptrace Forum wenn sie dich so brennend interessiert, als deshalb den Faden hier aus dem Ruder laufen zu lassen
Yalu X. schrieb: > Aber warum sollte jemand so etwas tun? Da verlässt jemand freiwillig den > Komfortlevel der LCL/VCL (für den Lazarus/Delphi ja so berühmt ist), um > sich stattdessen mit dem antiquierten C-API von Windows herumzuquälen? DirectX wurde ja schon genannt, dahingehend abstrahiert weder die VCL (Delphi) noch die LCL (Lazarus). Wenn man heute mit Lazarus starten wuerde, wuerde man OpenGL fuer das CAD-Rendering nehmen, dafuer gibt es plattformuebergreifende Bibliotheken unter Lazarus. Die LCL kann halt auch nur in den Funktionalitaeten VCL-kompatibel sein, die es in der VCL gibt. Da es in der VCL aber nur die Win-API gab, hat man auch haeufiger direkt auf API-Calls zurueckgegriffen.
Dr. Sommer schrieb: > Das ist ja furchtbar ineffizient. Mittels WaitForMultipleObjects... Klar, du Schwätzer kennst natürlich mein Programm und kannst beurteilen, ob das ineffizient ist. Der Timer läuft natürlich als eigener Thread im Hintergrund, so dass Daten unabhängig von Aktionen der Gui abgefragt werden. Der Timer stößt auch zyklisch Datenabfragen an, löst zyklisches Datenspeichern aus, wäre also sowieso vorhanden. Und er ist allemal besser, als bei einem Problem am Uart, z.B. wenn der aufgrund von Störungen mit Fakedaten geflutet wird das Programm abstürzen zu lassen, weil dein WaitForMultipleObjects ständig neue Daten meldet.
Karl K. schrieb: > Der Timer läuft natürlich als eigener Thread im Hintergrund, so dass > Daten unabhängig von Aktionen der Gui abgefragt werden. Das macht nichts besser. Karl K. schrieb: > äre > also sowieso vorhanden. Das wäre der einzige Grund den man gelten lassen könnte. Und das muss alle 1ms laufen? Karl K. schrieb: > das Programm > abstürzen zu lassen, weil dein WaitForMultipleObjects ständig neue Daten > meldet. Wieso sollte das Programm davon abstürzen? Das stürzt davon genauso wenig ab wie wenn du per Timer die volle Datenrate des UART ausnutzt. Wie mies sind deine Programme, dass sie von popeligen UART-Datenraten überlastet werden können?
W.S. schrieb: > Aber für alles, wo das grafische UI essenziell ist, müßte man sich > entweder auf nur eine einzige Distribution beschränken und dabei auch > nur auf einen einzigen Versionsstand Kannst du einen Scheiss erzählen... Ich kompiliere meine Programme aus Windows heraus für Linux PC oder Linux ARM (Raspberry), und da wird nur im Compiler die Zielplattform ausgewählt. Und das Terminal verwendet unter Windows die gleichen Gadgets wie unter Linux, die sehen etwas anders aus, weil einmal WinApi und einmal GTK. Wenn ich sie gleich aussehen lassen wöllte, könnte ich Qt nutzen. Aber die Gadgets werden unter Windows und unter Linux exakt gleich angesprochen, haben die gleichen Funktionen, liefern die gleichen Ergebnisse zurück. Dank LCL. Das funktioniert unter Linux unter verschiedenen Distries, das funktioniert auch unter einer Qt-basierten Distri wie Opensuse, da wird halt ein GTK Frameset geladen. Gimp z.B. macht das genau so. W.S. schrieb: > sondern das ist ein Teil des > Windows-API, das man benutzen muß, um überhaupt Programme mit > grafischem UI zu schreiben. Kannst du einen Scheiss erzählen. Schon PureBasic bietet für die meisten Api-Funktionen Wrapperfunktionen, damit es mit Linux portabel ist. Wenn man direkt an die Api muss, dann für einige Gimmicks, die nicht implementiert sind. Das braucht man aber äußerst selten. Ich hab das unter Purebasic mal gemacht, um Button-Hints mit umgebrochenen Text zu bekommen. Das hat dann in der nächsten Windows-Version schon nicht mehr so funktioniert. Unter Freepascal habe ich noch nie direkt an der Api rummachen müssen. Yalu X. schrieb: > Aber wozu sollte eine reine Anwendersoftware wie Diptrace oder Altium, > die nur aus GUI, Algorithmen und etwas Networking besteht, solche > Windows-spezifischen Bibliotheken benutzen? Weil sie vom Kumpel von W.S. programmiert wurde, der glaubt er muss alles Api-nah machen, weil das cool ist? Nein, technisch gibt es eigentlich keinen Grund, warum das nicht unaufwändig portierbar sein sollte. Praktisch hat es eventuell - Spekulation - den Grund, dass man am Anfang mit WinApi-spezifischen Funktionen rumgemacht hat, aus denen man jetzt nicht mehr so einfach rauskommt. Oder weil man halt einfach keine Lust auf eine Portierung hat. > Ich bin bisher davon ausgegangen, dass in Lazarus/FPC nicht nur die > Sprache selbst, sondern auch alle wichtigen Standardmodule von Delphi > (dazu gehört insbesondere auch das GUI-Framework) in kompatibler Weise > implementiert sind. Mangels Erfahrung mit Delphi kann ich nur aus diversen Suchen berichten, wenn ich eine Funktionalität benötigt habe: Da findet man oft eine Lösung für Delphi, und die läßt sich nahezu 1:1 übertragen. Für einige Funktionen bietet Laz/FPC inzwischen bessere Lösungen, und die alte Delphi-Funktion wurde nur aus Kombatibilitätsgründen übernommen.
Gegeg J. schrieb: > @Autor: Yalu X. (yalu) (Moderator) > noch mal für Dich > Linux interessiert im Kommerziellen Umfeld niemanden ernsthaft! > Und JA man könnte es zu Linux portieren, aber nicht mit einem > Klick..warum wurde oft genug gesagt. > Selbst wenn die Portierung nur wenige tausend Euro kosten > würde...wozu?!?! Das Geld wäre schon mit einer Handvoll verkaufter Lizenzen wieder drin, und danach würde mit der Linux-Version Gewinn gemacht werden. Bei der ersten Windows-Version hat es sicher sehr viel länger gedauert, bis die Entwicklungskosten wieder eingespielt waren. Aber ich habe ja jetzt gelernt, dass eine Portierung sehr viel teurer als wenige tausend Euro kosten würde, und endlich konnte das auch jemand stichhaltig begründen: Maxe schrieb: > Yalu X. schrieb: >> Aber warum sollte jemand so etwas tun? Da verlässt jemand freiwillig den >> Komfortlevel der LCL/VCL (für den Lazarus/Delphi ja so berühmt ist), um >> sich stattdessen mit dem antiquierten C-API von Windows herumzuquälen? > DirectX wurde ja schon genannt, dahingehend abstrahiert weder die VCL > (Delphi) noch die LCL (Lazarus). Wenn man heute mit Lazarus starten > wuerde, wuerde man OpenGL fuer das CAD-Rendering nehmen, dafuer gibt es > plattformuebergreifende Bibliotheken unter Lazarus. > > Die LCL kann halt auch nur in den Funktionalitaeten VCL-kompatibel sein, > die es in der VCL gibt. Da es in der VCL aber nur die Win-API gab, hat > man auch haeufiger direkt auf API-Calls zurueckgegriffen. Danke für die technisch fundierten Informationen. Jetzt habe auch ich verstanden, warum das mit der Portierung nicht so einfach ist.
Yalu X. schrieb: > Aber warum sollte jemand so etwas tun? Ich hatte vor ein paar Monaten einen ähnlichen Fall hier: Ein Kollege der sein Leben lang nur Delphi auf Windows gemacht hatte hat nun in einer Lazarus-Anwendung die Windows unit benutzt um irgendwelche Keycodes oder WM_Irgendwas Konstanten für Window-Messages) zu benutzen um Window-Messages abzufangen. Er hats halt unter Lazarus so gemacht wie er es unter Delphi schon immer gemacht hatte und natürlich ging das auch problemlos denn auf der jeweiligen Plattform sind natürlich die nativen APIs ebenfalls vorhanden. Erst als wir es auf Linux kompilieren wollten fiel das auf denn da gibts kein Windows. Das war in dem Fall kein Beinbruch denn man kann den ganzen Kram mit den Window Messages auch portabel über die LCL machen und die Konstanten heißen dann halt nicht WM_xxx sondern haben andere Prefixe und funktionieren sonst aber sehr ähnlich (weil alte Windows-Delphianer die Zielgruppe sind) und in 2 Minuten war das gefixt und die Abhängigkeit von Windows entfernt. Aber man kann sich auch so tief in Windows eingraben daß man nicht mehr ohne weiteres rauskommt und Leute die ihr Leben lang nur Windows gemacht haben ist es oft überhaupt nicht bewußt daß das Lazarus/FPC-Ökosystem für viele der Windows-APIs Alternativen bereistellt die oftmals ähnlich, manchmal prinzipbedingt aber auch komplett anders sind und die man dann auch benutzen sollte. Es ist generell einfacher wenn man die Anwendung auf Linux entwickelt und dann nach Windows portiert da die Nicht-Windows-Versionen allesamt gar nicht erst die Windows APIs bereitstellen die dort nur existieren um alten Windows-Code aus Borland-Zeiten noch am Leben zu erhalten. So kommt man gar nicht erst in Versuchung schnell mal ein Windows-API direkt zu benutzen. Ausnahmen sind Sachen für die es (noch) keine Abstraktion gibt oder die eigentliche Implementierung der Abstraktion selbst, da muss man halt mit bedingter Kompilierung mal direkt auf dieses, mal auf jenes API zugreifen, aber das kann man sauber vom Rest seiner Anwendung trennen und jemand der solche Abstraktionsschichten entwirft kennt die Fallstricke besser als der der sie nur benutzt. Alles in allem ist die LCL ein Meisterwerk an Cross-Plattform Abstraktion mit einem sehr hohen Anspruch den es auch erfüllt und das in einer ganz hohen Liga spielt.
:
Bearbeitet durch User
Gegeg J. schrieb: > Linux interessiert im Kommerziellen Umfeld niemanden ernsthaft! Wenn $KUNDE nachfragt, $KUNDE2 auch, …, $KUNDE<N>, irgendwann schon. Scheint inzwischen durchaus auch bei Altium schon langsam angekommen sein, wurde gemunkelt. Da werden wohl einfach mal „historisch gewachsen“ genügend Altlasten drin sein, die die eigentlich vorhandene Portabilität aushebeln, und daher die Portierung dann eben doch nicht so einfach machen.
Bernd K. schrieb: > Ich hatte vor ein paar Monaten einen ähnlichen Fall hier: > ... Ich kann nicht genau sagen, warum, aber irgendwie erscheinen mir deine Beiträge (insbesondere dein letzter) sehr viel besser als bspw. die von W.S. geeignet zu sein, einem Skeptiker wie mir die positiven Seiten von Lazarus/FPC nahezubringen, und das, obwohl du nicht einmal aktiv die Werbetrommel dafür gerührt hast. Ganz unter uns (hoffentlich liest W.S. nicht mit ;-)): Ich habe FPC längst auf allen meinen Rechnern installiert (auf einem davon sogar den kompletten Lazarus). Ich glaube zwar nicht, dass ich damit zukünftig größere Projekte realisieren werde (dazu fehlt mir einfach die Zeit für eine gründliche Einarbeitung, und es gibt für mich noch ein paar Dinge mit höherer Priorität zu lernen), aber so übel wie direkt nach den ersten (und danach regelmäßig wiederholten) Missionierungsversuchen einiger Unverbesserlicher hier im Forum finde ich es inzwischen gar nicht mehr.
W.S. schrieb: > Wahrscheinlich sind sich Linuxer garnicht bewußt, wie > umfänglich die Multitasking-Verwaltung bei Windows ist > und denken, daß das grafische UI bloß ein Aufsatz sei > wie bei Linux. Du solltest Politiker werden. Im Erzeugen alternativer Fakten bist Du jedenfalls unübertroffen. Mal eben einen zentralen Kritikpunkt in etwas "wahrscheinlich gar nicht bewußtes" umzudeuten, das hat schon was. Respekt.
W.S. schrieb: > Glaubst du, wer Anwendungen schreibt, macht sowas > freiwillig? Selbstverständlich. Was denn sonst? Oder hast Du schonmal von einer Blauhelm-Mission mit robustem Mandat zur Befreiung der unter unmenschlichen Bedingungen geknechteten und gefolterten OpenGL-Programmierer gehört? Solange für die jungen Bubis die Aussage "...sieht etwas altbacken aus..." ein valides Argument ist, das Framework zu wechseln, soll sich bitte niemand über die damit verpulverte Anstrengung beschweren. > Guck dir bloß mal den Werdegang von Lukas' Horizon an. ??? Gibts da neue Entwicklungen in unerwartete Richtung? (Also ich meine FAKTEN, so diese klassischen altbackenen Fakten -- keine "virtuelle Realität".) > Ich schätze, er hat den Kampf gegen sein OS im Juni > aufgegeben. Der Arme. Hat nach unendlicher Leidensgeschichte dann letztlich doch den Kampf gegen sein Betriebssystem verloren. R.I.P. > Hätte er Horizon unter Windows und für Windows und mit > DirecX geschrieben, dann hätten wir jetzt ein fertiges > und benutzbares EDA-Tool mehr gehabt. Bei allem Respekt: Schwachsinn. Lukas' Schwäche ist seine Einzelkämpfer-Mentalität.
Jörg W. schrieb: > Gegeg J. schrieb: >> Linux interessiert im Kommerziellen Umfeld niemanden ernsthaft! > > Wenn $KUNDE nachfragt, $KUNDE2 auch, …, $KUNDE<N>, irgendwann schon. > Scheint inzwischen durchaus auch bei Altium schon langsam angekommen > sein, wurde gemunkelt. Angefragt wird viel...ich würde jedenfalls nicht deshalb plötzlich so ein großes Projekt auf Linux portieren und die meisten anderen sicher auch nicht. Das Du das als Linuxer anders siehst ist klar,aber ein Unternehmer wird hier nüchterner vorgehen. Wenn dem so wäre, gäbe es vernünftige Banking Software etc...aber all das gibt es nicht aus guten Grund. Warte noch mal 10 oder 20 Jahre, dann wird das mit Linux sicher intressant
Yalu X. schrieb: > einem Skeptiker wie mir die positiven Seiten von > Lazarus/FPC nahezubringen Vielleicht solltest du langsam auf den Trichter kommen, dass µc net dafür das falsche Forum ist. Hiere wird jeder Thread über Pascal sofort von Sommer und Co gekapert die erklären, warum C so viel besser ist - ohne auch nur einen Schimmer vom aktuellen FPC zu haben. Was erwartest du da...
Karl K. schrieb: > Sommer und Co gekapert die erklären, warum C so viel besser ist Wo habe ich das geschrieben? Meine Frage, wie Meta Programmierung wie in C++ in Pascal geht, blieb aber leider unbeantwortet.
ich hoffe das bleibt sie auch! Karl K. schrieb: > Hiere wird jeder Thread über Pascal sofort > ... gekapert JEP :-(
Gegeg J. schrieb: > Angefragt wird viel...ich würde jedenfalls nicht > deshalb plötzlich so ein großes Projekt auf Linux > portieren und die meisten anderen sicher auch > nicht. Natürlich würdest Du nicht. Der Horizont durchschnittlicher Windows-Nutzer endet am Fensterrahmen; eine Welt außerhalb Windows existiert nicht. Was unter Windows nicht geht, geht gar nicht. Sehr praktisch. Jeder Linux-User dagegen weiss, dass es neben Linux auch noch Windows, MacOS, BSD und noch mehr gibt. Linux-User stellen daher unangenehme Fragen nach Interoperabilität, Vendor-Lock-In und all solchen Dingen. Eine impertinente Bande! Ganz schlecht für's Geschäftemachen!
Gegeg J. schrieb: > ich würde jedenfalls nicht deshalb plötzlich so ein großes Projekt auf > Linux portieren und die meisten anderen sicher auch nicht. Musst du ja auch nicht, willst du sowieso nicht, ist mir völlig klar. Nur: wenn sie die Portierung nicht machen, bekommen sie halt auch kein Geld. Die letzte Version, für die ich dann nach Betteln (was mich schon ank***t) mal eine Demo zugestanden bekommen habe, lief halt im Gegensatz zu der, die wir haben, nichtmal mehr unter VMware – irgendwelcher ActiveX-Kram, Aussage von Altium Designer stand im Widerspruch zur Aussage der Microsoft-Tools. (Damit bestätigt sich indirekt das, was weiter oben über AD vermutet worden ist, dass sie eben an der Abstraktion vorbei programmiert haben.) Irgendwelche Antworten auf die Diskrepanzen gab's vom Altium-Verkäufer auch nicht, nur immer wieder Spam, mich an irgendwelchen Webinars zu beteiligen oder zu Konferenzen zu gehen – was mich allesamt überhaupt nicht interessiert. Wenn sie mir eine lauffähige Linuxversion vorsetzen würden, würde ich die entsprechende Ausgabe für einen Upgrade bei meinem Chef auf die Tagesordnung setzen – ist ja nun nicht gerade wenig. Ich bin mir ziemlich sicher, dass ich da nicht der Einzige bin, das klang auch hier im Forum immer mal wieder an. Solange sie das nicht machen, gibt's halt auch kein Geld, denn die bestehende Version tut alles, was wir brauchen.
Oha..und DU weißt es natürlich besser:-) NA dann auf zu den ganzen Firmen,e erzähl denen von Star Division, Alfbanco etc pp..mal das die auf dem völlig falschen Dampfer sind und nur Du den vollen Durchblick hast.. Aber nun bitte zurück zum Thema...ersparen wir uns diese Müßige Diskussion. Wenn Du denkst in Linux steckt derzeit das große Geld, dann nur zu, es wird dich sicher niemand aufhalten dafür jetzt tolle PRogramme zu schreiben und Du sahnst dann so richtig aber weil Du einer der ersten bist..wieso tust Du es nicht einfach?...so..alles klar? Nun bitte ende dieser sinnfreien Diksussion. Und an Dr.Sommer...wie sagt ihr doch immer so schön in diesem Forum..Ist Dein Google kaputt?! Google es doch einfach, wenn es für dich so wichtig ist
Karl K. schrieb: > Yalu X. schrieb: >> einem Skeptiker wie mir die positiven Seiten von >> Lazarus/FPC nahezubringen > > Vielleicht solltest du langsam auf den Trichter > kommen, dass µc net dafür das falsche Forum ist. Vielleicht solltest Du mal langsam auf den Trichter kommen, dass ein Diskussionsforum (neben den Eingriffen der Zensoren, die wir hier vernachlässigen können) von der Diskussionskultur der Teilnehmer lebt. Wenn Du nicht in der Lage bist, mit Teilnehmern, die eine von Dir unerwünschte Meinung vertreten, konstruktiv umzugehen, dann ist ein Diskussionsforum nicht die richtige Plattform für Dich. > Hiere wird jeder Thread über Pascal sofort von Sommer > und Co gekapert die erklären, warum C so viel besser > ist - ohne auch nur einen Schimmer vom aktuellen FPC > zu haben. Ja und? Dann ENTKRÄFTE doch einfach seine Argumente! Zeige doch mal am Beispiel, wie einfach FreePascal für Mikrocontroller "freestanding" zu verwenden ist! MSP430 würde mich als Zielplattform interessieren.
Jörg W. schrieb: > Solange sie das nicht machen, gibt's halt auch kein Geld, denn die > bestehende Version tut alles, was wir brauchen. siehst Du..sag ich ja..warte einfach noch 10 jahre. Derzeit übersteigt der Aufwand den Nutzen. Das kann in 1ß JAhren anders aussehen, womöglich nutzen dann aber alle Kicad..und dann hätten sie sinnlos zeit verballert,..die haben sicher auch keine Manpower zu verschenken und brauchen ihre derzetigen Kapazitäten schon voll für die Win Version. Wenn sie das mal so eben stemmen könnten, würden sie es sicher tun..oder eher für Apple als für Linux, denn der MArkt für Apple ist sicher noch größer als der von Linux..leider
Jörg W. schrieb: > Solange sie das nicht machen, gibt's halt auch kein > Geld, denn die bestehende Version tut alles, was wir > brauchen. Hmm. Und wie sieht Eure langfristige Lösungsstrategie für das Problem aus? "Beten und Hoffen" ist ja irgendwie... suboptimal, oder?
Gegeg J. schrieb: > eher für Apple als für Linux Soll mir auch recht sein. Dann frage ich meinen Chef nach einem Macbook :) Aber die Portabilitätsprobleme werden ja dabei nicht kleiner. Portabel konzipierte Software kann man halt auf mehr als einer Plattform pflegen, ohne sich in endlosen Aufwand zu stürzen. Dinge wie FPC und Lazarus können dabei ganz sicher hilfreich sein (wenngleich sie keineswegs die einzigen derartigen Tools sind, die das ermöglichen). Unportabel zusammengehackte Programme (ob nun „historisch gewachsen“ oder einfach nur schlampig designt) hingegen kann man nur mit viel Aufwand auf andere Plattformen bringen, und wie sich am Beispiel von Altium Designer sehen lässt, hilft dann eben auch eine bestimmte Programmiersprachen nicht automatisch dagegen. Unportabel konzipierte Programme gibt's natürlich überall, das ist keineswegs eine Eigenheit von Windows …
:
Bearbeitet durch Moderator
Egon D. schrieb: > Zeige doch mal am Beispiel, wie einfach FreePascal für > Mikrocontroller "freestanding" zu verwenden ist! MSP430 > würde mich als Zielplattform interessieren. ?!? Was soll diese sinnfreie Diskussion? Dann verwende doch einfach Assembler oder aufgehübschte Assembler Tools wie C?!? Raffen einige hier nichts mehr? Es geht nicht darum zu beweisen das Freepascal die ultimative Sprache für alles ist..das scheint an einigen hier echt vorbei zu gehen. Wie schon 1000x erwähnt nutzt mal dafür Assembler oder C!!! Könntet ihr vielleicht mal alles lesen als immer nur die letzten 10 Posts?! Das alles wurde schon 100 mal durchgekaut! Es geht darum das PAscal eine schöne Sprache ist und diese Spaß macht und noch sehr aktiv aufgrund ihrer vielen Vorteile in der Industrie eingesetzt wird. In den C Foren, kommen da auch immer die Assembler Programmierern au ihren löchern und sagen wie kacke doch C im Vergleich zu Assembler ist weil es für irgendwelche Bereiche nicht geeignet ist?! In was für eine eingeschränkten kleinen Welt lebt ihr eigentlich?! Niemand sagt das DU zu Pascal kommen sollst, absolut niemand!
Jörg W. schrieb: > hilft dann eben auch eine bestimmte > Programmiersprachen nicht automatisch dagegen. nein, das behauptet ja auch niemand. Probleme gibt es immer und überall. Aber dennoch bleibt es mit FPC gut machbar und die Möglichkeiten bietet es halt. Niemand bestreitet das es auch andere Tools gibt die das können, nicht mal ich;-) Nur behaupte ich das es mit PAscal sogar fast Spaß macht:-) zumindest mir
Gegeg J. schrieb: > Dann verwende doch einfach Assembler oder aufgehübschte Assembler Tools > wie C?!? Aha. Ohne Beleidigungen geht's einfach nicht, oder was soll das? Wenn die Argumente ausgehen, wird das diffamiert, was einem gerade nicht gefällt? > Es geht darum das PAscal eine schöne Sprache ist und diese Spaß macht > und noch sehr aktiv aufgrund ihrer vielen Vorteile in der Industrie > eingesetzt wird. Das alles hat doch sowieso keiner bestritten. (Wenngleich ich mich frage, warum du in diesem Satz ein „noch“ drin hast.)
:
Bearbeitet durch Moderator
Beitrag #6000233 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > > ... > und noch sehr aktiv aufgrund ihrer vielen Vorteile in der Industrie > eingesetzt wird. Und woran mißt man das? Daran, das vermutlich jede größere Firma einen Mitarbeiter hat, der seinem Chef eine Lizenz aus der Kostenstelle leiern konnte. Und warum das so wichtig sein sollte, versteh ich auch nicht. Wer's mag soll's benutzen. Oder wollen wir eine Liste führen, welche Firma schon mal welchen "x"-Compiler runtergeladen hat und was das für die Wichtigkeit der Sprache "x" bedeutet? BTW, manchmal ist der größte Vorteil bei irgendwas zu bleiben, daß man es nicht neu machen muß. ("aufgrund der vielen Vorteile")
wenn ich schreibe das er dann doch einfach Assembler verwenden soll ist das also beleidigend? Nun gut...vielleicht war das mit dem Assembler ja wirklich zu hart von mir rofl Es ist einfach dumm ständig krampfhaft irgendwelche Vergleiche zu suchen. Da einer seine Metaprogrammierungsfrage nicht beantwortet bekommt, kann das vermutlich gerade niemand beantworten weil es schlich noch keiner gebraucht hat und wenn Pascal das nicht hätte!?ß Das ist alles kacke oder was?!? So zu diskutieren ist einfach sinnlos. Und der nächste fragt oder er seine Xikochi Controller damit programmieren kann. Gibt es keinen Pascal Compiler dafür? was dann? ist Pascal kacke?! Merken die die solche Fragen stellen nicht wie sinnlos das ist? Für den Xikochi Controller gibt es übrigens nicht mal einen C Compiler, und nein es gibt diesen Controler auch nicht, aber wenn müsste er in Assembler programmiert werden bis es einen C Compiler dafür gäbe..vielleicht mal..irgendwann..ist C deshalb scheiße?! Ich hoffe es ist klar worauf ich hinaus will..eine sachliche lockere Diskussionsrunde ohne diesen Blödsinn dazwischen
Carl D. schrieb: > Und warum das so wichtig sein sollte, versteh ich auch nicht. es ist gar nicht wichtig...aber es wird von einigen immer wichtig gemacht und der ganzen Faden gekapert ..offenbar ist es manchen sehr wichtig störend einzuwirken Ich versuche nur anderen klar zu machen das Pascal eben nicht so selten ist, wie viele glauben. Und warum ich das tue ,,geht dich eigentlich gar nichts an, bzw muss ich mich nicht rechtfertigen, und dann kommen gleich wieder Schlaumeier die meinen man Missioniert.....aber ich tue einfach weil ich es freiwillig gerne tue! Und die die es nicht interessiert..oben rechts..das kreuz klicken oder welches Symbol bei euch immer zum schließen des FEnsters dient..einfach draufklicken..JETZT..NEIN..sag nichts...einfach draufklicken..na los..es ist nur ein Klick..na..JEtzt aber...
Gegeg J. schrieb: > > Da einer seine Metaprogrammierungsfrage nicht beantwortet bekommt, kann > das vermutlich gerade niemand beantworten weil es schlich noch keiner > gebraucht hat und wenn Pascal das nicht hätte!?ß Das ist alles kacke > oder was?!? So zu diskutieren ist einfach sinnlos. > Das war eine rhetorische Frage von jemand, der nicht rätseln muß, ob P das hat, aber weiß, was er da vermissen würde. Und als Anwort auf die Behauptung, daß das eine ein vollwertiger Ersatz für das andere sei. Schuhe sind ein vollwertiger Ersatz für ein Auto, wenn man sich auf den Aspekt "bringt mich von A nach B" beschränkt.
Gegeg J. schrieb: > Egon D. schrieb: >> Zeige doch mal am Beispiel, wie einfach FreePascal für >> Mikrocontroller "freestanding" zu verwenden ist! MSP430 >> würde mich als Zielplattform interessieren. > > ?!? Was soll diese sinnfreie Diskussion? Warum beteiligst Du Dich an einer Diskussion, deren Sinn Du nicht verstehst? > Dann verwende doch einfach Assembler oder aufgehübschte > Assembler Tools wie C?!? Warum sollte ich denn? Ich suche ja gerade nach einer ALTERNATIVE zu dem semi-portablen Assembergeraffel, dass sich "C" nennt. > Raffen einige hier nichts mehr? Na, na. > Es geht nicht darum zu beweisen das Freepascal die > ultimative Sprache für alles ist.. Natürlich nicht -- denn das ist sowieso Tcl. > das scheint an einigen hier echt vorbei zu gehen. > Wie schon 1000x erwähnt nutzt mal dafür Assembler > oder C!!! Unter welchen Stein bist Du denn hervorgekrochen? Glaubst Du im Ernst, ich lasse mir von irgendeinem Schreihals, der die Unterhose auf dem Kopf trägt, vorschreiben, welche Sprache ich benutzen soll? Wisch' Dir mal den Schaum vom Mund. > Es geht darum das PAscal eine schöne Sprache ist und > diese Spaß macht Nein. Es ging MIR darum, dass Karl über den bösen Dr. Sommer herumgreint, ohne dessen Argumente entkräften zu können. > In was für eine eingeschränkten kleinen Welt lebt ihr > eigentlich?! Niemand sagt das DU zu Pascal kommen > sollst, absolut niemand! Du begreifst nix. Ich verwende FreePascal, aber im Moment deutet vieles darauf hin, dass das eine Sackgasse ist.
Karl K. schrieb: > Yalu X. schrieb: >> einem Skeptiker wie mir die positiven Seiten von >> Lazarus/FPC nahezubringen > > Vielleicht solltest du langsam auf den Trichter kommen, dass µc net > dafür das falsche Forum ist. Hiere wird jeder Thread über Pascal sofort > von Sommer und Co gekapert die erklären, warum C so viel besser ist - > ohne auch nur einen Schimmer vom aktuellen FPC zu haben. Mit den "Unverbesserlichen" meinte ich nicht den Dr. Sommer, sondern ein paar wenige Mitglieder der Object-Pascal-Fraktion, die immer wieder meinen, ein paar weitgehend irrelevante Sprachdetails, in denen sich Object-Pascal ein kleines Bisschen von C/C++ unterscheidet, als die ganz große Errungenschaft herausstellen zu müssen. Wenn diese paar unwichtigen Details wirklich die Highlights von Object-Pascal sind, so dachte ich mir, kann es mit der Sprache ja nicht sehr weit her sein. Ungeschickt betriebene Missionierung geht eben manchmal auch nach hinten los. PS: Was ich auch sehr gerne mag, sind Diskussionsteilnehmer, deren schlagkräftigste Argumente "Blödsinn", "kacke" und "scheiße" lauten :)
Gegeg J. schrieb: > wenn ich schreibe das er dann doch einfach Assembler verwenden soll ist > das also beleidigend? Ja, ist es. Du weißt ganz genau, dass das keine sinnvolle Option ist. Du hättest freundlich schreiben können, dass das einfach mal nicht in das Aufgabenfeld von Freepascal fällt, damit wäre die Sache erledigt. Aber stattdessen etwas zu posten, was unterstellt, dass eine dir nicht genehme Sprache angeblich doch bloß ein besserer Assembler sei, disqualifiziert dich als Diskutanten, und tut dem von dir geliebten Freepascal schlicht keinen Gefallen. Wenn einem mehr als ein Pascal-Liebhaber derart verquer diskutierend ankommt, macht sich sonst schnell selbst bei Unvoreingenommenen so ein unterschwelliges Gefühl breit: "Wenn's dort nur solche Typen gibt, will ich mir das vielleicht doch nicht erst ansehen."
> "kacke" und "scheiße"
ist Hardware, hat hier nichts zu suchen!
wenn Du Freepascal nutzt weiß Du auch das der MSP430 nicht unterstützt wird. Das ist docha ber auch gar nicht der Anspruch von Pascal? Ich finde es schon super, das bereits jetzt so viele Plattformen unterstützt werden..alle wichtigen sind dabei. Apple, Linux, Windows, AVR, ARM und sogar völlige unwichtige Amiga, OS/2 etc Ich finde das klingt mehr als super. Allerdings nutze ich Freepascal nur für Windows und für ARM/AVR nutze ich Mikroe
Jens Jensen schrieb: >> "kacke" und "scheiße" > ist Hardware, hat hier nichts zu suchen! Kann auch Software sein (s. aktueller Wurst- und Milchskandal), aber das muss hier nicht im Detail ausdiskutiert werden :)
Jörg W. schrieb: > angeblich doch bloß ein besserer Assembler sei, > disqualifiziert dich als Diskutanten, ?! Äh....aber genau das ist C! Da ist doch auch nichts schlimmes dran, aber so ist es nun mal. C ist weder ein Hochsprache noch leicht, so steht es sogar in 2 meiner Bücher. Ich komme jetzt nicht auf den kompletten Wortlaut und müsste auch die Bücher suchen, wobei ich glaube ich nur 6 oder 7 habe..aber die Mühe mache ich mir jetzt nicht, weil es im GRunde auch unwichtig ist. JEdenfalls sehe ich an der Aussage nichts schlimmes, da sind einige der PRovokanten fragen gegenüber Pascal eher fragwürdig..die überhaupt erst uzu hitzigen Dikussionen führen..wie di der Makrodings..wenn Pascal das nicht hat..was bedeutet das dann wohl für die große PCB Software? nichts...weil es nur wenige benötigen
Yalu X. schrieb: > hier nicht im Detail ausdiskutiert werden :) und erst nicht von einem Moderator...da Themenfremd, hätte es eher gelöscht werden müssen..auch wenn es zur Auflockerung dienen kann..
Gegeg J. schrieb: > für ARM/AVR nutze ich Mikroe Ist das nicht dieses abgespeckte C mit Pascal-ähnlicher Syntax? Damit bist ja immerhin schon auf dem richtigen Weg. Die C-Syntax lernst du auch noch ;-) Ok, ok, ich werde mich für den Rest des Tages zurückhalten. Versprochen!
Gegeg J. schrieb: > wenn Du Freepascal nutzt weiß Du auch das der > MSP430 nicht unterstützt wird. Ja, sicher weiss ich das. > Das ist docha ber auch gar nicht der Anspruch > von Pascal? Und was ist Deiner Meinung nach der Anspruch von Pascal? N. Wirth wollte jedenfalls eine Lehrsprache für die strukturierte Programmierung schaffen, und das ist ihm ja auch gelungen. Das allein wäre aber HEUTE für niemanden ein Grund, die Sprache noch zu verwenden. Vermarktet wurde Pascal m.o.w. als Universalsprache, und das ist auch der Anspruch, den ich an die Sprache stelle. Den erfüllt sie aber aus einer Summe von Gründen nur schlecht bis gar nicht, und das ist bedauerlich. Eine Sprache primär für GUI-Anwendungen nützt mir nix; dafür verwende ich Tcl/Tk.
Yalu X. schrieb: > Ist das nicht dieses abgespeckte C mit Pascal-ähnlicher > Syntax? Ich verstehe sowieso nicht, warum P2C eingegangen ist und Klämpfl et al einen eigenen Compiler bauen mussten. Assembler als Zwischensprache ist ja auch üblich -- warum dann nicht dasselbe eine Etage höher mit C? Das hätte erstens den Vorteil, dass man jede Maschine in Pascal programmieren könnte, für die es einen C-Compiler gibt, und zweitens gäbe es einen sanften Pfad zur C-Programmierung, weil sich jeder Pascal- Programmierer den C-Zwischencode angucken könnte. Das geht im Übrigen nicht gegen die Leistung von Klämpfl, van Canneyt usw., die ich im außersten Maße bewundere -- ich verstehe einfach die Logik dahinter nicht.
Yalu X. schrieb: > Mit den "Unverbesserlichen" meinte ich nicht den Dr. Sommer Ähm doch, genau dieser Dr. Sommer ist es, der in sämtlichen Pascal-Threads aufschlägt mit "C++ ist aber besser, weil es das und das kann". Drauf geschissen. C++ ist so komplex, dass mir niemand erzählen kann, dass er sämtliche Möglichkeiten die C++ bietet beherrscht. Schon für die einfachsten Algos gibt es immer mehrere Möglichkeiten. Da wird dann irgendein Begriff reingekackt - "Metaprogrammierung". Mit bißchen Googlen hätte er gefunden, dass Freepascal Metaprogrammierung kann. Aber dann hätte er ja nicht hier auf die Kacke hauen können. Ob Metaprogrammierung in Pascal so ist wie in C++? Wayne! Ist doch nicht mein Problem und interessiert mich nicht. Wenn er das wissen will, soll ers selber rausfinden. Oder nee, doch lieber nicht. Solche Schwätzer und Buzzword-Helden sollen mal schön bei ihrem C++ bleiben.
Karl K. schrieb: > Yalu X. schrieb: >> Mit den "Unverbesserlichen" meinte ich nicht >> den Dr. Sommer > > Ähm doch, genau dieser Dr. Sommer ist es, der > in sämtlichen Pascal-Threads aufschlägt mit "C++ > ist aber besser, weil es das und das kann". Ja und? Dies ist ein DISKUSSIONSFORUM! Warum beschwerst Du Dich, wenn es jemand zum DISKUTIEREN nutzt? Wenn Dich seine Einwände ärgern, sehe ich vier legitime Verhaltensweisen für Dich: 1. Du weist nach, dass er Unrecht hat. 2. Du weist nach, dass seine Aussage irrelevant ist, und deshalb keine Rolle spielt, ober er Recht oder Unrecht hat. 3. Du gibst offen zu, dass er Recht hat. 4. Du schweigst. Das, was Du tust -- nämlich Dich ständig über ihn zu beschweren -- ist kindisch.
Der "Anspruch" von Pascal ist es eine einfach gut strukturierte Sprache zu sein, die gut lesbar ist,und leicht zu erlernen und dennoch leistungstark, schnell. Und all dem wird Pascal gerecht. Pascals Anspruch ist es nicht die Sprache für für alls zu sein. Egon D. schrieb: > gäbe es einen sanften > Pfad zur C-Programmierung, weil sich jeder Pascal- > Programmierer den C-Zwischencode angucken könnte. ähm..es geht nicht um den sanften PFad..Pascal ist einfach in einigen bereichen einfacher schöner und parktischer als C und man WILL dort gar nicht mit C arbeiten MÜSSEN. Und was diese Anspielung C ähnlicher Synta soll bei Mikro e ist mir auch ein Rätsel. Wie jede Sprache, entwickelt sich diese weiter. Und Pascal hat praktische dinge von anderen Sprachen übernommen, so wie es andere Spachen auch tun auch C oder Swift..dehalb hat Pascal natürlich udn zum GLÜCK auch einiges von C übernommen, nämlich die Dinge die gut sind! Wo ist da jetzt das PRoblem?! Wieder eine neue Randdsikussion? Auch D hat Dinge von C übernommen, sogar swift etc. na und?
Tina P. schrieb: > Der "Anspruch" von Pascal ist es eine einfach gut > strukturierte Sprache zu sein, die gut lesbar ist, > und leicht zu erlernen und dennoch leistungstark, > schnell. Und all dem wird Pascal gerecht. Pascals > Anspruch ist es nicht die Sprache für für alls zu > sein. Und das weisst Du so genau, weil...? ... Du Pascal geschaffen hast? ... Du vom Pascal-Weltverband als Sprecher gewählt wurdest? ... Du den beliebtesten Pascal-Compiler programmiert hast? > Egon D. schrieb: >> gäbe es einen sanften >> Pfad zur C-Programmierung, weil sich jeder Pascal- >> Programmierer den C-Zwischencode angucken könnte. > > ähm..es geht nicht um den sanften PFad.. In Deinem Schrebergarten vielleicht nicht. > Pascal ist einfach in einigen bereichen einfacher > schöner und parktischer als C und man WILL dort gar > nicht mit C arbeiten MÜSSEN. Richtig -- und trotzdem MUSS man es, weil Pascal nicht immer alles bereitstellt, was man benötigt. Leider.
Umfang und Leistungsfähigkeit von Pascal und C sind gleich. Keine der beiden Sprachen schränkt den Programmierer ein. Keine ist komplizierter oder einfacher. Die Qualität des Outputs hängt von der Qualität des Compilers (und nicht der Sprache) ab. Ein Vorteil liegt bei Pascal. Es hat weniger Stolperfallen als C. Da wurde bei C++ zwar nachgearbeitet, aber dafür gibt es in C++ wieder neue Fallen.
Gegeg J. schrieb: >> angeblich doch bloß ein besserer Assembler sei, >> disqualifiziert dich als Diskutanten, > > ?! Äh....aber genau das ist C! Nein, ist es nicht. Das ist eine Mär von Leuten, die wohl C nicht weiter kennen. Der wesentliche Unterschied ist der Arbeitsaufwand zur Pflege der Software: ich würde ihn auf 1:10 schätzen (C : Assembler). Auch, wenn ich dem falschen Mawin nur ungern recht gebe: im Prinzip können die beiden Sprachen erstmal dasselbe. Die Inkarnation als Freepascal glänzt dafür mit einem umfangreichen „Rundrum“, und solange sie damit ein Quasi-Monopol hat, ist das sicher als de-facto-Standard eine gute Sache. Aber deshalb braucht nun niemand so zu tun, als könnte man in einer Programmiersprache nur unleserlichen Krempel verfassen, während die andere als Stein der Weisen den Code von selbst schön rausfließen lässt. Es gilt immer noch der alte Spruch: “Real Programmers can write FORTRAN in any language.”; unleserlichen Kram kann man in jeder Programmiersprachen zusammennageln. Selbst die viel gelobte und gehasste Einrückungspflicht in Python verhindert das nicht. BTT: kann man eigentlich mit Lazarus einfach ein statisches Windows-Binary bauen, also etwas, was ich jemandem anders in die Hand drücken kann, und das er, ohne dass ich ihm erst noch einen riesigen Windows-Installer mit sackweise DLLs mitgeben muss, laufen lassen kann? Genau daran scheiterte es bei meinem letzten Projekt, das auch 'ne kleine GUI enthält, und das ich mit Qt gemacht habe. Qt ist natürlich auch sehr schön plattformübergreifend und abstrahierend, aber die Opensource-Variante (die mir ansonsten völlig genügt hätte, das soll nicht kommerziell werden, und ich könnte den Code auch veröffentlichen) von Qt weigert sich beharrlich, statisch zu linken. Damit muss jemand, dem ich das gebe, dann selbst erstmal Qt installieren, oder aber ich müsste ihm einen Installer bauen und den ganzen Rassel mitgeben. Das ist für ein „Hier hast du, probier's aus“-Projekt lästig.
Egon D. schrieb: > Richtig -- und trotzdem MUSS man es, weil Pascal nicht immer alles > bereitstellt, was man benötigt. Leider. Warum regst du dich auf? Die Rede war doch nicht in allen Bereichen, sondern "in einigen Bereichen".
Jörg W. schrieb: > Opensource-Variante (die mir ansonsten völlig genügt hätte, das soll > nicht kommerziell werden, und ich könnte den Code auch veröffentlichen) > von Qt weigert sich beharrlich, statisch zu linken Das liegt aber nicht an Pascal oder Lazarus, sondern an den Lizenzbedingungen von Qt - und ist in C selbst mit Qt Creator genauso. Ein Grund, warum ich es nicht verwende.
Tany schrieb: > Egon D. schrieb: >> Richtig -- und trotzdem MUSS man es, weil Pascal >> nicht immer alles bereitstellt, was man benötigt. >> Leider. > > Warum regst du dich auf? Weil mir die Willkür, die Beliebigkeit der Pascal-Fanboys auf die Nüsse geht, wenn sie ihre Lieblingssprache beweihräuchern. > Die Rede war doch nicht in allen Bereichen, sondern > "in einigen Bereichen". Jaja... und die Bereiche, die die Fanboys wichtig finden, sind OBJEKTIV GANZ WICHTIG, während die Bereiche, die ICH wichtig finde, nur meiner Verbohrtheit geschuldet sind. Alles klar.
Karl K. schrieb: > Das liegt aber nicht an Pascal oder Lazarus, sondern an den > Lizenzbedingungen von Qt Ja, aber das war für dieses Mini-Projekt letztlich das k.o.-Kriterium, weshalb ich es dann doch nicht weiter verfolgt habe. Kam hinzu, dass qwt ziemlich krampfig da hinein gestrickt ist und in verschiedenen Konstellationen dann segfaults verursacht hat. Aber auf dieses Gimmick hätte ich ansonsten verzichten können, so nett wie die qwt-Widgets auch aussehen. Vermutlich hätte ich bei Freepascal dann auch nichts vergleichbares. Kann FPC eigentlich auf USB zugreifen (also Direktzugriff aufs Gerät, libusb oder dergleichen)? Das war unter Qt kein Problem, auch plattformübergreifend nicht, und das wäre für dieses Projekt ein "muss".
:
Bearbeitet durch Moderator
Jörg W. schrieb: > kann man eigentlich mit Lazarus einfach ein statisches > Windows-Binary bauen, also etwas, was ich jemandem anders in die Hand > drücken kann, und das er, ohne dass ich ihm erst noch einen riesigen > Windows-Installer mit sackweise DLLs mitgeben muss, laufen lassen kann? Ja geht, genau so läuft mein Uart-Terminal, weisst schon das ineffiziente: Eine Exe unter Windows, eine ausführbare Datei unter Linux. Nutzt unter Windows die WinApi, unter Linux GTK. Und genau aus diesem Grund: Das Terminal läuft vom Stick, ohne das was installiert werden muss. Hat aber Grenzen: Ein Telegram-Bot braucht für https die OpenSSL, die muss unter Windows als DLL vorliegen, unter Linux ist sie üblicherweise installiert.
Jörg W. schrieb: > Ja, aber das war für dieses Mini-Projekt letztlich das k.o.-Kriterium, > weshalb ich es dann doch nicht weiter verfolgt habe. Häh? Und? Das ist doch unter C genauso. Ich hab besagtes Terminal vor Jahren in Purebasic geschrieben. Da es das für den Raspi - Linux Arm nicht gibt, hab ich das - das Forum war der Meinung, da geht nur C(++) - dann in C mit Qt erneut geschrieben, für Win und Linux Arm. Und bin prompt auf die Schnauze geflogen, als ich das beim Kunden starte und "Keine Qt Lib gefunden" kommt. Dann hab ich Lazarus und FPC gefunden, das Terminal damit nochmal geschrieben - letztlich sind die Programmstrukturen doch sehr gleich. Der Witz ist, mit Lazarus ist die Exe 2Mbyte groß, mit Qt waren es 5MByte - ohne DLL -, und in PureBasic - ganze 56kByte. Gleiche Programmfunktionalität.
Jörg W. schrieb: > BTT: kann man eigentlich mit Lazarus einfach ein statisches > Windows-Binary bauen, also etwas, was ich jemandem anders in die Hand > drücken kann, und das er, ohne dass ich ihm erst noch einen riesigen > Windows-Installer mit sackweise DLLs mitgeben muss, laufen lassen kann? Ja. Das ist einer der Gründe warum ich noch nicht auf Qt umgestiegen bin. Die Executables (für GUI-Anwendungen) beginnen so bei 5MB aufwärts und laufen standalone auf Windows XP bis 10. Da kann man nem Kunden auf einfachste Weise schnell mal eine .exe geben die garantiert laufen wird, egal worauf, und die keine Zicken mit DLL-Hölle oder dergleichen machen wird. Genau wie Delphi damals. Die Linux Executables sind ebenfalls statisch gelinkt und brauchen auf dem Zielrechner nur GTK (oder wahlweise kann man auch für Qt bauen) und GTK findet sich auf jedem Linux-Desktop, es läuft auf dem verstaubtesten Debian das man irgendwo im Keller noch finden kann bis hin zur neuesten Bleeding Edge Distro. Muss nur GTK drauf sein. Draufkopieren, ausführbar machen und los gehts.
Karl K. schrieb: > Häh? Und? Das ist doch unter C genauso. In C natürlich nicht, Qt ist C++. Aber genau darum ging es mir ja, dass ich das Mini-Projekt dann liegen lassen und nicht weiter verfolgt habe, weil mir der DLL-Kram unter Windows zu lästig war. (Die paar Shared Libs unter Linux oder FreeBSD waren kein Problem, das ist alles nur very basic, bis hin zu besagter libusb.)
Karl K. schrieb: > Ob Metaprogrammierung in Pascal so ist wie in C++? Wayne Es wurde gesagt dass Object Pascal genau so viel kann wie C++. Und da Metaprgrammierung nunmal ein zentraler Teil von C++ ist, muss sie nach der Aussage auch von Object Pascal so unterstützt werden. Da das nicht der Fall zu sein scheint, ist diese vollmundige Aussage also widerlegt. Es kann ja sein dass du lieber deine Tastatur abnutzt anstatt Metaprogrammierung einzusetzen. Aber dann braucht man nicht zu behaupten das Pascal das könnte. Karl K. schrieb: > Mit bißchen Googlen hätte er gefunden, dass Freepascal > Metaprogrammierung kann. Ach, kannst du denn diese vollmundige Aussage belegen, oder kommt gleich wieder dass es irrelevant ist? Ich meine natürlich richtige Metaprogrammierung, keine Codegenerierung mit Dritt-Tools oder simples Präprozessing. Karl K. schrieb: > mit Qt waren es 5MByte - ohne DLL -, Sicher dass die Optimierung an war? Mit Java hättest du übrigens die kleinste Programmdatei erhalten. Eine JRE hat praktisch jeder installiert... Den meisten Programmierern ist halt Funktionalität des Framework am Wichtigsten. Da wird auf die Größe der Programmdatei nicht so viel wert gelegt. Wenn deine Kunden so wenig Speicherplatz frei haben musst du dich halt mit weniger Umfang des Framework zufrieden geben. Der Platz wird ja nicht aus Spaß verbraucht, da ist ja Funktion drin.
Karl K. schrieb: > Der Witz ist, mit Lazarus ist die Exe 2Mbyte groß, mit Qt waren es > 5MByte Bist du dir sicher, dass du da auch die tatsächlich zu ladende Größe gemessen hast, und nicht etwa die Debug-Infos? Die sind gerade bei C++ (Qt) durch das name mangling ausufernd riesig. Weiß nicht, wie das Windows-Pendant dazu heißt, unter unixoiden Systemen gibt dir das "size"-Kommando die entsprechende Größe zurück.
Jörg W. schrieb: > Kann FPC eigentlich auf USB zugreifen (also Direktzugriff aufs Gerät, > libusb oder dergleichen)? Das war unter Qt kein Problem, auch > plattformübergreifend nicht, und das wäre für dieses Projekt ein "muss". Hab mal kurz gesucht, es gibt Bindings für libusb, sollte also kein Problem sein. Habs aber selber nie benutzt.
Jörg W. schrieb: > Kann FPC eigentlich auf USB zugreifen (also Direktzugriff aufs Gerät, > libusb oder dergleichen)? Das war unter Qt kein Problem, auch > plattformübergreifend nicht, und das wäre für dieses Projekt ein "muss". Ja, wenn es Header-Files für die entsprechenden Libs gibt oder du die selber erstellen kannst. Sollte ich statt Header ev. Wrapper schreiben? Für FTDI z.B. gab es die.
:
Bearbeitet durch User
Die URL eines Wrappers wurde ja schon gepostet. Muss ich mir dann trotzdem erstmal zu Gemüte führen, wie man das benutzt, da das ja dort alles OO-Wrapper sind. Macht leider den Aufwand wieder größer … Weil du FTDI erwähnst: das ist hier ein reines custom device: ein ATmega mit USB, der aus einem Tektronix 492 Daten ausliest und an den Host senden kann. Alles also völlig selbst gestrickt.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Muss ich mir dann trotzdem erstmal zu Gemüte führen, wie man das > benutzt, da das ja dort alles OO-Wrapper sind. Macht leider den Aufwand > wieder größer … Beispielprojekt angucken, das geht am schnellsten. ;-)
Guido B. schrieb: > Beispielprojekt angucken, das geht am schnellsten. ;-) Wenn man für diesen speziellen Anwendungsfall (eigenes USB-Gerät an libusb) eins findet.
Dr. Sommer schrieb: > Es wurde gesagt dass Object Pascal genau so viel kann wie C++. Da niemand so wirklich weiss was C++ alles kann - ja ok, ausser du natürlich -, halte ich diese Aussage für gewagt. Ich würde auch nicht behaupten, dass ich weiß was Lazarus/FPC alles kann. Da ich zielorientiert programmiere - bin ja kein Student mehr -, suche ich mir das, was ich brauche. > Metaprgrammierung nunmal ein zentraler Teil von C++ ist, muss sie nach > der Aussage auch von Object Pascal so unterstützt werden. Ja pffft, dein Buzzword. Definiere doch erstmal, was bei dir Metaprogrammierung ist. Templates? Kann FPC auch. Aber da du es nicht definierst, sondern dir schön schwammig offen hältst, kann du natürlich immer die nächsten Buzzwords reinwerfen. Und da erwartet oben jemand, mit dir ernsthaft diskutieren zu wollen. Geschenkt.
Jörg W. schrieb: > Wenn man für diesen speziellen Anwendungsfall (eigenes USB-Gerät an > libusb) eins findet. Da kapiere ich garnichts mehr. An wen sendet das Gerät denn? Gibt es schon ein System das unterstützt wird und liegen die Quellen vor? Die FTDI-Libs sind unter Linux suboptimal. Ich habe das damals ja für den MiniLA (imho noch vor Mockup) probiert. Da war schon klar, das müsste man mit LibUSB realisieren. Die Umsetzung geht aber nicht 1:1, ... , wieder ein gestorbenes Projekt. :-( Ah, Google findet den Link: Beitrag "Re: miniLa Software"
Guido B. schrieb: > Da kapiere ich garnichts mehr. An wen sendet das Gerät denn? An meine Qt-App, die ich gewillt wäre, auf FPC umzuschreiben. > Gibt es > schon ein System das unterstützt wird und liegen die Quellen vor? Ja. Ich mach da mal einen separaten Thread auf.
Guido B. schrieb: > Ja, wenn es Header-Files für die entsprechenden Libs gibt oder > du die selber erstellen kannst. Sollte ich statt Header ev. Wrapper > schreiben? Für FTDI z.B. gab es die. Unter Pascal gibt es keine Headerfiles. In Pascal gibt es ein bestens funktionierendes Unitsystem.
Zeno schrieb: > Unter Pascal gibt es keine Headerfiles. Word! Das ist mal echt ein Sackgang mit den Headerfiles bei C. Leider hat man das bei Ada auch nicht besser umgesetzt.
Karl K. schrieb: > Da niemand so wirklich weiss was C++ alles kann - ja ok, ausser du > natürlich -, halte ich diese Aussage für gewagt. Bla, bla. Im ISO C++ Standard steht klipp und klar drin was C++ kann. Karl K. schrieb: > Templates? Kann FPC auch Das ist anscheinend nur eine primitive Text Ersetzung. Das kann sogar C. Karl K. schrieb: > Definiere doch erstmal, was bei dir Metaprogrammierung ist Das was es in C++ ist. Die Möglichkeit, während des Kompilations Vorgangs automatisch eigene Datentypen und Algorithmen zu konstruieren. Mit der C++ Bibliothek Boost.Spirit beispielsweise kann man mit ein paar Zeilen mit einer EBNF-artigen Definition eine kontextfreie Grammatik definieren, und der Compiler baut dafür einen perfekt optimierten Parser Algorithmus. Die Eigen3 Library ermöglicht die abstrakte Formulierung von Matrix-Algorithmen, welche dann vom Compiler zu optimierten Algorithmen zusammen gebaut werden. In C++ kann man sich allein mit Mitteln der Sprache selbst Variant und Tupel Typen bauen. In Sprachen wie Java, Kotlin, C# welche zwar auch so etwas wie Generics haben ist das aber nicht möglich. Daher kann man da keine wirkliche Meta Programmierung machen. Welche Sprach-Mittel man dafür also braucht - variadische Templates, constexpr, fold expressions, partielle Spezialisierung, Overloads und Type-Inferenz, abhängige Typ-Aliase, Mehrfach-Vererbung und natürlich einen starken Optimizer. Das werde ich jetzt natürlich nicht alles im Detail erläutern, denn C++ Bücher können das viel besser. Ein solches zu lesen hat auch den Nebeneffekt dass man dann C++ lernt...
Jörg W. schrieb: > Kann FPC eigentlich auf USB zugreifen (also Direktzugriff aufs Gerät, > libusb oder dergleichen)? Das war unter Qt kein Problem, auch > plattformübergreifend nicht, und das wäre für dieses Projekt ein "muss". Der Vollständigkeit halber noch hidapi unter Linux (und unter Windows kann man stattdessen direkt das Windows-API benutzen): https://github.com/prof7bit/HIDAPI.pas > Kann FPC eigentlich auf USB zugreifen FPC ist ein Compiler damit kann man Programme kompilieren, nicht auf Dinge zugreifen. Das macht dann das Programm das man damit schreibt. Eigentlich genauso wie bei C oder C++.
Dr. Sommer schrieb: >...Das was es in C++ ist. Die Möglichkeit, während des Kompilations > Vorgangs automatisch eigene Datentypen und Algorithmen zu konstruieren.... Egon D. schrieb: > Jaja... und die Bereiche, die die Fanboys wichtig finden, > sind OBJEKTIV GANZ WICHTIG, während die Bereiche, die > ICH wichtig finde, nur meiner Verbohrtheit geschuldet > sind. Alles klar. Egon D. schrieb: >...auf die Nüsse geht, wenn sie ihre Lieblingssprache > beweihräuchern
Wie gesagt, man kann auch ohne Metaprogrammierung auskommen. Aber zu behaupten, dass Pascal das auch alles so könnte, ist falsch. Und mich nerven diese allumfassenden Aussagen à la "Pascal kann das auch alles".
Dr. Sommer schrieb: > Mit der C++ Bibliothek Boost.Spirit beispielsweise kann man mit ein paar > Zeilen mit einer EBNF-artigen Definition eine kontextfreie Grammatik > definieren, und der Compiler baut dafür einen perfekt optimierten Parser > Algorithmus. Du meinst also eine eigene Makrosprache? Schau dir VisualBasic an, das macht dich bestimmt glücklich. Dr. Sommer schrieb: > "Pascal kann das auch alles" Aber so ist es doch nun einmal. Da beisst die Maus (oder sommerliches Mäuschen) keinen Faden ab.
MaWin schrieb: > Du meinst also eine eigene Makrosprache? Nein. Ich muss euch Programmier-Experten doch wohl nicht erläutern was Metaprogrammierung ist. MaWin schrieb: > Schau dir VisualBasic an, das > macht dich bestimmt glücklich. Sehr witzig. MaWin schrieb: > Aber so ist es doch nun einmal. Da beisst die Maus (oder sommerliches > Mäuschen) keinen Faden ab. Wieder einmal ohne Beleg. Hurra! Ein ganz primitives Beispiel: Man möchte ein "max"-Funktion implementieren, welcher man N Werte beliebigen aber identischen Typs übergeben kann. Diese sollen, beginnend mit den ersten beiden, paarweise verglichen werden mit dem "<" Operator. Der größte Wert soll zurückgegeben werden. Damit das schön effizient ist, soll keine Schleife verwendet werden, sondern der Algorithmus hartkodiert. Die Parameter sollen nur 1x evaluiert werden, d.h. bei der Übergabe von "++i" soll nichts schief gehen. In C++ wäre eine Möglichkeit:
1 | #include <iostream> |
2 | |
3 | template <typename First> |
4 | inline constexpr First max (const First& first, const First& second) { |
5 | return first < second ? second : first; |
6 | }
|
7 | |
8 | template <typename First, typename... Rest> |
9 | inline constexpr First max (const First& first, const First& second, const Rest&... rest) { |
10 | return max (max(first, second), rest...); |
11 | }
|
12 | |
13 | constexpr double x = max(3.14, 2.7, 9.5, 2.4); |
14 | |
15 | int main () { |
16 | int a = 42, b = 52, c = 7; |
17 | std::cout << max(a,++b,c) << ", " << x << std::endl; |
18 | std::cout << "a=" << a << ", b=" << b << ", c=" << c << std::endl; |
19 | }
|
Die per "constexpr" berechnete Variable "x" wird vom Compiler berechnet und in den Programmspeicher (Flash bei MCU) gepackt. Das ganze funktioniert mit allen Zahlentypen und auch selbstdefinierten Typen welche den "<" Operator haben, d.h. vergleichbar sind. Bei eingeschalteter Optimierung wird in diesem einfachen Beispiel die Unterscheidung sogar wegoptimiert. Die Definition von max sieht zwar nicht besonders schön aus, aber die Nutzung schon, und es ist immerhin möglich, so etwas effizient in C++ umzusetzen. In C geht das nicht. In Java nur ineffizient mit Umwegen. Wie geht das in Free/Object Pascal?
Dr. Sommer schrieb: > In C geht das nicht. In Java nur ineffizient mit Umwegen. Wie geht das > in Free/Object Pascal? Es geht nicht weil sowas wie constexpr nicht existiert. Und in C++ gabs das lange Zeit auch nicht. Es existiert sowas wie templates in der Form von Generics, damit kann man schonmal viele wichtige Sachen aus der Praxis erschlagen, dazu gibts ne kleine Sammlung von den gängigsten generischen Containerklassen, wenns das nicht gäbe würde ich es wirklich schmerzlich vermissen weil eine statisch getypte Sprache sowas IMHO einfach braucht, aber sowas constexpr gibts nicht und auch vieles von der fortgeschritten C++ Template-Magie geht nicht. Ebenso gibt es keinen so leistungsfähigen (und dennoch irgendwie verkorksten) Präprozessor wie bei C der Makros mit Argumenten beherrschen würde mit dem man in C die übelsten Hacks vollführen kann um fehlende Metaprogrammierung zu kompensieren, das hat man in Pascal niemals implementiert und wehrt sich auch dagegen weil man der Überzeugung ist daß man damit den Weg in die Hölle pflastern würde. Es gibt simple Makros ohne Argumente und bedingte Kompilierung. Nachdem das jetzt geklärt ist müssen wir hoffentlich nicht weiter darauf herumreiten. Man kann offenbar auch ein erfülltes und turing-vollständiges Leben führen ohne 3-fach verschachtelte template-constexpr-Konstrukte bei denen der ungeübte Leser nur so mit den Ohren schlackert und der Fachmann sich wundert.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Man möchte ein "max"-Funktion implementieren, welcher man N Werte > beliebigen aber identischen Typs übergeben kann. Kauf dir mal ne ordentliche Programmiersprache. In Freepascal nimmt man einfach MaxValue, ja geht für alle vergleichbaren Datentypen, ja wenn das alles Konstanten sind ist der Compiler so schlau das auf eine Konstante zu optimieren. Dr. Sommer schrieb: > Damit das schön effizient > ist, soll keine Schleife verwendet werden, sondern der Algorithmus > hartkodiert. Ach, ist das deine Definition von Effizient? Wenn es der Compiler berechnet, ist es egal ob Schleife oder if.. else if... am Ende steht eine Konstante im Compilat. Wenn es Variablen sind, möchte ich doch bitte, dass der Compiler auf dem AVR eine Schleife verwendet und mir nicht den Flash mit Branches vollmüllt. Kommt halt drauf an, auf was man optimieren möchte.
Dr. Sommer schrieb: > Wie gesagt, man kann auch ohne Metaprogrammierung > auskommen. Aber zu behaupten, dass Pascal das auch > alles so könnte, ist falsch. Der Witz ist nur, dass das überhaupt niemand behauptet hat. Schon in Deiner allerersten Antwort spricht das korrekte Zitat von "...deren Funktionsumfang mit C++ vergleichbar ist..." Und Du wirst mir ja wohl hoffentlich zustimmen, dass Vergleichbarkeit durchaus im Auge des Vergleichenden liegt.
Karl K. schrieb: > In Freepascal nimmt man einfach MaxValue, ja geht für alle > vergleichbaren Datentypen Das basiert aber auf Arrays. Das baut eine Iteration und ist ineffizient. Karl K. schrieb: > Wenn es der Compiler berechnet, ist es egal ob Schleife oder if.. else > if... am Ende steht eine Konstante im Compilat. Ja, WENN. Karl K. schrieb: > Wenn es Variablen sind, möchte ich doch bitte, dass der Compiler auf dem > AVR eine Schleife verwendet und mir nicht den Flash mit Branches > vollmüllt. Auch wenn's nur 3 Elemente sind? Und wenn du einen Prozessor mit Cache und Branch Prediction hast auf dem Schleifen langsam sind? Okay, das Beispiel war zu primitiv. Dann schau dir Boost.Spirit an, das ist mehr als nur schnöde Schleifen. Karl K. schrieb: > Kommt halt drauf an, auf was man optimieren möchte. In C++ hat man halt die Wahl. Egon D. schrieb: > Und Du wirst mir ja wohl hoffentlich zustimmen, dass > Vergleichbarkeit durchaus im Auge des Vergleichenden > liegt. Nö. Wenn es in dieser Hinsicht um Größenordnungen weniger mächtig ist, ist es nicht vergleichbar.
Dr. Sommer Du hast recht und wir haben unsere Ruhe. Könne wir uns darauf einigen Dr. Sommer zu ignorieren? Die Diskussionen mit ihm führen zu nichts, er versteht auch nicht wirklich was gemeint ist. Dr. es wäre schön wenn Du dich etwas raushalten könntest. Es geht nicht darum jedes Fitzelchen von C++ mit Pascal zu vergleichen. Im Grundsatz kannst Du alles mir Pascal genauso machen (jedes Programm erstellen) der Weg dahin ist naturgemäss anders und führt dennoch ans Ziel. Wenn Dir der C++ Weg lieber ist, spricht doch nichts dagegen, Pascal kann halt nicht in allen Punkten toll sein. Die Sachen um die es bei Pascal geht..habe ich auf die Anfrage eines Anderen bereits aufgezählt, sind auch in Wikipedia etc nachzulesen oder in so ziemlich jedem Pascal Buch
Dr. Sommer schrieb: > Egon D. schrieb: >> Und Du wirst mir ja wohl hoffentlich zustimmen, dass >> Vergleichbarkeit durchaus im Auge des Vergleichenden >> liegt. > > Nö. Naja, gut. Mit einem solchen Armutszeugnis hätte ich zwar bei Dir nicht gerechnet, aber wenn Du der Meinung bist, dass Vergleichbarkeit NICHT vom Vergleichsmaßstab abhängt, dann ist eine Diskussion mit Dir tatsächlich sinnlos. > Wenn es in dieser Hinsicht um Größenordnungen > weniger mächtig ist, ist es nicht vergleichbar. Du setzt damit voraus, dass das "um Größenordnungen weniger mächtig" irgendwie relevant wäre. Für Dich ist es das vielleicht, und das ist ja auch in Ordnung, aber für mich ist es das NICHT. Mir geht Metaprogrammierung komplett am Arsch vorbei. Von daher: Es steht Dir natürlich frei, Dich weiterhin über die ganzen Dummköpfe lustig zu machen, die auf Grundlage ihrer eigenen (natürlich "völlig falschen" Maßstäbe) zu anderen Urteilen gelangen als Du, aber erwarte nicht, dass man diese Kinderei ernstnimmt.
Egon D. schrieb: > Für Dich ist es das vielleicht, und das ist ja auch in Ordnung, aber für > mich ist es das NICHT. Mir geht Metaprogrammierung komplett am Arsch > vorbei. Schön für dich. Aber es ging um einen objektiven Vergleich von Sprachfeatures, nicht darum was du brauchst. Egon D. schrieb: > Naja, gut. Mit einem solchen Armutszeugnis hätte ich zwar bei Dir nicht > gerechnet Bin ich eigentlich der einzige der ohne ständige persönliche Angriffe diskutieren kann? Egon D. schrieb: > aber wenn Du der Meinung bist, dass Vergleichbarkeit NICHT vom > Vergleichsmaßstab abhängt, Der Maßstab ist, was mit der Sprache möglich ist, welche Mittel die bietet. Nicht was du brauchst. Gegeg J. schrieb: > Es geht nicht darum jedes Fitzelchen von C++ mit Pascal zu vergleichen. Es ist halt nicht nur ein Fitzelchen sondern ein wesentlicher Bestandteil.
Egon D. schrieb: > aber wenn Du der Meinung bist, dass > Vergleichbarkeit NICHT vom Vergleichsmaßstab abhängt, > dann ist eine Diskussion mit Dir tatsächlich sinnlos. Muhaha, auch schon auf den Trichter gekommen? Egon D. schrieb: > Ja und? Dann ENTKRÄFTE doch einfach seine Argumente! Wie gesagt, muhaha! Ich geh dann mal einen Pudding an die Wand nageln.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Egon D. schrieb: >> Für Dich ist es das vielleicht, und das ist ja auch >> in Ordnung, aber für mich ist es das NICHT. Mir geht >> Metaprogrammierung komplett am Arsch vorbei. > > Schön für dich. Aber es ging um einen objektiven > Vergleich von Sprachfeatures, nicht darum was du > brauchst. Es gibt (in dem von Dir gemeinten Sinne) keinen objektiven Vergleich, denn jeder Vergleich setzt einen Vergleichsmaßstab voraus, und dieser folgt einer subjektiven Wahlentscheidung . > Egon D. schrieb: >> Naja, gut. Mit einem solchen Armutszeugnis hätte >> ich zwar bei Dir nicht gerechnet > > Bin ich eigentlich der einzige der ohne ständige > persönliche Angriffe diskutieren kann? Das weiss ich nicht. Du bist aber jedenfalls der einzige, der seinen eigenen subjektiven Maßstab als allgemeingültig verkaufen will. Den Taschenspielertrick kenne ich aber, und ich falle nicht darauf hinein. Wenn ich einen Nagel in die Wand schlagen will und dazu nur ein Stück Butter sowie eine Tüte Bonbons zur Verfügung habe, dann ist beides für diesen Zweck untauglich -- und das völlig unbeschadet der objektiv wahren Tatsache, dass es die Bonbons in mehr Geschmacksvarianten gibt als die Butter. > Egon D. schrieb: >> aber wenn Du der Meinung bist, dass Vergleichbarkeit >> NICHT vom Vergleichsmaßstab abhängt, > > Der Maßstab ist, was mit der Sprache möglich ist, > welche Mittel die bietet. Nein: Das ist DEIN Maßstab, nicht DER Maßstab. > Nicht was du brauchst. In der Regel ist für die meisten Diskutanten der Maßstab, was sie entweder selbst brauchen oder wovon sie sich vorstellen können, dass man es brauchen kann. Kein normaler Mensch wählt freiwillig ein komplizierteres Werkzeug, wenn er davon keinen Zusatznutzen hat -- außer natürlich, er will mit seinen Fähigkeiten angeben. > Gegeg J. schrieb: >> Es geht nicht darum jedes Fitzelchen von C++ mit >> Pascal zu vergleichen. > > Es ist halt nicht nur ein Fitzelchen sondern ein > wesentlicher Bestandteil. Das behauptest Du wieder und wieder, aber den Beleg dafür bleibst Du schuldig.
Dr. Sommer schrieb: > Egon D. schrieb: >> Für Dich ist es das vielleicht, und das ist ja auch in Ordnung, aber für >> mich ist es das NICHT. Mir geht Metaprogrammierung komplett am Arsch >> vorbei. > > Schön für dich. Aber es ging um einen objektiven Vergleich von > Sprachfeatures, nicht darum was du brauchst. Manchmal frag ich mich wozu du dir das antust? Machs doch wie Willhelm und ich und post C++ relevante Dinge hier: Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion" Dass man hier im Forum Sprachfeatures nicht objektiv diskutieren kann is ja wirklich nix neues. Mir wär lieber die C++ Nutzer hier würden ihre Energie in sinnvollere Beiträge stecken wo so Sachen wie letzte Erkenntnisse, neue Sprachfeatures oder Probleme diskutiert werden. Davon hätten wir alle am Ende vermutlich mehr?
Dr. Sommer schrieb: > Man möchte ein "max"-Funktion implementieren, welcher man N Werte ... In Pascal muß ich die nicht implementieren, da ist sie vorhanden und zwar für alle numerischen Typen.
Dr. Sommer schrieb: > In C++ wäre eine Möglichkeit:#include <iostream> > > template <typename First> > inline constexpr First max (const First& first, const First& second) { > return first < second ? second : first; > } > > template <typename First, typename... Rest> > inline constexpr First max (const First& first, const First& second, > const Rest&... rest) { > return max (max(first, second), rest...); > } > > constexpr double x = max(3.14, 2.7, 9.5, 2.4); > > int main () { > int a = 42, b = 52, c = 7; > std::cout << max(a,++b,c) << ", " << x << std::endl; > std::cout << "a=" << a << ", b=" << b << ", c=" << c << std::endl; > } Ohje - komplizierter geht's nimmer. Da lob ich mir halt doch Pascal, da gibt es diese Funktion bereits. Aber das hat ja Karl bereits geschrieben wie's funktioniert. Ob das nun über ein Array läuft ist doch dabei völlig egal. WEnn man solche Zahlenreihen hat dann hält man die in aller Regel in einer Liste oder eben einem dynamischen Array. Praktischerweise gibt es auch noch eine Min- und Mean-Funktion. Um Minimum, Maximum und Mittelwert zu bestimmen reichen dann 3 Zeilen - das Array mit den Zahlen ist ja eh vorhanden. Wenn das da oben ein großer Vorteil von C sein soll, dann möchte ich die nicht so guten Sachen gar nicht wissen.
Yalu X. schrieb: > Aber wozu sollte eine reine Anwendersoftware wie Diptrace oder Altium, > die nur aus GUI, Algorithmen und etwas Networking besteht, solche > Windows-spezifischen Bibliotheken benutzen? Ein GUI-Framework bringt > Delphi selber mit (m.W. heißt es dort VCL), die Algorithmen sollten sich > vollständig in Object-Pascal (ohne externe C++-Module) implementieren > lassen, und für die Netzwerkgeschichten gibt es ebenfalls Delphi-Module. Deine Denkweise ist zu "linuxisch", das ist hier ein bissel der Punkt. Bei "GUI" denkst du nur an das oberflächliche Aussehen, aber nicht an die dahinter stehende Funktionalität. Für gewöhnliche Programme reicht das ja auch aus, die FCL bietet genug Funktionalität für gewöhnliche Programme. Nimm mal mein STM32Prog als Beispiel. Dafür reichen die in die VCL eingebauten Komponenten aus - bis auf die Comport-Komponente. OK, die ist in Pascal selber geschrieben und setzt direkt auf das Windows-API auf. Also ist eigentlich alles, was zum Programm gehört, komplett in Pascal geschrieben - auch das an VCL-Komponenten, die lediglich Wrapper für Windows-Funktionen sind: sowas wie UpDown's, Listen, Check- und Radio-Boxen, Menüs udgl. - die allesamt eigentlich Windows-Prozesse sind. Das alles bildet die FCL für Linux nach, sofern es dort keinen nativen Ersatz vom OS gibt. Aber das, was so ein Bolide wie AltiumDesigner ist, braucht weitaus mehr von den grafischen Funktionalitäten, die Windows beinhaltet. Sowas kann eine brave FCL nicht alles bieten und es müßte all dieses vom OS bereitgestellt werden oder eben separat für X11 nachentwickelt und in's Linux integriert werden. Also, sieh mal nicht nur das Aussehen an. Dein "Aber wozu sollte eine reine Anwendersoftware" zeigt mir, daß du das etwas zu oberflächlich siehst. W.S.
Jörg W. schrieb: > Die letzte Version, für die ich dann nach Betteln (was mich schon > ank***t) mal eine Demo zugestanden bekommen habe, lief halt im Gegensatz > zu der, die wir haben, nichtmal mehr unter VMware – irgendwelcher > ActiveX-Kram, Aussage von Altium Designer stand im Widerspruch zur > Aussage der Microsoft-Tools. (Damit bestätigt sich indirekt das, was > weiter oben über AD vermutet worden ist, dass sie eben an der > Abstraktion vorbei programmiert haben.) Jörg, ActiveX IST die Abstraktion - und es ist eben Windows-Funktionalität, von der ich grad einen Beitrag hier drüber geschrieben habe. Und wer schon mal ein 3D-Spiel angesehen hat, der weiß, wie mächtig das ist. Aber es gibt eben genau DAS unter Linux nicht. W.S.
Hallo, Zeno schrieb: > In Pascal muß ich die nicht implementieren, da ist sie vorhanden und > zwar für alle numerischen Typen. Das hast du gelesen? Dr. Sommer schrieb: > Ein ganz primitives Beispiel: Zeno schrieb: > Wenn das da oben ein großer Vorteil von C sein soll... Offensichtlich hast du auch einiges andere nicht gelesen, es geht nicht um C. rhf
Gegeg J. schrieb: > Und der nächste fragt oder er seine Xikochi Controller damit > programmieren kann. Gibt es keinen Pascal Compiler dafür? was dann? ist > Pascal kacke?! Du sprichst hier ein wichtiges Wort versehentlich an - ich rücke das mal ein bissel gerade: Es wäre sehr wünschenswert, wenn es einen guten Pascal-Compiler für bare-metal-Anwendungen aktueller µC gäbe. W.S.
Dr. Sommer schrieb: > template <typename First> > inline constexpr First max (const First& first, const First& second) { > return first < second ? second : first; > } > > template <typename First, typename... Rest> > inline constexpr First max (const First& first, const First& second, > const Rest&... rest) { > return max (max(first, second), rest...); > } > > constexpr double x = max(3.14, 2.7, 9.5, 2.4); Wie lässt sich das debuggen? Ach ja, der Sommer ist zu Ende.
Jörg W. schrieb: > BTT: kann man eigentlich mit Lazarus einfach ein statisches > Windows-Binary bauen, also etwas, was ich jemandem anders in die Hand > drücken kann, und das er, ohne dass ich ihm erst noch einen riesigen > Windows-Installer mit sackweise DLLs mitgeben muss, laufen lassen kann? Ja. Wenn die Anwendung keine sonstigen Dateien braucht/hat (Helpfiles und so), dann reicht eine einzige EXE aus. > Genau daran scheiterte es bei meinem letzten Projekt, das auch 'ne > kleine GUI enthält, und das ich mit Qt gemacht habe. Tja, das war auch mein Ärger bei dem NWT-Program von Andreas. Zusätzlich zu seiner EXE braucht das eben auch einige QT-DLL's. Die hätte er einfach dazuzupacken brauchen, aber er meinte, unbedingt einen Installer machen zu müssen, der sich in's Windows-Verzeichnis entleert und so weiter. Mich piept sowas an (ich mag nicht, wenn irgendwelche Installer mir im System herumtrampeln), weswegen ich damals zuerst das Programm von Horst verwendete, bis mein eigenes fertig war. Bei Delphi-Programmen sieht das freundlicher aus. Da braucht man keinen Installer und keine fetten Laufzeit-DLL's in irgend einem passenden Versionsstand. Siehe OpenGL bei Horizon... W.S.
W.S. schrieb: > Aber das, was so ein Bolide wie AltiumDesigner ist, braucht weitaus mehr > von den grafischen Funktionalitäten, die Windows beinhaltet. Die da wären? Ich hab jetzt nur einen schnellen Eindruck von einem YT Video zum Altium Designer, aber alles was da in der Gui verwendet wird, Toolbars, Menus, Drop-Down-Menus, Projektbaum, Komponentenauswahl... basiert auf nativen Widgets, die es so in der LCL für WinApi und GTK gibt. Die Inhalte von Schematic und Board müssen "von Hand" gezeichnet werden, aber so schlimm ist das auch nicht. Da nimmt man ein Image, zeichnet drauf und bei einem Repaint für das Fenster wird das aktualisiert. Das kann man über DirectX / OpenGL machen, muss aber nicht. Für die 3D-Ansicht der Bauteile wird sicher DirectX verwendet, den Teil müßte man auf OpenGL umstellen. Aber wie gesagt, ohne Einblick wie der Programmierer das umgesetzt hat ist das rein spekulativ. Über Jahre gewachsene Programme können da eigenartige Züge annehmen. Also ja, man könnte das mit Lazarus/FPC so umsetzen, dass man es problemlos portieren kann, an der Technik liegt es nicht.
Vincent H. schrieb: > Dr. Sommer schrieb: >> Egon D. schrieb: >>> Für Dich ist es das vielleicht, und das ist ja auch >>> in Ordnung, aber für mich ist es das NICHT. Mir >>> geht Metaprogrammierung komplett am Arsch vorbei. >> >> Schön für dich. Aber es ging um einen objektiven >> Vergleich von Sprachfeatures, nicht darum was du >> brauchst. > > Manchmal frag ich mich wozu du dir das antust? [...] > Dass man hier im Forum Sprachfeatures nicht objektiv > diskutieren kann is ja wirklich nix neues. Hmm. Offen gestanden habe ich mit der inflationären Verwendung des Wortes "objektiv" ein Problem. "Objektivität" ist ein SEHR hoher Maßstab, der im vorliegenden Fall mMn nicht sinnvoll ist. Mir wäre sehr daran gelegen, wenn wir vielleicht von "neutral", "wertfrei" oder meinetwegen "ergebnisoffen" sprechen könnten. > Mir wär lieber die C++ Nutzer hier würden ihre Energie > in sinnvollere Beiträge stecken wo so Sachen wie letzte > Erkenntnisse, neue Sprachfeatures oder Probleme diskutiert > werden. Sehr guter Ansatz. > Davon hätten wir alle am Ende vermutlich mehr? Das hängt davon ab, was ihr erreichen wollt. Das Forum hier ist weder der Noam-Chomsky-Club noch die Friedrich-Ludwig-Bauer-Akademie oder der Stroustrup-Verein, sondern das MIKROCONTROLLER - Forum. Man kann daher mit einiger Lebenserfahrung erwarten, dass nicht die Aspekte der theoretischen Informatik im Vordergrund stehen, sondern die verschiedenen Facetten der Mikrocontroller- Programmierung. Wenn die C++-Propagandisten die Verwendung von C++ auf Mikrocontrollern voranbringen wollen, sollten sie vielleicht von ihrem hohen Roß heruntersteigen und die Mikrocontroller- Programmierer dort abholen, wo sie gerade stehen. Das bedeutet konkret: C++ müsste ein Problem, dass die Skeptiker tatsächlich HABEN , AUS DER SICHT DER SKEPTIKER so viel besser lösen als andere Werkzeuge, dass sie bereit sind, sich damit näher auseinanderzusetzen. Der aktuelle Stand ist: Für mich liest sich bis jetzt jede "Vereinfachung" durch C++ wie ein bitterer Hohn auf den menschlichen Verstand.
W.S. schrieb: > Es wäre sehr wünschenswert, wenn es einen guten > Pascal-Compiler für bare-metal-Anwendungen aktueller > µC gäbe. In der Tat. Aber das ist ja angeblich "nicht der Anspruch" von Pascal. Naja.
tatsächlich hatte ich das auch mal im Freepascal forum angeregt und wollte demnächst weiterer Vorschläge für die Umsetzung einer Art Libstock etc. anregen. Bereits jetzt wird PAscal überraschend häufig beim RasberryPI eingesetzt..Keine Ahnung wie die Generation auf Pascal gekommen ist, aber es freut mixh
Beitrag #6001617 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > Bereits jetzt wird PAscal überraschend häufig beim RasberryPI > eingesetzt.. Es bietet halt genial einfaches Crossplattform-Compiling, ohne mit Makefiles rummachen zu müssen. Ich hab auch C++ für den Pi versucht, mit Qt Creator von Windows aus, ging aber war nervig. Und man kann von Kommandozeilentool über Web-CGI-Anwendung bis zur Gui so ziemlich alles erledigen, einfach Presets auswählen. Dazu einen komfortablen Gui-Editor mit Ankerei, wo man Guis flexibel für WinApi und GTK bauen konnte. Das geht nicht schlechter als im Qt Creator, auch ist die Verknüpfung der Events einfacher.
Roland F. schrieb: > Zeno schrieb: >> In Pascal muß ich die nicht implementieren, da ist sie vorhanden und >> zwar für alle numerischen Typen. > > Das hast du gelesen? Nö! Selbst oft genug gemacht. Da ich sehr viel Software schreibe mit der Messdaten aufbereitet werden ist das praktisch mein täglich Brot.
Roland F. schrieb: > Offensichtlich hast du auch einiges andere nicht gelesen, es geht nicht > um C. Wenn Du meinst dann habe ich eben einiges nicht gelesen - Du hast gar nichts gelesen und offensichtlich auch nichts verstanden. Ist aber alles nicht weiter schlimm, da Du eh 0,nix zum Thema beigetragen hast.
Beitrag #6001707 wurde von einem Moderator gelöscht.
Beitrag #6001721 wurde von einem Moderator gelöscht.
Beitrag #6001726 wurde von einem Moderator gelöscht.
Beitrag #6001730 wurde von einem Moderator gelöscht.
Jetzt dreht er komplett durch. Ich denke der nächste Moderator der hier vorbeikommt wird dieses außer Kontrolle geratene Rumpelstilzchen jetzt löschen bevor er sich das zweite Bein auch noch ausreißt.
Beitrag #6001742 wurde von einem Moderator gelöscht.
Beitrag #6001744 wurde von einem Moderator gelöscht.
Beitrag #6001745 wurde von einem Moderator gelöscht.
Beitrag #6001750 wurde von einem Moderator gelöscht.
Beitrag #6001778 wurde von einem Moderator gelöscht.
Beitrag #6001785 wurde von einem Moderator gelöscht.
Karl K. schrieb: > Die da wären? Ich hab jetzt nur einen schnellen Eindruck von einem YT > Video zum Altium Designer, aber alles was da in der Gui verwendet wird, > Toolbars, Menus, Drop-Down-Menus, Projektbaum, Komponentenauswahl... > basiert auf nativen Widgets Ich habe den AD selbst noch nicht auseinandergenommen, aber wenn ich den Jörg hier jammern sehe, daß der AD in seiner virtuellen Box über mangelndes DirectX klagt, dann wird mir klar, was da abgeht. Du kannst aus dem Aussehen von Menüs, Toolbars usw. NICHT ersehen, was da hinter der eigentlichen Zeichenfläche steckt. DirectX kann in ganz gewöhnliche 2D-Umgebungen eingebettet sein, so daß man von außen davon nichts sieht. Und sowas wie einstellbare Transparenz zwischen den Layern und der schnelle Wiederaufbau des Hintergrundes beim Verschieben von Bauteilen, Leiterzügen etc. riecht geradezu danach. Es ist wie immer: Delphi und Lazarus haben mit ihren jeweiligen Komponenten-Bibliotheken all das an Bord, was man für gewöhnliche Programme im Allgemeinen so braucht, aber wenn irgend etwas darüber hinaus geht, dann braucht es zusätzliche Funktionalität. Und die muß von irgendwo halt herkommen. Das Kapseln von sowas in Komponenten, die man dann im eigentlichen Programm benutzt, kann sowohl Delphi als auch Lazarus. Das ist nicht das Problem. Salopp gesagt: Wenn eine Anwendung sowas wie DirectX unter Windows braucht, dann braucht diese Anwendung das eben auch unter Linux. Deswegen ist es eben nicht mit einem simplen Neu-Übersetzen getan, wie Yalu das weiter oben naiverweise geglaubt hat. Aber ich meine, derartige Spezereien sind kein Thema für Feld-Wald-Wiesen-Programme. Die lassen sich mit den Bordmitteln von Delphi und Lazarus allemal programmieren. W.S.
Beitrag #6001922 wurde von einem Moderator gelöscht.
W.S. schrieb: > Wenn eine Anwendung sowas wie DirectX unter Windows > braucht, dann braucht diese Anwendung das eben auch unter Linux. Ja, soweit waren wir oben schon. Das ist keine Frage der Gui, die ist problemlos portierbar. Wenn die da DirectX verwendet haben, dann müsste man das auf OpenGL umstellen. Was technisch auch kein Problem wäre, denn die Funktionalität von DirectX stellt OpenGL im Prinzip auch da, zumindest das, was für ein CAD-Programm gebraucht wird. Aber man müßte die an DX hängenden Routinen halt umschreiben, und da hat wohl keiner Lust drauf... Witzig übrigens: Ich hab mal in Purebasic was geschrieben, was dieses 3D-Drawing Zeug verwendete. Das hat Purebasic so gewrappt, dass man einfach durch einen Compilerswitch zwischen "kompiliere für DirectX" und "kompiliere für OpenGL" wechseln konnte. Ohne irgendwas im Programm umzuschreiben. Es gibt auch für Freepascal Grafiklibs, die beides können. Nützt nur nichts, wenn die für Altium Designer nicht verwendet wurden. Das sind halt so Design-Entscheidungen, die trifft man einmal und Jahre später merkt man, dass man damit in eine Sackgasse gefahren ist.
Beitrag #6001957 wurde von einem Moderator gelöscht.
Tina P. schrieb: > Und was diese Anspielung C ähnlicher Synta soll bei Mikro e ist mir auch > ein Rätsel. Die Syntax ist schon Pascal, aber die Datentypen und die Semantik sind größtenteils C. Ein paar Beispiele: - Strings wie in C zero-terminated, Pascal-Implementationen speichern üblicherweise die Anzahl der Zeichen - Bibliotheksfunktionen für Strings wie in C: strlen, strcpy, strcat, strcmp usw. - Wie in historischen C-Versionen (vor C99) kein boolean-Typ - Als Folge davon kein polymorphes AND, OR- und NOT wie in Free Pascal In Free Pascal: boolean -> logisch, integer -> bitweise) In mikroE Pascal: immer bitweise - Zeiger wie in C (inkl. der von den Pascal-Anhängern vielgeschmähten Zeigerarithmetik) - Keine verschachtelten Prozedur-/Funktionsdeklarationen, alle Prozeduren und Funktionen stehen wie in C auf einer Ebene - Wie in C nur eindimensionale Arrays, mehrdimensionale werden als Array of Array gebildet - Keine Sets - ... Es fehlen aber auch einige Pascal-Features, die sich (zumindest in etwas eingeschränkter Form) auch in C wiederfinden, und deswegen weder in einem echten, noch in einem "C-ishen" MikroE Pascal fehlen dürften: - boolean (in C bool) - Logisches AND, OR und NOT (in C &&, || und !) - Aufzählungstypen (in C Enums) - ... Das Ganze muss doch für einen echten Pascal-Anhänger ein Schlag ins Gesicht sein.
Es fehlte noch mehr, als ich mir das mal angeschaut hatte: Die Möglichkeit, selber einen Controllertyp dort einzuarbeiten. Mikroe's Toolchain war auf die Typen festgelegt, die man bei Mikroe dort eingearbeitet hatte. Sowas schränkt mir die Benutzbarkeit doch gar zu sehr ein. W.S.
Yalu X. schrieb: > - Zeiger wie in C (inkl. der von den Pascal-Anhängern vielgeschmähten > Zeigerarithmetik) Um das mal klarzustellen: Natürlich kann in Freepascal auch mit Pointern arbeiten, es ist nur meistens nicht nötig.
:
Bearbeitet durch User
Karl K. schrieb: > Yalu X. schrieb: >> - Zeiger wie in C (inkl. der von den Pascal-Anhängern >> vielgeschmähten Zeigerarithmetik) > > Um das mal klarzustellen: Natürlich kann in Freepascal > auch mit Pointern arbeiten, Es geht nicht um "hat Zeiger", sondern um Zeiger- ARITHMETIK wie in C. Bedeutet: Wenn man einen getypten Zeiger (z.B. Zeiger auf longint) um Eins erhöht, dann zeigt er auf das nächste FELDELEMENT -- und nicht auf das nächste BYTE. Das geht in Standard-Pascal gar nicht; in TurboPascal weiss ich es nicht. FreePascal kann es, und ich finde es sehr nett. > es ist nur meistens nicht nötig. Das würde ich nicht unterschreiben. Feldadressierung in Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer verwendet werden, sondern die Adresse jedesmal explizit aus dem Index berechnet wird. Der Umgang mit Feldern ist überhaupt ein Schwachpunkt in Pascal; ich überlege schon länger, wie man das besser machen könnte :) Ach ja: "Schwachpunkt in Pascal" bedeutet nicht, dass ich C in diesem Punkt besser finde.
Yalu X. schrieb: > Tina P. schrieb: >> Und was diese Anspielung C ähnlicher Synta soll bei >> Mikro e ist mir auch ein Rätsel. > > Die Syntax ist schon Pascal, aber die Datentypen und > die Semantik sind größtenteils C. Ein paar Beispiele: Naja, solange Ausdrucksmittel ZUSÄTZLICH angeboten werden, die in Pascal bisher fehlten, ist da ja nix gegen einzuwenden (Stringfunktionen; Zeigerarithmetik.) > - Wie in historischen C-Versionen (vor C99) kein > boolean-Typ > > - Als Folge davon kein polymorphes AND, OR- und NOT > wie in Free Pascal Das ist bescheuert. Wer denkt sich so etwas aus? Das Typsystem ist -- neben dem deutlich weniger aggressiven Einsatz von Operatoren -- mMn einer der wenigen echten Vorteile von Pascal gegenüber C.
Egon D. schrieb: > Feldadressierung in > Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer > verwendet werden, sondern die Adresse jedesmal explizit > aus dem Index berechnet wird. Das fällt beim AVR auf, wenn man da ein Array abarbeitet. Allerdings war der Leidensdruck bisher an der Stelle nicht so hoch, dass ich mir dafür die Rumpointerei angetan hätte.
W.S. schrieb: > aber wenn ich den Jörg hier jammern sehe, daß der AD in seiner > virtuellen Box über mangelndes DirectX klagt, Ich denke, dass sie da nur irgendwas falsch gemacht haben. Erstens ist es keine Virtualbox, zweitens lief es auch bislang (einschließlich allen 3Ds) schon in VMware, drittens gab/gibt es andere (hier im Forum), die auch mit der aktuellen AD-Version in VMware kein Problem haben. Wenn sie mir aber erzählen, dass sie angeblich DirectX 10 brauchen, und das Microsoft-Tool sagt mir, dass die vorhandene Version 12 oder 13 ist, dann ist da irgendwas im Argen, und sie sollten sich als Hersteller einfach mal drehen, wenn sie mir das Zeug verkaufen wollen. Danach war aber nur Schweigen im Walde.
Karl K. schrieb: > Das würde ich nicht unterschreiben. Feldadressierung in > Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer > verwendet werden, sondern die Adresse jedesmal explizit > aus dem Index berechnet wird. Das könnte der Compiler auch einfach mal besser optimieren, geht in C ja auch. Jörg W. schrieb: > und sie sollten sich als Hersteller > einfach mal drehen, wenn sie mir das Zeug verkaufen wollen. Danach war > aber nur Schweigen im Walde. Natürlich. Ein nicht reproduzierbares Problem auf einem nicht offiziell unterstützten System zu finden, lohnt sich einfach nicht.
Nop schrieb: > Ein nicht reproduzierbares Problem auf einem nicht offiziell > unterstützten System zu finden, lohnt sich einfach nicht. Das Ganze läuft auf Windows 7, mit einer DirectX-Version, die höher als die vorausgesetzte ist. Dass das eine VM ist, braucht eine Anwendungssoftware erstmal nicht interessieren. Es würde mich nicht wundern, wenn der Bug genauso gut auch außerhalb einer VM auftreten kann. Was dann? Auch ignorieren, Kunde möge sich doch ein anderes System zulegen?
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Dass das eine VM ist, braucht eine > Anwendungssoftware erstmal nicht interessieren. Sagst Du. > Es würde mich nicht wundern, wenn der Bug genauso gut > auch außerhalb einer VM auftreten kann. Möglich ist vieles. Geld dafür auszugeben, das zu untersuchen, rechnet sich aber erst, wenn sich das bestätigt. Bis dahin bist Du ein Kunde auf einem nicht offiziell unterstützten System, und solange Desktoplinux keine nennenswerte Verbreitung hat, ist es wirtschaftlicher, auf die paar Kunden einfach zu verzichten, bei denen es nicht läuft.
Nop schrieb: > Bis dahin bist Du ein Kunde auf einem nicht offiziell unterstützten > System Wo steht das eigentlich, dass das nicht offiziell supportet wäre? Irgendwo die Prerequisites eines Programmes zu dokumentieren, scheint unüblich zu sein – zumindest finde ich bei Altium nichts. Ist aber auch egal, es zeigt ja nur, dass allein das Programmiersystem eben noch lange nicht darüber entscheidet, ob eine bestimmte damit verfasste Applikation am Ende wirklich portabel ist oder nicht.
Jörg W. schrieb: > Wo steht das eigentlich, dass das nicht offiziell supportet wäre? Das sollte in den Systemanforderungen stehen, wo typischerweise neben der erforderlichen Mindesthardware auch irgendwas zu den unterstützten OS steht. > Irgendwo die Prerequisites eines Programmes zu dokumentieren, scheint > unüblich zu sein – zumindest finde ich bei Altium nichts. Dann scheint Dein Google-Fu noch im Wochenend-Modus zu sein. Gib mal die Stichworte 'altium designer system requirements' bei Google ein. Ich sehe da nichts von "Windows in einer VM unter Linux".
Jörg W. schrieb: > Das Ganze läuft auf Windows 7, mit einer DirectX-Version, die höher als > die vorausgesetzte ist. Kann sein, dass AD hier auf einige Hardware DX Funktionen der Grafikkarte zugreifen will, die VMware so nicht bereitstellt. Oder die Windows zwar in Software emulieren kann, aber das Programm will halt Hardware. Ich musste letztens auch lernen, dass DirectX11 vorhanden nicht heisst, dass ein Spiel was DirectX11 fordert damit auch läuft - wenn das Spiel auf einige DX Features der Grafikkarte zugreifen will, die diese halt nicht bietet weil zu alt. Pech. Ob das zur Darstellung der Grafik notwendig wäre und nicht auch in Software emuliert genügen würde, ist dabei nichtmal die Frage. Wenn es so programmiert wurde, weil der Programmierer meint: Sollen sie halt ne bessere Grafikkarte kaufen - dann ist das so.
Nop schrieb: > und solange Desktoplinux keine nennenswerte Verbreitung hat, ist > es wirtschaftlicher, auf die paar Kunden einfach zu verzichten, bei > denen es nicht läuft. Ist jetzt zwar etwas OT, aber man kann zur Beurteilung ob sich eine Linuxversion rechnet, nicht die Einnahmen durch Linuxkunden 1:1 mit den Entwicklungskosten vergleichen. Wenn ein Mitbewerber naemlich die Wahl anbietet, dann kann einen das letztlich auch Windowsnutzer kosten. So Offtopic ist das eigentlich auch nicht, die unterstuetzten Platformen sind ja gerade die Staerke von FPC/Lazarus.
Karl K. schrieb: > Kann sein, dass AD hier auf einige Hardware DX Funktionen der > Grafikkarte zugreifen will, Ist ja nicht so, dass da irgendwas falsch gezeichnet würde, sondern sie behaupten beim Start des PCB-Moduls (nur der braucht das überhaupt, aber das ist bei anderen PCB-Programmen wie Kicad oder Horizon nicht anders), dass sie nicht das nötige DirectX 10 hätten. Nop schrieb: > Dann scheint Dein Google-Fu noch im Wochenend-Modus zu sein. Gib mal die > Stichworte 'altium designer system requirements' bei Google ein. Ist aber K*cke, dass man das nur mit Google findet. Ich war über deren Webseite reingegangen und hatte es dort versucht zu finden. > Ich > sehe da nichts von "Windows in einer VM unter Linux". Ich sehe auch nichts, was das explizit ausschließen würde. Alle dort aufgeführten Anforderungen werden von der VM erfüllt – selbst die aus den "Recommended", wenn man davon absieht, dass ich keine 3D-Maus habe (brauch' ich aber auch nicht, den 3D-View benutze ich nur, um mir das Resultat nochmal anzusehen, das geht auch mit einer herkömmlichen Maus gut genug). Da man ihnen für eine doofe Demo-Version hinterher rennen muss, weil man ja schließlich vor Jahren schon einmal eine Demo bekommen hatte, kann ich jetzt auch nicht einfach ausprobieren, wie es sich in anderen Umgebungen verhalten würde (anderes Windows in gleicher VMware, oder andere VM – selbst in der VirtualBox sagt dxdiag, dass sie DirectX 11 hat).
Jörg W. schrieb: > sondern sie > behaupten beim Start des PCB-Moduls... > dass sie nicht das nötige DirectX 10 hätten. Ja, ging mir bei dem Spiel genauso: Systemanforderungen ausreichend, Downloader lädt problemlos runter, beim Start dann "DX Version wird nicht unterstützt". Irgendwo findet man dann, dass irgendwelche DX Features auf der Grafikkarte gefordert werden, die Windows halt auch nicht simulieren kann. Ich behaupte jetzt nicht, dass das bei AD so ist, klingt aber ziemlich ähnlich.
Karl K. schrieb: > Ich behaupte jetzt nicht, dass das bei AD so ist, klingt aber ziemlich > ähnlich. Kann sein. Wie gesagt, Gegentest kann ich nicht machen. Demoversion ist schon lange abgelaufen, ich bettele nicht nach einer weiteren. Wenn das so speziell sein sollte, dann stehen die Chancen gut, dass es auch irgendwelche Grafikmodule ("Grafikkarte" trifft es ja oft genug nicht mehr) in freier Wildbahn gibt, die dann das entsprechende Feature auch nicht unterstützen. Dann wiederum würde es in die Systemanforderungen hin gehören.
Jörg W. schrieb: > Ist ja nicht so, dass da irgendwas falsch gezeichnet würde, sondern sie > behaupten beim Start des PCB-Moduls (nur der braucht das überhaupt, aber > das ist bei anderen PCB-Programmen wie Kicad oder Horizon nicht anders), > dass sie nicht das nötige DirectX 10 hätten. Hallo Jörg, ich sehe das wie Karl, die Software will einfach eine passende Hardware haben und die findet sie in der virtuellen Umgebung nicht. Die Fehlermeldung muß ja nicht die wahre Fehlerursache aufzeigen. Ich kann mir durchaus vorstellen, das bei Grafikfehlern halt ne Fehlermeldung ausgegeben wird die ein falsches DirektX suggeriert. Wir hatten mal ne Messsoftware für DOS gehabt, die wollte auch reale Hardware haben. Dort waren viele Zugriffe auf den Coprozessor und die Grafikkarte in Assembler programmiert mit direkten Zugriffen auf die Hardware. Deshalb lief diese Software auch nur auf echter Hardware. Selbst unter WinNT lief die Software nicht, da dieses System direkte Hardwarezugriffe nicht erlaubt.
Zeno schrieb: > ich sehe das wie Karl, die Software will einfach eine passende Hardware > haben und die findet sie in der virtuellen Umgebung nicht. Dann sollte die Software aber auch angeben, was sie genau an Hardware braucht.
Beitrag #6002586 wurde von einem Moderator gelöscht.
mh schrieb: > Zeno schrieb: >> ich sehe das wie Karl, die Software will einfach eine passende Hardware >> haben und die findet sie in der virtuellen Umgebung nicht. > > Dann sollte die Software aber auch angeben, was sie genau an Hardware > braucht. Sehe ich auch so. Zumindest sollte es der Vertriebler, der einem die Software aufschwatzen möchte, dann mal so artikulieren, wenn man ihm die Fehlermeldung präsentiert. Solange sie als Hardwarevoraussetzungen nur eine „hinreichend gute Grafik mit DirectX 10 oder höher“ angeben (und dann gerade mal zwei Beispiele nennen), dann müssen sie sich auch darauf festnageln lassen. Mal ehrlich: so speziell ist das bisschen 3D-Zeichnerei nun im Jahr 2019 ja auch nicht mehr, dass man als Hersteller da anfangen müsste, neben das dokumentierte API (nein, @W.S., DirectX ist keine Abstraktion, sondern ein API, wie OpenGL auch eins ist) zu greifen.
Fortsetzung meiner Liste der Programme die Pascal erfolgreich kommerziell einsetzen, mit CAO arbeite ich täglich CAo Faktura https://www.cao-faktura.de/
Jörg W. schrieb: > Solange sie als Hardwarevoraussetzungen nur eine „hinreichend gute > Grafik mit DirectX 10 oder höher“ angeben (und dann gerade mal zwei > Beispiele nennen), dann müssen sie sich auch darauf festnageln lassen. Hi, bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte braucht (alles mit DirectX), dann muss man das in der Maschine entsprechend konfigurieren. Macht man das nicht, dann gibt es die vorher beschriebenen Fehlermeldungen, da nur eine einfach 2D-Karte virtuell eingebunden wird: https://docs.vmware.com/de/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-E03ED27D-E469-4115-80E1-435125D6168B.html CU, Crazy
Andreas W. schrieb: > bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte > braucht (alles mit DirectX), dann muss man das in der Maschine > entsprechend konfigurieren. Jein. Es gibt halt Software die die Hardware direkt abfragt und wenn da nichts Entsprechendes zurück kommt dann ist es halt Essig. Da kannst Du an der VM herumkonfigurieren soviel wie Du willst, es wird einfach nicht funktionieren. Glaube mir, ich schrieb ja von einer Software die das so macht, und viele meiner Kunden wollten dann auch das ganze über eine virtuelle Maschine machen. Sie sind einfach nur kläglich gescheitert. Einige Kunden haben da nämlich wirklich ein massives Problem, weil an der Software noch eine Maschine im Wert von über 100k€ dran hängt. Die Software läuft auch nur bis Pentium IV (ab da haben sich die Coprozessorinstruktionen geändert) und als OS max. Win98SE. Wenn man das überhaupt auf einem modern Rechner installiert bekommt, dann scheitert es am Prozessor.
Andreas W. schrieb: > bei VMware ist es so dass wenn die VM eine beschleunigte Grafikkarte > braucht (alles mit DirectX), dann muss man das in der Maschine > entsprechend konfigurieren. Wenn man den Closedsource-Grafiktreiber des Hosts benutzt, schalten sie es automatisch an. Den Opensource-Treibern trauen sie nicht aufs Blaue übern Weg, da muss man explizit die Verantwortung selbst übernehmen. Aber das habe ich natürlich gemacht, ansonsten würde ja auch AD16 nicht damit laufen (die offiziell DirectX 9 oder höher benötigen).
Egon D. schrieb: > Das würde ich nicht unterschreiben. Feldadressierung in > Pascal ist i.d.R. langsam, weil keine mitlaufenden Pointer > verwendet werden, sondern die Adresse jedesmal explizit > aus dem Index berechnet wird. Gute Compiler können längst sowas wie for i := 1 to 100 ... array[i] ... auf der Zielmaschine selber effizient umsetzen. Beispielsweise über einen mitlaufenden Pointer, wenn sich das lohnt. Da kann es dann auch sein, das "i" komplett verschwindet und nur der Pointer bleibt. Erfolgt das nicht, ist es heutzutage eine Schwäche des Compilers, nicht der Sprache. Die Zeiten, in denen man das von Hand optimiert, um den Compiler zu entlasten, sollten lange vorbei sein.
:
Bearbeitet durch User
A. K. schrieb: > Egon D. schrieb: >> Das würde ich nicht unterschreiben. Feldadressierung >> in Pascal ist i.d.R. langsam, weil keine mitlaufenden >> Pointer verwendet werden, sondern die Adresse jedesmal >> explizit aus dem Index berechnet wird. > > Gute Compiler können längst sowas wie > for i := 1 to 100 > ... array[i] ... > auf der Zielmaschine selber effizient umsetzen. > Beispielsweise über einen mitlaufenden Pointer, wenn > sich das lohnt. Da kann es dann auch sein, das "i" > komplett verschwindet und nur der Pointer bleibt. Du hast gerade einige sehr grundsätzliche Überlegungen bestätigt, die ich mir zum Thema gemacht hatte. > Erfolgt das nicht, ist es heutzutage eine Schwäche des > Compilers, nicht der Sprache. Die Zeiten, in denen man > das von Hand optimiert, um den Compiler zu entlasten, > sollten lange vorbei sein. Es geht weniger um Entlastung des Compilers, sondern mehr um Klarheit im Ausdruck. Allerdings habe ich wenig Bedürfnis, meine renitente Außenseitermeinung hier zu diskutieren.
Egon D. schrieb: >> Erfolgt das nicht, ist es heutzutage eine Schwäche des >> Compilers, nicht der Sprache. Die Zeiten, in denen man >> das von Hand optimiert, um den Compiler zu entlasten, >> sollten lange vorbei sein. > > Es geht weniger um Entlastung des Compilers, sondern mehr > um Klarheit im Ausdruck. In Deinem Post auf das Bezug genommen wurde geht es aber genau um das: Du hast unterstellt man wolle gerne von Hand mit Zeigern rumwurschteln um dem Compiler zu helfen weil es sonst angeblich Performanceprobleme gäbe. Und jetzt willst Du plötzlich das Gegenteil gesagt haben? > Du hast gerade einige sehr grundsätzliche Überlegungen > bestätigt, die ich mir zum Thema gemacht hatte. Er hat sie widerlegt, nicht bestätigt! 180°-Wende?
:
Bearbeitet durch User
https://www.golem.de/news/verschluesselung-gpg-muss-endlich-weg-2102-153820.html hach ja....Pascal ist schon schön:-) Viele neue Alternativen natürlich auch
https://news.ycombinator.com/item?id=22843140 auch hier sieht man das es lange noch nicht abgeschrieben ist. NÉs unterstützt auch direkt Z80, AVR und STM32. Der C64 Prozessor befindet sich in Vorbereitung bzw dessen Unterstützung
W.S. schrieb: > Es wäre sehr wünschenswert, wenn es einen guten Pascal-Compiler für > bare-metal-Anwendungen aktueller µC gäbe. Nicht ganz das was du dir wünschst, aber immerhin bare-metal für den RasPi in FreePascal wenn ich das richtig interpretiere: https://ultibo.org/faq/ Gerhard
Ja, gerade in dem Bereich wird überraschend wieder öfter Pascal genutzt "Why not use a language like C, Python or PHP? There are probably more programming languages available today than you could list on a single page, we decided on Free Pascal because it is powerful, flexible and offers the range of features needed to create Ultibo. If you’ve never tried Pascal give it a go, you might be surprised."
Erklär doch mal bitte was Du mit Metaprogrammierung meinst. Vor einer Diskussion sollten Schlagworte klar definiert sein.
Pandur S. schrieb: > Wow, da geistern Zombies in der Daemmerung herum. Und pruegeln sich mit > Altsprachen wie C um die besten Plaetze in der Zombie Liga. Tja... immerhin wird C immer noch aktiv für die meistverbreiteten Betriebssysteme genutzt, wie Windows oder Linux... > Die moderne > Welt will moderne Sprachen. Wie zB Python, wo ein Blank ueber sein oder > nichtsein entscheidet. Ein Gross-Klein Tipp Fehler und eine neue > Variable wird erzeugt, waehrend ich glaube es waere dieselbe. > Schoene neue Debugwelt. Entweder Du kannst coden, oder Du kannst es nicht. Nix neues insofern. ;-)
Tobi P. schrieb: > C für OS und embedded, Delphi für die Anwendungsseite ist imo eine super > Kombi. Es gibt natürlich auch noch andere, keine Frage. Klar, kann man nehmen, aber C++ für OS und Embedded und Python für UI ist auch fein. ;-)
Dr. Sommer schrieb: > loeti2 schrieb: >> Hust, IMHO ist das eine der größten Schwächen wo sich C++ hin entwickelt >> hat. > > Wenn du Features als Schwäche siehst... viel andere > Alleinstellungsmerkmale hat C++ nicht. Doch, schon. Es ist extrem schnell, weit verbreitet, hervorragend dokumentiert und genauso ressourcensparend wie C, wenn man es will. > Wo gibt es denn sonst "richtige" Metaprogrammierung mit statischer (!) > Reflektion? Naja, statische Reflektion... aber wenn Du Metaprogrammierung suchst, bist Du bei Python sicher an einer guten Adresse. ;-) > test schrieb: >> Braucht man so etwas zur normalen Anwendungsentwicklung? > > Man "braucht" nicht mehr als das was Brainfuck bietet. Aber hilfreich > sind zusätzliche Hilfestellungen schon. Was manche Fortschrittsfeinde gerne ignorieren, ist der ökonomische Aspekt von Softwareentwicklung. Und, um ehrlich zu sein: das ist zumindest im kommerziellen Bereich wesentlich wichtiger als ein kindisches Bestehen auf Typsicherheit und maximaler Performanz. ;-)
noch so ein Pascal / delphi Programm:-)
12V
|
|
_ |/
PWM -|___|--|
|>
|
|
.-.
| | 1K
| |
'-' _
|-|___|--------------- 0-6V
| 20k |
.-. |
| | | +
| | 1K ###
'-' ---
| |
GND o------o-------'
(created by AACircuit v1.28.7 beta 10/23/16 www.tech-chat.de)
Passend dazu, das Pascal immer wieder das Ende vorausgesagt wird https://jonlennartaasenden.wordpress.com/2020/03/08/delphi-dying-think-again-tiobe/?fbclid=IwAR0IXjFT16jjCWVbZG7FFWT9QNHpVnsva5SU_s_yxtZsbXtXLu-RsBpwQcA
Delphi and Freepascal is different in more ways than one, but beyond language compatibility there is one aspect that is quintessential for them both; namely their role in the commercial sector. Where other languages, like C/C++ or (for example) JavaScript see a lot of open-source activity, especially with regards to Linux and Node.js – Delphi and Freepascal are predominantly used to write high-quality, commercial, closed source business applications. In other words, the vast majority of code produced by the millions of Object Pascal developers around the world – is never publicly committed to GitHub or BitBucket.
Yalu X. schrieb: > Wie in historischen C-Versionen (vor C99) kein boolean-Typ Aus aktuellem Anlaß: C hat auch jetzt keinen Boolean Typ. Das Einrichten eines Schlüsselwortes macht noch keinen Typ, sondern gibt dem Compiler lediglich die Möglichkeit, zusätzlichen Code zu erzeugen, der aus 42 eben 1 macht. Mehr ist das Ganze nicht, der Boolean "Typ" ist bei C lediglich ein numerischer Untertyp, der nur von 0 bis 1 zählen kann, aber kein echter boolean Typ. Das hatte ich auch dem Jörg neulich zu erklären versucht, aber ich bin mir nicht sicher, daß er es verstanden hat. Kurzum gesagt: Wenn es einen echten Boolean Typ gibt, dann sind alle Vereinbarungen a la 0 ist false, alles ungleich 0 ist true, komplett aus dem Verkehr zu ziehen, ebenso die Unterscheidung zwischen A&B versus A&&B, denn bei Vorhandensein eines boolean Typs ist die UND-Verknüpfung genau so wie auch die ODER-Verknüpfung typgerecht auf alle verknüpfbaren Typen anzuwenden, also logisch auf boolean Variablen und bitweise auf numerische Variablen. Und ja, numerische Variablen haben gar keinen logischen Zustand, eben weil es Zahlen sind. Daß man mittels o.g. Regel (0=false, alles andere = true) die logischen Zustände auf die Zahlen 0 und 1 projiziert, ist nur eine erlassene Regel, ein 'ordre de mufti'. Jörg meinte im Nebensatz, daß $0F und $F0 jeweils true seien, aber das ist C-Denkweise und hat mit Boolean nix zu tun. Also nochmal: Solange all diese genannten Regeln nicht offiziell aus C entfernt werden, gibt es in C keinen Boolean Typ. W.S
W.S. schrieb: > die UND-Verknüpfung genau so wie auch die ODER-Verknüpfung typgerecht > auf alle verknüpfbaren Typen anzuwenden "typgerecht" in Standard-Pascal heißt: ausschließlich auf Boolean. Für etwas anderes sind diese Operatoren dort nicht definiert. Dann stimme ich dir in folgender Aussage zu: "C hat keinen 'echten' Boolean-Typ, und Pascal hat keine bitweisen Operatoren." Hilft einem natürlich in der Praxis rein gar nichts, denn die C-Variante funktioniert in der Praxis ausgezeichnet als reale Implementierung einer Wahrheitsentscheidung, und dass übliche Pascal-Implementierungen die Anwendungen von UND und ODER auf numerische Typen gestatten und dann als bitweise Operatoren betrachten, ist nun auch kein Geheimnis.
Jörg W. schrieb: > "typgerecht" in Standard-Pascal heißt: ausschließlich auf Boolean. > > Für etwas anderes sind diese Operatoren dort nicht definiert. Du solltest wirklich mal wieder ein paar Programme mit sowas wie dem aktuellen Delphi oder mit Lazarus schreiben, dann würdest du dich für solche Worte wohin beißen und rot hinter den Ohren werden. Nein, die besagten Operatoren tun ihren Dienst für alle dafür geeigneten Datentypen. Also für alle numerischen Typen, außer float und double, weil dort ja die Bits zweier Mantissen unterschiedliche Wertigkeiten haben, je nach der gerade vorliegenden Zahl. Das Ganze ist auch logisch: für eine Verknüpfung von boolean Variablen wird ein boolean Ergebnis erzeugt und für dasselbe mit zwei numerischen Variablen eben ein numerisches Ergebnis. Das alles hatte ich dir bereits vor einigen Tagen geschrieben, aber du hast nicht 'zugehört'. Und rede dich nicht mit "Standard-Pascal" heraus. Das Ur-Pascal von Wirth war ein Anfang, aber mittlerweile sind die derzeitigen Fassungen von Embarcadero und Freepascal der Standard. W.S.
Jörg W. schrieb: > und dass übliche Pascal-Implementierungen die > Anwendungen von UND und ODER auf numerische Typen gestatten und dann als > bitweise Operatoren betrachten, ist nun auch kein Geheimnis. Man koennte es auch andersrum sehen, Pascal kennt nur bitweise Operationen. Bei Ein-Bit-Variablen (Boolean) ist die bitweise und logische Operation identisch.
Bernd K. schrieb: > Dr. Sommer schrieb: >> Aber gut zu wissen >> dass Delphi "Von Affen geschrieben" ist und Haarausfall bewirkt! > > Das mit den Affen ist eine böswillige Unterstellung und entspricht nicht > der Wahrheit, aber daß es Haarausfall bewirkt kann als gesichert gelten, > bei mir ist mittlerweile oben rum alles blank. Mit C++ wäre das nicht passiert!
Bernd K. schrieb: > Joggel E. schrieb: >> Ein Gross-Klein Tipp Fehler und eine neue >> Variable wird erzeugt > > Diese Sprache von der Du sprichst heißt Lua und diesen kapitalen > Designfehler gibts zum Glück in keiner anderen relevanten Sprache. Jaein, Autovivikation gibt es auch in Python, Ruby, Perl und anderen, funktioniert dort aber nur bei Zuweisungen. Wer eine Variable zu lesen versucht, der vorher nie etwas zugewiesen wurde, bekommt seinen Unsinn (zurecht!) um die Ohren gehauen.
Nop schrieb: > Bernd K. schrieb: > >> Nein, wenn ich mich recht erinnere bekomme ich bei JS einen Fehler wenn >> ich auf eine Variable zugreifen will die nicht existiert. > > Wenn Du einer Variable einen Wert zuweist, aber dabei deren > Variablennamen verkehrt schreibst, wird die Variable nicht bloß > automatisch neu angelegt anstatt einer Fehlermeldung, was an sich schon > für viel Spaß beim Debuggen sorgt - sie wird obendrein als globale > Variable angelegt, auch wenn Du das in einer Funktion tust. Ist das in Lua so? 8-O
EADS in einem Titel zu erwähnen, ist eine bodenlose Frechheit. Wer weiß, was sich hinter diesem Firmenkonstrukt verbirgt, weiß worum es geht.
W.S. schrieb: > Du solltest wirklich mal wieder ein paar Programme mit sowas wie dem > aktuellen Delphi oder mit Lazarus schreiben Ich schrieb absichtlich von Standard-Pascal. Dass es bei Pascal offenbar nur Wildwuchs gibt (zwei Standards, an die sich keiner halten mag), ist ja nun eher kein positives Markenzeichen. Maxe schrieb: > Man koennte es auch andersrum sehen, Pascal kennt nur bitweise > Operationen. Bei Ein-Bit-Variablen (Boolean) ist die bitweise und > logische Operation identisch. Wenn man in C in logischen Ausdrücken nur Ergebnisse von Vergleichen oder anderer "bool"-Ausdrücke (also 1-Bit-Ausdrücke) benutzt, braucht man auch nicht zwischen & und && zu unterscheiden, dann verhält es sich wie Pascal.
Sludge Hammer schrieb: > EADS in einem Titel zu erwähnen, ist eine bodenlose Frechheit. Das zu monieren, kommst du aber zwei Jahre zu spät. So alt ist die Threadleiche, die da wer ausgebuddelt hat.
Guido B. schrieb: > Jajaja, es geht schon, ich schrieb ja auch nur, dass es keinen > Spaß macht. ;-) > > Der Zusatzaufwand ist schon groß, kein Wunder, dass Borland sein > Projekt Kylix wieder eingestellt hat. Das Problem war sicherlich nicht der Aufwand, sondern das Verhältnis vom Aufwand zum Ertrag. An sich war die Idee aber von vorneherein zum Scheitern verurteilt, um nicht zu sagen ein bisschen blöd: Kylix kam zu einer Zeit, als es unter Linux schon viele sehr leistungsfähige und kostenlose Sprachen und Entwicklungsumgebungen gab, und die Delphi-Entwickler waren meist ohnehin unter Windows sozialisiert.
W.S. schrieb: > C hat auch jetzt keinen Boolean Typ. Oh nein, nicht schon wieder =8-[ > […] der Boolean "Typ" ist bei C lediglich ein numerischer Untertyp, […] ... und damit ein Typ, denn auch ein Untertyp ist ein Typ, wie der zweite Teil des Kompositums erahnen lässt. Übrigens wird auch in Pascal (zumindest in Free Pascal) ein boolean genau wie in C intern als ein Byte mit einem Wertebereich von 0 bis 255 repräsentiert. Das (und die Folgen davon) zeigt dieses Beispiel hier:
1 | var |
2 | i: integer; |
3 | pb: ^boolean; |
4 | b1, b2: boolean; |
5 | |
6 | begin |
7 | i := 12345; |
8 | pb := @i; |
9 | b1 := pb^; |
10 | |
11 | i := 23456; |
12 | pb := @i; |
13 | b2 := pb^; |
14 | |
15 | writeln('b1 = ', b1);
|
16 | writeln('b2 = ', b2);
|
17 | if b1 = b2 then |
18 | writeln('b1 und b2 sind gleich')
|
19 | else |
20 | writeln('b1 und b2 sind verschieden')
|
21 | end. |
Ausgabe:
1 | b1 = TRUE |
2 | b2 = TRUE |
3 | b1 und b2 sind verschieden |
Häh? Tatsächlich ist intern b1=57 und b2=160. Da beide Werte von 0 verschieden sind, werden sie – wie auch in C – als TRUE gewertet. Der Unterschied zwischen boolean in Pascal und _Bool (aka bool) in C besteht also einzig und allein darin, dass es in Pascal keine implizite Konvertierung von boolean nach integer gibt. Aber obwohl ich dir das schon im anderen Thread erklärt habe, verstehst du es offensichtlich immer noch nicht (oder willst es nicht verstehen). Im obigen Code ist die Art und Weise wie mit Zeigern umgegangen wird, natürlich maximal böse, aber interessanterweise winkt das der Compiler bei Verwendung der Defaultoptionen anstandslos durch. In C schmeißt einem der GCC für diesen groben Unfug mindestens eine Warnung entgegen. Wo ist denn die einst so vielgepriesene Typsicherheit von Pascal geblieben?
Ist aber doch viel lesbarer als in C!
Yalu X. schrieb: > Im obigen Code ist die Art und Weise wie mit Zeigern umgegangen wird, > natürlich maximal böse, aber interessanterweise winkt das der Compiler > bei Verwendung der Defaultoptionen anstandslos durch. > [...] > Wo ist denn die einst so vielgepriesene Typsicherheit von Pascal > geblieben? Durch die konstanten 12345 in deinem Beispiel könnte der Compiler zwar den ungültigen Wertebereich erkennen, aber bei praktischen Problemstellungen wäre das erst zur Laufzeit möglich. Was zusätzlichen Code, d.h. Performanceverlust bedeuten würde.
Maxe schrieb: > Durch die konstanten 12345 in deinem Beispiel könnte der Compiler zwar > den ungültigen Wertebereich erkennen Ich meinte nicht den Wertebereich, sondern die Datentypen, mit denen hier Schindluder getrieben wird, und zwar in den Zeilen 8 und 12:
1 | pb := @i; |
Hier wird ein Zeiger auf eine Integer-Variable einer Variablen vom Typ "Zeiger auf Boolean" zugewiesen. Konvertierungen zwischen verschiedenen Zeigertypen sind i.Allg. gefährlich und meist auch wenig sinnvoll. Eine Ausnahme stellt die Konvertierung eines Zeigers auf ein Objekt der Klasse C in einen Zeiger auf die Basisklasse von C dar. In Object Pascal wird defaultmäßig deswegen keine Warnung ausgegeben, weil @i kein Zeiger auf Integer, sondern ein typloser Zeiger (ähnlich einem void* in C) ist und ein typloser Zeiger implizit in jeden anderen Zeigertyp konvertiert werden kann. C würde sich ebenso verhalten, wenn der Adressoperator & implizit einen Cast nach (void *) enthalten würde. Das ist aber aus gutem Grund nicht der Fall. Warum es in Object Pascal so gemacht wird, kann ich beim besten Willen nicht nachvollziehen, da eine Konvertierung zwischen verschiedenen Zeigertypen, die in keiner Vererbungsrelation zueinander stehen, in 99.99% einen Fehler darstellt.
Yalu X. schrieb: > Ich meinte nicht den Wertebereich, sondern die Datentypen, mit denen > hier Schindluder getrieben wird, und zwar in den Zeilen 8 und 12: > >
1 | > pb := @i; |
2 | > |
> > Hier wird ein Zeiger auf eine Integer-Variable einer Variablen vom Typ > "Zeiger auf Boolean" zugewiesen. Da hast du Recht. Der Kompiler müsste das nicht so einfach durchgehen lassen. Es scheint bei Pascal die Grundannahme zu gelten, wer mit Pointern hantiert muss wissen was er tut. > Konvertierungen zwischen verschiedenen > Zeigertypen sind i.Allg. gefährlich und meist auch wenig sinnvoll. Eine > Ausnahme stellt die Konvertierung eines Zeigers auf ein Objekt der > Klasse C in einen Zeiger auf die Basisklasse von C dar. Im modernen Pascal ist der Einsatz von Pointern von Haus aus recht selten, da ja Arrays, Strings und Klassen ohne solche auskommen. Für dynamische Daten verwendet man Klassen, braucht sich also auch nicht mit Pointern aufzuhalten. Bleiben hauptsächlich Operationen auf Binärdatenfelder. Und da wird es mit Typsicherheit schon schwierig.
Jörg W. schrieb: > Dann stimme ich dir in folgender Aussage zu: "C hat keinen 'echten' > Boolean-Typ, und Pascal hat keine bitweisen Operatoren." Kannst du bitte nochmal kurz zusammenfassen, warum C keinen 'echten' Boolean-Typ hat? Ich konnte aus eurer Diskussion kein Kriterium ableiten, das für einen echten Boolen-Typ notwendig ist.
Klaus W. schrieb: > Ist aber doch viel lesbarer als in C! Nein. Yalu hat erfolgreich nachgewiesen, dass ein echter Programmierer in jeder Sprache C programmieren kann. Wenn man jedoch Pascal verwendet, um Pascal zu programmieren, wird es für noch nicht radikalisierte tatsächlich lesbarer. Vertrau mir. (Deswegen verwenden echte Programmierer kein Pascal: Sie möchten ihren Job ja auch nächste Woche noch haben... )
Maxe schrieb: > Im modernen Pascal ist der Einsatz von Pointern von Haus > aus recht selten, Kommt aber schon vor. Zugriffe über daten[i] sind fühlbar langsamer als über pointer^, weil bei daten[i] die Adresse jedesmal aus Startadresse des Feldes und Element-Index ausgerechnet wird. Deswegen beiße ich in der innersten Schleife gelegentlich in den sauren Apfel und verwende einen Pointer.
Ich habe zwar nichts beizutragen, aber ich verspreche mir morgen früh einen hohen Unterhaltungswert dieses Threads ab dieser Stelle.
Walter T. schrieb: > Ich habe zwar nichts beizutragen, aber ich verspreche > mir morgen früh einen hohen Unterhaltungswert dieses > Threads ab dieser Stelle. Unterhaltend ist es jetzt. Morgen früh ist hier zugesperrt, weil jemand unter dem Deckmantel der Meinungsfreiheit das Forum missbraucht, um seine Meinung über Pascal und C zu äußern.
Egon D. schrieb: > Morgen früh ist hier zugesperrt, weil jemand unter dem > Deckmantel der Meinungsfreiheit das Forum missbraucht, > um seine Meinung über Pascal und C zu äußern. Ein Satz zum Einrahmen. Keep up the good work! Bis morgen!
mh schrieb: > Ich konnte aus eurer Diskussion kein Kriterium ableiten, das für einen > echten Boolen-Typ notwendig ist. Das musst du schon W.S. fragen, denn von ihm war die Aussage ja.
Egon D. schrieb: > Yalu hat erfolgreich nachgewiesen, dass ein echter > Programmierer in jeder Sprache C programmieren kann. Naja, das sollte ja kein Beispiel für guten Programmierstil sein, sondern W.S: zeigen, dass ein boolean in Pascal – abgesehen von den nicht vorhandenen impliziten Typkonvertierungen – nichts anderes als das bool in C ist. Aber zum Thema "Pascal in C programmieren": Als ich das erste Mal etwas in Turbo Pascal programmieren durfte bzw. musste, war ich überrascht, wieviele C-Features da im Vergleich zum "echten" Pascal (das ich im Studium gelernt hatte) zur Verfügung standen. Plötzlich konnte man auch in Pascal Anwendungen für die reale Welt schreiben (und nicht nur für Übungsaufgaben an der Uni). Turbo Pascal war für mich deswegen fast so etwas wie C mit BEGIN und END. Andererseits konnte man sich damit – ähnlich wie in C – auch gewaltig ins Knie schießen, was ich aber in Kauf nahm (der Reset-Knopf am PC war immer in greifbarer Nähe). Da ich aber nicht primär auf MS-DOS-PCs arbeitete, ist es für mich mangels Verfügbarkeit bald wieder gestorben.
:
Bearbeitet durch Moderator
Maxe schrieb: > Im modernen Pascal ist der Einsatz von Pointern von Haus aus recht > selten, Gerade deswegen würde es nicht schaden, wenn der Compiler da etwas pingeliger wäre. Wenn man Zeiger nur selten braucht, braucht man Zeigerkonvertierungen noch seltener, weswegen es dem Programmierer durchaus zuzumuten wäre, solche Konvertierungen explizit zu machen. Egon D. schrieb: > Zugriffe über daten[i] sind fühlbar langsamer als über > pointer^, weil bei daten[i] die Adresse jedesmal aus > Startadresse des Feldes und Element-Index ausgerechnet > wird. > Deswegen beiße ich in der innersten Schleife gelegentlich > in den sauren Apfel und verwende einen Pointer. Siehst du, so etwas mache ich in C nicht, weil solche Dinge der Compiler sehr gut selber optimieren kann. Vielleicht ist ja am Ende doch C das bessere Pascal :)
Jörg W. schrieb: > mh schrieb: >> Ich konnte aus eurer Diskussion kein Kriterium ableiten, das für einen >> echten Boolen-Typ notwendig ist. > > Das musst du schon W.S. fragen, denn von ihm war die Aussage ja. Ich hatte gehofft, du verstehst es, da du ihm (eingeschränkt) zugestimmt hast. Was W.S. zu irgend etwas das C/C++ betrifft sagt, ist mir relativ egal. Es war deine Zustimmtung, die es Interessant gemacht hat.
mh schrieb: > Kannst du bitte nochmal kurz zusammenfassen, warum C > keinen 'echten' Boolean-Typ hat? Dafür gibt es zwei Gründe: 1. C hat ÜBERHAUPT keine echten Typen, das sind alles mehr so unverbindliche Empfehlungen. Daraus folgt zwanglos, dass es auch keinen echten Boolean-Typ geben kann. 2. Wenn man genau hinschaut, bemerkt der aufmerksame Betrachter ein meist totgeschwiegenes Detail: Es gibt in C ZWEI VERSCHIEDENE (informelle) "Typen" für boolsche Variablen: Ergebnisse boolscher Ausdrücke sind stets nur "0" oder "1" -- aber Steueranweisungen, die von einer logischen Bedingung abhängen, akzeptieren dagegen ganzzahlige "Bedingungen" mit der Zuordnung "gleich 0" für "falsch" und "ungleich 0" für "wahr". > Ich konnte aus eurer Diskussion kein Kriterium > ableiten, das für einen echten Boolen-Typ notwendig ist. "Sachkunde ist einer lebhaften Diskussion nur abträglich." C ist bedeutend besser als die üblichen Erklärungen und Erläuterungen zur Programmiersprache C. So könnte man ja einfach sagen, dass... 1. Vergleichs- und ähnliche Ausdrücke STETS nur "0" oder "1" als Ergebnis produziern, die somit als Wahrheitswerte aufzufassen sind, 2. bedingte Steueranweisungen (leider) die Schlamperei mit den ganzzahligen (statt booleschen) Bedingungen zulassen, 3. die Operatoren "||" und "&&" in der Regel bösartig irre- führend und falsch erklärt werden, weil es sich dabei keineswegs um abkürzende Auswertung boolescher Ausdrücke handelt, sondern um Auswertung erweiterter boolescher Ausdrücke. Aber DAS ware ja für mathematisch vorgebildete Leser leicht verständlich -- und geht also gar nicht... Frei nach Peter Altenberg: "In jeder Diskussion liegt etwas Tiefes, Wahres. Nur ist das nicht das, worum es in der Diskussion geht."
Egon D. schrieb: > [...] blubber [...] Dein Beitrag ist inhaltlich eng verwandt mit dem was W.S. gewöhnlich von sich gibt und legt nahe, dass du von C keine Ahnung hast. Es hat einen Grund, warum ich die Frage explizit an Jörg W. gerichtet habe. Seine Beiträge basieren auf echtem Wissen.
Yalu X. schrieb: > Egon D. schrieb: >> Yalu hat erfolgreich nachgewiesen, dass ein echter >> Programmierer in jeder Sprache C programmieren kann. > > Naja, das sollte ja kein Beispiel für guten Programmierstil > sein, Das hätte mich bei Dir auch gewundert :) (Ich wollte halt nur mal über das Stöckchen springen, das Klaus hingehalten hat... nur um in Übung zu bleiben.) > sondern W.S: zeigen, dass ein boolean in Pascal – abgesehen > von den nicht vorhandenen impliziten Typkonvertierungen – > nichts anderes als das bool in C ist. Naja, über echte oder unechte Typen in C zu diskutieren ist m.E. weitgehend nutzlos. Man müsste -- wenn überhaupt -- ändern, dass Ausdrücke wie "if (17)" vom Compiler akzeptiert werden, aber das hieße, die heilige Kuh der Kompatibilität zu schlachten. > Aber zum Thema "Pascal in C programmieren": > > Als ich das erste Mal etwas in Turbo Pascal programmieren > durfte bzw. musste, war ich überrascht, wieviele C-Features > da im Vergleich zum "echten" Pascal (das ich im Studium > gelernt hatte) zur Verfügung standen. Naja, das Problem an Standard-Pascal ist m.E., dass N. Wirth wie ein akademischer Prinzipienreiter agiert hat. Der Ansatz war ja gut -- aber er hatte offenbar kein Interesse an einer koordinierten Weiterentwicklung der Sprache, sondern hat sich alle Nase lang eine neue ausgedacht. Pech für alle seine Fans... > Plötzlich konnte man auch in Pascal Anwendungen für die > reale Welt schreiben (und nicht nur für Übungsaufgaben an > der Uni). Turbo Pascal war für mich deswegen fast so etwas > wie C mit BEGIN und END. Nach Z80-Assembler, ein wenig BASIC und einer frustrierenden Begegnung mit C (auf P8000, unter "WEGA"!) war TurboPascal auch mein nächster Schritt. Ich sehe das heute sehr ambivalent. Einerseits war ich sehr erpicht auf die "strukturierte Programmierung" -- ich wusste ja vom Assembler her, wie beschissen es ohne ist. Andererseits kann (konnte) man m.E. mit TurboPascal keine Systemprogrammierung machen, ohne zu wilden Hacks zu greifen, und das murksige MS-DOS als Unterbau... naja. Und so etwas wie eine "tool chain" gab es da auch nicht, also bin ich auf der Strecke weitgehend ahnungslos...
mh schrieb: > Egon D. schrieb: >> [...] blubber [...] > > Dein Beitrag ist inhaltlich eng verwandt mit dem was > W.S. gewöhnlich von sich gibt und legt nahe, dass du > von C keine Ahnung hast. Dann sei doch so gut zeige mit Zitat und (Gegen-)Argument, welche meiner Aussagen über C falsch sind. Vielen Dank im Voraus. > Es hat einen Grund, warum ich die Frage explizit an > Jörg W. gerichtet habe. Nun, ich kann nichts dafür, dass Du den Unterschied zwischen privater E-Mail und öffentlichem Diskussions- forum nicht kennst. Vielleicht lernst Du es ja noch irgendwann...
Yalu X. schrieb: > Egon D. schrieb: >> Zugriffe über daten[i] sind fühlbar langsamer als über >> pointer^, weil bei daten[i] die Adresse jedesmal aus >> Startadresse des Feldes und Element-Index ausgerechnet >> wird. >> Deswegen beiße ich in der innersten Schleife gelegentlich >> in den sauren Apfel und verwende einen Pointer. > > Siehst du, so etwas mache ich in C nicht, weil solche > Dinge der Compiler sehr gut selber optimieren kann. Ich verstehe offen gestanden auch nicht, warum der FreePascal-Compiler es nicht optimieren kann. Bei "-O3" ist er ziemlich clever, was arithmetische Sachen angeht; der Output ist da m.E. nahe am Optimum. Aber Feldzugriffe in einer for-Schleife werden prinzipiell als "Index holen, mit Elementgröße malnehmen, Basisadresse addieren" umgesetzt -- auch dann, innerhalb der Schleife nicht weiter an der Laufvariablen herumgefummelt wird. Verstehe nicht, warum der Compiler da keinen mitlaufenden Pointer verwenden kann (bzw. verwendet). > Vielleicht ist ja am Ende doch C das bessere Pascal :) Definiere "besser" :) Aber im Ernst: Ich sehe keinen Unterschied in der Sprache, der die Beobachtung rechtfertigt. Das ist m.E. eine rein technische Sache, also eine Frage der konkreten Implemen- tierung des Compilers. Feldzugriffe über den Index in for-Schleifen sind sowieso redundant. "foreach" wäre häufig viel praktischer...
Egon D. schrieb: > Man müsste -- wenn überhaupt -- > ändern, dass Ausdrücke wie "if (17)" vom Compiler akzeptiert > werden, aber das hieße, die heilige Kuh der Kompatibilität > zu schlachten. Das wäre vermutlich dann das, was W.S. unter "echtem Boolschen Typen" verstehen würde. Im Prinzip ließe sich das sogar im C-Standard unterbringen: man könnte, nachdem es _Bool ja nun schon mehr als 20 Jahre lang gibt, auch festlegen, dass die Steuerausdrücke nach if, while etc. von ebendiesem Typ sind. Da C ja trotzdem auch implizite Typumwandlungen kennt, wäre ein "if (42)" dann mit einer impliziten Typumwandlung von "int" nach "_Bool" verbunden, für die der Compiler natürlich freizügig eine Warnung erzeugen kann. Die Frage ist nur: außer, dass W.S. das dann vielleicht als "echten Boolschen Typen" akzeptieren könnte, welches reale Problem wäre damit gelöst? Also, warum genau sollte man solche Klimmzüge machen? Es ist ja nun nicht so, dass die derzeitige Lösung eine fundamentale Schwachstelle der C-Sprachdefinition wäre, die vielleicht zu massenhaft Sicherheitsproblemen führt oder dergleichen. Außer, dass es dann besser der "reinen Lehre" genügt, wäre rein gar nichts damit gewonnen. Daher wird sich wohl keiner die Mühe machen, sowas in den Standard überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich da eher mit real existierenden Problemen herum und einer Lösung dafür.
Egon D. schrieb: > 1. C hat ÜBERHAUPT keine echten Typen, das sind alles > mehr so unverbindliche Empfehlungen. Daraus folgt > zwanglos, dass es auch keinen echten Boolean-Typ > geben kann. Doch, und das bemerkst Du spätestens dann, wenn der Compiler Dir wegen pointer aliasing auf verschiedene Typen Dein Programm wegoptimiert.
Jörg W. schrieb: > Daher wird sich wohl keiner die Mühe machen, sowas in den Standard > überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich > da eher mit real existierenden Problemen herum und einer Lösung dafür. Die Leute aus der Compiler- und Tooling-Ecke würden sich sicher über die zusätliche Arbeit freuen, die diese Änderung verursachen würde. Dieses "Problem" hat anscheinend auch niemand als wichtig genug (oder als Problen überhaupt) eingestuft, um eine entsprechende Warnung in den gcc einzubauen.
Jörg W. schrieb: > Die Frage ist nur: außer, dass W.S. das dann vielleicht als "echten > Boolschen Typen" akzeptieren könnte, Ach nö, so nicht, mein Lieber. Du hast mit Behauptungen angefangen (wie z.B. daß es in Pascal keine oder nur rudimentäre boolsche Algebra gäbe oder daß C seit Jahren eine echten boolean Typ hätte), die allesamt sachlich unrichtig sind und ich habe versucht, es dir zu erklären, so daß du in die Lage kommst, das Ganze zu verstehen. Es ist mein Versuch, dich aus dem Brunnen zu fischen, in den du hineingefallen bist. Ich selber komme auch so mit C klar und habe für mich keinen Bedarf an blöden Bemerkungen anderer, die zwar ebenfalls in denselben Brunnen gefallen sind wie du, es aber noch nicht gemerkt haben. Was mich allerdings stört, ist der Gedanke, daß wenn andere Leute hier mitlesen und von euch völlig falsche Dinge gesagt bekommen, sie damit etwas Falsches lernen. Um das Ganze mal abzukürzen: In C sieht es so aus, daß eigentlich alles außer Gleitkomma in den numerischen Bereich der Integerzahlen projiziert wird. Boolean wird zu einem Integer des Bereiches 0..1, Textzeichen werden ebenfalls zu Integers mit dem Bereich 0..255 oder -128..+127 je nachdem, ob man ein Textzeichen nun als vorzeichenbehaftet ansehen will oder nicht, na und so weiter. Ich stelle mir grad vor, wie Jörg ein großes 'A' auf sein Blatt Papier mit dem Bleistift schreibt und dann darüber grübelt, woran man dessen Vorzeichen erkennen kann. Apropos Textzeichen: Bitte mal das Alphabet aufsagen. So, wie wir es gelernt haben, beginnt es mit A B C und so weiter. Das heißt, wenn wir uns die Ordnungszahl des A in unserem Alphabet näher anschauen, stellen wir fest, daß das A die Nummer 1 ist, denn das Alphabet beginnt mit damit. Wenn wir uns hingegen das ASCII-Alphabet anschauen, dann hat dort das A die Ordnungszahl 65 (wenn ich mich nicht grad verzählt habe) und wenn wir die Alphabete anderer Kulturkreise anschauen, wo die Textzeichen eine ganze Silbe oder gar ein ganzes Wort darstellen, dann erkennen wir, daß Textzeichen eben keine Integers sind, sondern deren Ordnungszahl sich nur aus dem gerade verwendeten Alphabet ergibt. Textzeichen sind keine Rechengrößen und Vergleiche zwischen Textzeichen können deshalb nur auf Gleichheit oder Ungleichheit gemacht werden. Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner) funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet. Man kann zwar damit zurechtkommen, daß ein char in C im wesentlichen ein numerischer Typ ist (mit oder ohne Vorzeichen), aber daß das ganze Konstrukt an der Realität vorbei geht und sachlich falsch ist, sollte man sehen können. Natürlich kann man alles zusammen in den Topf werfen, man muß allerdings mit den Folgen leben, die es nach sich zieht: Dann muß man hinterher sich Regeln einfallen lassen, um die zusammengerührten Dinge wieder auseinander zu kriegen. Und so muß man sich in C z.B. zwei Stück UND einfallen lassen, eines für das bitweise Und-Verknüpfen von Integers und ein anderes für die logische Verknüpfung. Und so weiter. Jedes "if (A)..." ist eigentlich ein "if (A!=0)..." - aber das so zu schreiben wäre dem durchschnittlichen C Programmierer ja zu buchstabenreich aber es wäre eine der Vorarbeiten, um einen Boolean Typ in C einzuführen. Und mehr als Faulheit vermag ich in solcher Schreibweise nicht zu sehen. Benutze solches Geschreibe in C ja selber. Aber im Gegensatz zu euch mache ich mir dabei nix vor. W.S.
mh schrieb: > Jörg W. schrieb: >> Daher wird sich wohl keiner die Mühe machen, sowas in den Standard >> überhaupt nur vorzuschlagen. Die Damen und Herren der WG14 schlagen sich >> da eher mit real existierenden Problemen herum und einer Lösung dafür. > > Die Leute aus der Compiler- und Tooling-Ecke würden sich sicher über die > zusätliche Arbeit freuen, die diese Änderung verursachen würde. Die sitzen eh (zumindest zu einem Teil) mit in der WG14. Vermutlich ist dort das Problem aber gar nicht so groß. Die Einführung eines _Bool (der nur die Werte false und true hat) haben sie ja auch mitgetragen. W.S. schrieb: > Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner) > funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet. Wobei das lateinische Alphabet (als Basis-Zeichensatz) letztlich in jeder Sprache, welche diese Zeichen nutzt, die Ordnung von 'A' nach 'Z' bzw. 'a' nach 'z' hat. Außerdem gibt es noch eine Ordnung von '0' bis '9'. Das sind die einzigen implizierten Bedingungen für Textzeichen im C-Standard. Insbesondere hatte man damit ja auf EBCDIC Rücksicht zu nehmen, bei dem bspw. die Buchstaben nicht lückenlos aufeinander folgen. Andere Alphabete lassen sich auf diese Weise logischerweise nicht abbilden und werden auch nicht abgebildet. Die Frage, ob ein 'Л' nun also kleiner oder größer als ein 'L' ist, ist von diesem Standard nicht definiert worden, und du hast ja dargelegt, dass eine solche Definition auch keinen Sinn hätte.
Jörg W. schrieb: > Wobei das lateinische Alphabet (als Basis-Zeichensatz) letztlich in > jeder Sprache, welche diese Zeichen nutzt, die Ordnung von 'A' nach 'Z' > bzw. 'a' nach 'z' hat. Außerdem gibt es noch eine Ordnung von '0' bis > '9'. Das sind die einzigen implizierten Bedingungen für Textzeichen im > C-Standard. Insbesondere hatte man damit ja auf EBCDIC Rücksicht zu > nehmen, bei dem bspw. die Buchstaben nicht lückenlos aufeinander folgen. Das ist auch in Pascal so und sogar im ISO-Standard festgeschrieben. Und wenn W.S. behauptet, in Pascal sei für Textzeichen kein Vergleich auf größer oder kleiner möglich W.S. schrieb: > Textzeichen sind keine Rechengrößen und Vergleiche zwischen Textzeichen > können deshalb nur auf Gleichheit oder Ungleichheit gemacht werden. > Jegliche weiterführenden mathematischen Vergleiche (größer oder kleiner) > funktionieren nur mit der Ordnungszahl in einem bestimmten Alphabet. dann zeigt er damit nur, dass er nicht nur von C, sondern auch von Pascal keine Ahnung hat :) Mich erinnert W.S. ein wenig an Moby, der immer als der ganz große AVR-Assemblergott dastehen wollte, bis sich irgendwann herausstellte, dass er nicht einmal den EOR-Befehl kannte.
Jörg W. schrieb: > Egon D. schrieb: >> Man müsste -- wenn überhaupt -- ändern, dass >> Ausdrücke wie "if (17)" vom Compiler akzeptiert >> werden, aber das hieße, die heilige Kuh der >> Kompatibilität zu schlachten. > > Das wäre vermutlich dann das, was W.S. unter "echtem > Boolschen Typen" verstehen würde. Vermutlich -- und ich kann dieser Logik durchaus folgen. > Im Prinzip ließe sich das sogar im C-Standard unterbringen: > man könnte, nachdem es _Bool ja nun schon mehr als 20 Jahre > lang gibt, auch festlegen, dass die Steuerausdrücke nach > if, while etc. von ebendiesem Typ sind. Da C ja trotzdem > auch implizite Typumwandlungen kennt, wäre ein "if (42)" > dann mit einer impliziten Typumwandlung von "int" nach > "_Bool" verbunden, für die der Compiler natürlich freizügig > eine Warnung erzeugen kann. Mal schauen... vielleicht erlebe ich das noch. Wer warten kann, erlebt fast alles. Bei der Pointerarithmetik in Pascal hat es ja schon funktioniert... > Die Frage ist nur: außer, dass W.S. das dann vielleicht als > "echten Boolschen Typen" akzeptieren könnte, welches reale > Problem wäre damit gelöst? Also, warum genau sollte man > solche Klimmzüge machen? Naja, wie so oft ist der Sprachstandard klüger als viele der Leute, die ihn anwenden oder erklären (Anwesende natürlich ausgenommen). Der Standard VERBIETET es ja nicht, die korrekte Langform zu schreiben -- nur übertrumpfen sich die C-Tutorien gegenseitig mit Hinweisen "'xyz' kann auch kürzer als 'q' geschrieben werden", "'abc' kann an dieser Stelle weggelassen werden", statt sich erstmal auf die Langform zu beschränken, die immer stimmt und immer funktioniert. Die derart zur Schlampigkeit erzogenen Nachwuchsprogrammierer werden dann in der zweiten Runde mit MISRA geelendet, um ihnen wenigstens eine minimale Korrektheit im Ausdruck einzubläuen. Könnte man auch irgendwie einfacher haben...
Yalu X. schrieb: > Und wenn W.S. behauptet, in Pascal sei für Textzeichen > kein Vergleich auf größer oder kleiner möglich [...] Leider hat er das gar nicht behauptet. Seine Aussagen sind: 1. Buchstaben sind keine Zahlen. 2. Eine Ordnungsrelation in der Menge der Buchstaben gilt immer nur in einem m.o.w. willkürlichen Alphabet. Beide Aussagen sind richtig -- also in der wirklichen Welt, meine ich. In C ist (war) die erste Aussage "selbstverständlich" falsch; wer eine kleine Ganzzahl vereinbaren wollte, verwendete "char". Muss man nicht verstehen. > Mich erinnert W.S. ein wenig an Moby, der immer als > der ganz große AVR-Assemblergott dastehen wollte, [...] Mich nicht. Mich erinnern im Gegenteil die Programmierer, die es empört von sich weisen, als Ingenieure angesehen zu werden, weil sie ja freischaffende Heroen der Mathematik-Kunst seien, an die Halbstarken auf dem Schulhof, die zwar markige Sprüche klopfen können, aber von Tuten und Blasen keine Ahnung haben: C verwendet zwar mathematische Begriffe, tut dies aber auf eine Weise, die jedem sorgfältigen mathematisch geschulten Geist die Zornesröte ins Gesicht treibt -- und wenn man diese Vergewaltigung von Begriffen kritisiert, wird man als dumm und ignorant angepflaumt, weil man "ja überhaupt keine Ahnung von C" hat. Liebe Leute: Das Problem ist nicht C. C ist gar nicht SO schlecht, wie es von seinen Kritikern häufig gemacht wird. Das Problem sind die C-Missionare.
W.S. schrieb: > Ach nö, so nicht, mein Lieber. Du hast mit Behauptungen > angefangen (wie z.B. daß es in Pascal keine oder nur > rudimentäre boolsche Algebra gäbe Hat er nicht. Der Kern seiner Aussage war nach meinem Verständnis: "WENN man kritisiert, dass in C Wahrheitswerte (die eigentlich 'boolesch' sein müssten) durch kleine Ganzzahlen (Bereich 0..1) dargestellt werden, DANN müsste man eigentlich auch kritisieren, dass man in Pascal boolesche Operationen auf Ganzzahlen anwenden kann. Beides ist eine Verletzung des Typsystems." Die Aussage ist m.E. richtig. In keiner mir bekannten Arithmetik der Welt ist ein bitweises XOR (oder AND oder... usw.) definiert. Das sind Operationen der BOOLESCHEN Algebra -- keine arithmetischen Operationen über Zahlen! Für die mathematisch korrekte Implementierung von bitweisen booleschen Verknüpfungen müsste es einen Bitvektortyp geben -- den es in Pascal aber m.W. nicht gibt. Pech für die Kuh Elsa. Die Kritik ist korrekt -- und für mich überraschend; sie zeigt, wie sehr man sich an bestimmte Dinge gewöhnt. Balken, Splitter, und so... > oder daß C seit Jahren eine echten boolean Typ > hätte), Das ist unfair. Du hast Dich, soweit ich sehe, darüber ausgeschwiegen, was Du unter einem echten booleschen Typ verstehen willst -- im Gegensatz zu einem unechten. Auf meinen Deutungsvorschlag, dass es inkonsistent ist, wenn "boolesche" FUNKTIONSWERTE einen anderen Wertebereich haben wie "boolesche" ARGUMENTE, ist Jörg ja eingegangen und hat dem implizit zugestimmt. Das ist auch die einzige Sicht, die für mich Sinn gibt. > Und so muß man sich in C z.B. zwei Stück UND einfallen > lassen, eines für das bitweise Und-Verknüpfen von > Integers und ein anderes für die logische Verknüpfung. Immer wieder gern genommen... :) Stimmt aber so nicht. Hat Jörg auch schon erklärt: Wenn man immer korrekte, vollständige boolesche Ausdrücke baut, erhält man im Prinzip auch mit den Bit-Operatoren korrekte Resultate -- wenn das Problem mit der Auswertungsreihenfolge nicht wäre. Letzteres lösen "&&" und "||"; die Beschränkung auf 0/1 ist nur willkommener, aber verzichtbarer Nebeneffekt.
der Standard IST Turbo Pascal / Delphi!! Das hat mit Wildwuchs nichts zu tun. Alles richtet sich daran aus, und es spricht nichts dagegen, wenn Freepascal noch Erweiterungen anbietet, dennoch ist es kompatibel zu Turbo Pascal/Delphi Die, die immer wegen Standards rumheulen, Linux wäre tod, mit diesem Argument. Da klammert sich auch niemand an Standards fest Dieses Argument von Pascal Standards nervt nur und ist immer wieder schlicht falsch. Jeder der mit Pascal arbeitet weiß das > Ich schrieb absichtlich von Standard-Pascal. Dass es bei Pascal offenbar > nur Wildwuchs gibt (zwei Standards, an die sich keiner halten mag), ist > ja nun eher kein positives Markenzeichen. >
Peter K. schrieb: > der Standard IST Turbo Pascal / Delphi!! Da fehlt noch mindestens ein Ausrufezeichen. :-)) Das ist dann in etwa der Zustand, den C vor 1989 hatte, als sich alles nach den Beschreibungen von K&R ausgerichtet hat. Kann man gut finden, muss man nicht. > Die, die immer wegen Standards rumheulen, Linux wäre tod, mit diesem > Argument. > Da klammert sich auch niemand an Standards fest Linux hält sich durchaus an den zugehörigen Standard (IEEE 1003.2), andere unixoide Systeme auch, und der entsprechende Standard wird auch kontinuierlich weiter entwickelt. > Dieses Argument von Pascal Standards nervt nur und ist immer wieder > schlicht falsch. Also erfreuen wir uns dann daran, dass das Kurzschlussverhalten logischer Operatoren per Compileroption zu- oder abwählbar ist. Schrieb da oben jemand was wegen einer heiligen Kuh der Rückwärtskompatibilität? :-} Mir ist echt nicht klar, wofür zum Geier™ man logische Operatoren ohne Kurzschlussverhalten brauchen würde. Das war zu den Zeiten, als ich noch recht aktiv Pascal programmiert habe (und das war damals eben nicht nur Turbo-Pascal), immer völlig nervig, dass man if ... then if ... then schreiben musste, wenn man sicherstellen wollte, dass der zweite Ausdruck auch wirklich erst dann bewertet worden ist, wenn der erste erfolgreich war.
tatsächlich finde ich es schade, das der Thread leider durch sinnlose Diskussionen kaputtgemacht wird und anstatt das der Mod diese Diskussion beendet oder Beiträge löscht, sich sogar noch daran beteiligt:-( Naja, immerhin hat es der Thread einige Zeit Geschafft seinen Sinn zu erfüllen. Ich merke mir ledier nicht alle Quellen..aber das Arguemtn mit den fehlenden Standards bei Linux ist stichhaltig, genauso wie Linux selber sagte, das Linux noch lange nicht für den Einsatz auf dem Desktop taugt für die Normalanwender weil es viel zu Frickelig ist. Wenn das selbst der Erfinder von Linux sagt, verstehe ich nicht weshalb viele diese Aussage immer so aufregt. Alles braucht nun mal seine Zeit Und genau wie C ist auch Pascal in den Jahren gereift und besser geworden. Und mit Turbo Pascal 7 oder Freepascal und Delphi gibt es eine super Oberfläche . Und klar kann man auch C oder C++ nehmen. Nur geht es darum in diesem Thread überhaupt nicht sondern es soll lediglich aufzeigen, das Pascal erheblich aktiver sit als viele denken Und diese Aussage ist halt auch interessant, wie gesagt. "Delphi and Freepascal is different in more ways than one, but beyond language compatibility there is one aspect that is quintessential for them both; namely their role in the commercial sector. Where other languages, like C/C++ or (for example) JavaScript see a lot of open-source activity, especially with regards to Linux and Node.js – Delphi and Freepascal are predominantly used to write high-quality, commercial, closed source business applications. In other words, the vast majority of code produced by the millions of Object Pascal developers around the world – is never publicly committed to GitHub or BitBucket."
Peter K. schrieb: > Nur geht es darum in diesem Thread überhaupt nicht sondern es soll > lediglich aufzeigen, das Pascal erheblich aktiver sit als viele denken Naja, darum ging es mal vor zwei Jahren. Damit auch niemand denkt, es sei Ruhe rein gekommen, muss aber immer mal wieder jemand den Thread mit neuen Beweisen hervor holen. (Vermutlich sind das nicht die Leute, die Pascal aktiv und gern benutzen, die werden besseres zu tun haben.) Das Argument, Pascal-Programme wären nur wenig im Opensource-Bereich zu sehen und mehr im kommerziellen Bereich unterwegs, wurde ja nun auch schon mehr als einmal genannt. Es ignoriert natürlich, dass auch die Masse an anderer Software ganz sicher kein Opensource ist, das ist also keineswegs ein Alleinstellungsmerkmal von Pascal-Programmen.
ist sollte ein fortlaufender Thread sein, der immer ergänzt wird. Aber das wird gerade zunichte gemacht
Peter K. schrieb: > ist sollte ein fortlaufender Thread sein, der immer ergänzt wird Wofür denn aber eigentlich? Ego-boosting? "Ich habe doch die richtige Programmiersprache gewählt?" Ein wirklicher Sinn dahinter ist mir nicht klar. Es gibt doch auch für andere Programmiersprachen keine Threads "Projekt XXX benutzt YYY". Keiner zweifelt an, dass Pascal (in der einen oder anderen Form) Verwendung findet. Wenn es das nicht wäre, wären die entsprechenden Compiler-/IDE-Projekte schon längst eingeschlafen. Dass es nicht noch stärker Verwendung findet, hat diverse Gründe, aber das wird sich auch durch einen solchen Tread sicher kaum verbessern.
:
Bearbeitet durch Moderator
Irgendwie hat dich die Sinnfrage gar nicht zu interessieren, darum geht es in diesem Thread schlicht überhaupt nicht Es geht auch nicht darum etwas zu verbessern!!! Wenn du wissen willst, welchen Sinn er hat, dann lies den Eingangspost!! Ein Forum dient unter Anderem dem Austausch, der Informations und Meinungsbildung etc. Das kann Abhängig vom Forenthema sein Aber ich sehe schon wohin das hier wieder führt, und für diese Art der Moderation ist das Forum bzw. die Moderatoren hier ja bekannt Schwachsinnige Posts wie diese Beitrag "Was ist das?" sind in diesem Forum offenbar besser aufgehoben Und das permanente Störer wie der Cyblord nicht gesperrt werden, obwohl es mehrere Threads mit der Diskussion warum er nicht gesperrt wird seit 2014 gibt, erschließt sich mir auch nicht, zeigt aber sehr gut, was in diesem Forum schief läuft Ich bin hier raus und werde diesen Thread nicht mehr weiterführen.
Egon D. schrieb: > Yalu X. schrieb: > >> Und wenn W.S. behauptet, in Pascal sei für Textzeichen >> kein Vergleich auf größer oder kleiner möglich [...] > > Leider hat er das gar nicht behauptet. > > Seine Aussagen sind: > 1. Buchstaben sind keine Zahlen. > 2. Eine Ordnungsrelation in der Menge der Buchstaben > gilt immer nur in einem m.o.w. willkürlichen Alphabet. > > Beide Aussagen sind richtig -- also in der wirklichen > Welt, meine ich. Ok, vielleicht habe ich in seine Aussagen zuviel hineininterpretiert. Da es in dem Thread aber um Pascal geht und W.S. in allen seinen Beiträgen bestrebt ist, die Vorzüge von Pascal gegenüber C herauszustellen, bin ich davon ausgegangen, dass auch seine Ausführungen zu Alphabeten und Ordnungszahlen diesem Zweck dienen. In diesem Kontext habe ich seine Aussagen wie folgt interpretiert: W.S. schrieb: > dann erkennen wir, daß Textzeichen eben keine Integers sind, Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal nicht. Deswegen ist C schlecht und Pascal gut. Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache. > Textzeichen sind keine Rechengrößen Interpretation: In C sind auf char Rechenoperationen erlaubt, in Pascal nicht. Deswegen ist C schlecht und Pascal gut. Das ist nur teilweise richtig, denn auch in Pascal kann mit char gerechnet werden. wenn auch nur sehr eingeschränkt. Mit inc ist nämlich eine Addition mit einem Integer definiert. Beispiele: inc('A') -> 'B', inc('A', 4) -> 'E'. Man muss also nicht chr(ord('A')+4) schreiben, wie es W.S. wohl vorschwebt. > und Vergleiche zwischen Textzeichen können deshalb nur auf Gleichheit > oder Ungleichheit gemacht werden. Jegliche weiterführenden > mathematischen Vergleiche (größer oder kleiner) funktionieren nur mit > der Ordnungszahl in einem bestimmten Alphabet. Interpretation: In C sind sind > und < auf char erlaubt, in Pascal nicht. Deswegen ist C schlecht und Pascal gut. Das stimmt definitiv nicht, denn auch in Pascal ist das erlaubt. Beispiele 'A'>'B' -> false, 'A'<'B' -> true. Man muss also nicht ord('A')<ord('B') schreiben, wie es W.S. wohl vorschwebt. Meine Vermutung, dass es W.S. mit den vorangegangenen Aussagen tatsächlich um den Vergleich Pascal<->C ging, wird durch den folgenden Nachsatz erhärtet: > Man kann zwar damit zurechtkommen, daß ein char in C im wesentlichen > ein numerischer Typ ist (mit oder ohne Vorzeichen), aber daß das ganze > Konstrukt an der Realität vorbei geht und sachlich falsch ist, sollte > man sehen können. Wie ich schon mehrfach schrieb, liegen Pascal bzw. Object Pascal und C bzw. C++ in ihrer jeweiligen heutigen Ausprägung gar nicht mehr so weit auseinander.
Yalu X. schrieb: > Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal > nicht. Deswegen ist C schlecht und Pascal gut. > > Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache. Tja, der erste Satz ist von mir, der zweite Satz ist von dir. Das macht den Unterschied. W.S.
W.S. schrieb: > Yalu X. schrieb: >> Interpretation: In C gehört char zur Gruppe der Integertypen, in Pascal >> nicht. Deswegen ist C schlecht und Pascal gut. >> >> Mit dem ersten Satz hat er recht, der zweite ist Geschmackssache. > > Tja, der erste Satz ist von mir, der zweite Satz ist von dir. Ach so, du behauptest also gar nicht, dass Pascal "besser" (in welcher Hinsicht auch immer) als C sei? Super, dann war das wohl ein Missverständnis meinerseits, und wir können die Diskussion beenden.
Yalu X. schrieb: > Da es in dem Thread aber um Pascal geht und W.S. in > allen seinen Beiträgen bestrebt ist, die Vorzüge von > Pascal gegenüber C herauszustellen, ...was ich für legitim halte... :) > bin ich davon ausgegangen, dass auch seine Ausführungen > zu Alphabeten und Ordnungszahlen diesem Zweck dienen. Selbstverständlich. > W.S. schrieb: >> dann erkennen wir, daß Textzeichen eben keine Integers >> sind, > > Interpretation: In C gehört char zur Gruppe der > Integertypen, in Pascal nicht. Deswegen ist C schlecht > und Pascal gut. > > Mit dem ersten Satz hat er recht, der zweite ist > Geschmackssache. Das ist unstrittig. >> Textzeichen sind keine Rechengrößen > > Interpretation: In C sind auf char Rechenoperationen > erlaubt, in Pascal nicht. Deswegen ist C schlecht und > Pascal gut. > > Das ist nur teilweise richtig, denn auch in Pascal kann > mit char gerechnet werden. wenn auch nur sehr eingeschränkt. > Mit inc ist nämlich eine Addition mit einem Integer > definiert. Beispiele: inc('A') -> 'B', inc('A', 4) -> 'E'. > Man muss also nicht chr(ord('A')+4) schreiben, wie es W.S. > wohl vorschwebt. Meine Überraschung ist Dir sicher. Das habe ich auch nicht gewusst. A propos "definiert": Schätzungsweise kann man aus mathematischer Sicht auf jeder endlichen geordneten Menge "rechnen", da sich diese auf eine passende Teilmenge der natürlichen bzw. ganzen Zahlen abbilden lässt. Ob eine Programmiersprache jedoch solche "Rechnungen" zulassen sollte, ist eine andere Frage. Oder welcher Sinn ist dem Ausdruck
1 | "x" % "N" |
zuzuordnen? >> und Vergleiche zwischen Textzeichen können deshalb nur >> auf Gleichheit oder Ungleichheit gemacht werden. Jegliche >> weiterführenden mathematischen Vergleiche (größer oder >> kleiner) funktionieren nur mit der Ordnungszahl in einem >> bestimmten Alphabet. > > Interpretation: In C sind sind > und < auf char erlaubt, > in Pascal nicht. Deswegen ist C schlecht und Pascal gut. Hmm. Nee. Das habe ich anders aufgefasst. W.S. argumentiert (auch in den hier nicht zitierten vorhergehenden Sätzen) im Kern so, dass sich die "Zahl"- Eigenschaft der Buchstaben auf die m.o.w. willkürlich zugewiesene Platznummer (Ordinalzahl) in einem Alphabet beschränkt. Der Vergleich des üblichen deutschen Alphabetes mit z.B. ASCII lehrt aber, dass ein und dieselbe Reihen- folge der Buchstaben (=Ordnungsrelation) mittels gänzlich verschiedener Zahlen ausdrücken lässt! Dass sich eine Ordnungsrelation in einer (ansonsten beliebigen endlichen) Menge über Zahlen ausdrücken lässt, die den Elementen der Menge zugeordnet werden, heisst aber nicht, dass die Elemente dieser -- nunmehr geordneten -- Menge plötzlich Zahlen sind ! In C ist das aber so. Oder sind -- das sind jetzt meine Worte -- "Q" und "d" Quadrat-Buchstaben, weil zufällig ASCII("Q")=81 und ASCII("d")=100 gilt? > Das stimmt definitiv nicht, denn auch in Pascal ist das > erlaubt. Beispiele 'A'>'B' -> false, 'A'<'B' -> true. > Man muss also nicht ord('A')<ord('B') schreiben, wie es > W.S. wohl vorschwebt. Was Du hier schreibst, ist zwar eine völlig geradlinige Zuspitzung seiner Argumentation, aber ich habe bei ihm nicht herausgelesen, dass er das tatsächlich in dieser zugespitzten Form behauptet bzw. gefordert hätte. Ebensogut könnte man '>' und '<' als überladene Operatoren auffassen, die für Druckzeichen halt "steht im Alphabet nach" bzw. "steht im Alphabet vor" bedeuten... :) > Wie ich schon mehrfach schrieb, liegen Pascal bzw. > Object Pascal und C bzw. C++ in ihrer jeweiligen > heutigen Ausprägung gar nicht mehr so weit auseinander. Unbestritten. Dennoch bleibt bei mir der Eindruck, dass bei (einer bestimmten Gruppe von) C-Anwendern eine bestimmte logische und begriffliche Schlampigkeit aggressiver und lautstärker als integraler Bestandteil echten Könnertums verteidigt wird, als das im Pascal-Lager der Fall ist. Der für mich deutlich erlebbare Nachteil dieser Schlampigkeit ist, dass es dem Lernenden schwerer gemacht wird, als es der Sache nach sein müsste.
Egon D. schrieb: > Dennoch bleibt bei mir der Eindruck, dass bei (einer > bestimmten Gruppe von) C-Anwendern eine bestimmte > logische und begriffliche Schlampigkeit aggressiver > und lautstärker als integraler Bestandteil echten > Könnertums verteidigt wird, als das im Pascal-Lager > der Fall ist. Naja, "bestimmte Gruppen" wirst du wohl immer finden. ;-) Es gibt auch Leute, die sich über die Kryptizität einer Perl-Syntax aufregen und dann in Python "aus Optimierungsgründen" alles mit Lambdas und allen möglichen andere Tricks in eine Zeile quetschen müssen. Aber man sollte sich wohl nicht an schlechten Beispielen orientieren sondern eher an den guten, denke ich.
Egon D. schrieb: > Liebe Leute: Das Problem ist nicht C. C ist gar nicht SO > schlecht, wie es von seinen Kritikern häufig gemacht wird. > > Das Problem sind die C-Missionare. Besser hätte man es nicht formulieren können.
Hallo, Egon D. schrieb: > Das Problem sind die C-Missionare. Und die Pascal-Missionare. Und Rust-Missionare. Und Python-Missionare. Und ... Oder allgemein: "Hüte dich vor Sturm und Wind und Menschen, die fanatisch sind" rhf
@Jörg: Zu dem (nicht) statisch gelinkten QT: Normalerweise reicht es doch die DLLs im selben Ordner zu haben und dann braucht man keinen Installer (der die irgendwo unter $WINDOWS\system ablegt), oder irre ich mich da? Zu VisualBasic & deiner Tek2USB Anwendung: Das halte ich für gar nicht so abwegig. FreeBASIC und Gambas können anscheinend beide mit libusb umgehen. Nicht dass ich davon Ahnung hätte, das sagten mir jeweils die drei ersten Google-Ergebnisse. Ich kann Installer für solche kleinen Dinge auch nicht ab. Mit SDL und Dev-C++ hatte ich auch schon meine Problemchen und hab letztendlich die DLLs mitgeben müssen - solange man die im Programmordner hält, umgeht man auch (mehr oder weniger) die Höllenkreise.
Keiler schrieb: > Zu dem (nicht) statisch gelinkten QT: > Normalerweise reicht es doch die DLLs im selben Ordner zu haben und dann > braucht man keinen Installer (der die irgendwo unter $WINDOWS\system > ablegt), oder irre ich mich da? Weiß nicht, irgendwas ging da nicht oder wie auch immer, ist auch lange her. > Zu VisualBasic & deiner Tek2USB Anwendung: > Das halte ich für gar nicht so abwegig. FreeBASIC und Gambas können > anscheinend beide mit libusb umgehen. Naja, am Ende hat sich der Betreffende sowieso durchgerungen, seinen Lab-PC mal auf Windows 10 hochzurüsten, und er hat auch einen anderen Weg gefunden, die Daten da einzulesen. Den anderen Tek492 habe ich inzwischen an meine alte Firma verkauft, und die haben das Qt-GUI dann unter Linux in Betrieb genommen.
Das Thema ist zwar schon alt - dennoch aktuell. Ich hatte früher mit Clipper gearbeitet. Ab 1999 dann mit Delphi und seit neuestem mit Lazarus. Manchmal wurde ich belächelt - Was mit Clipper und mit dbf Tabellen ! Waren da die Sprüche. Doch eines ist Tatsache: Kunden die um 1990 mein Programm (Clipper und dbf) gekauft hatten die haben bis heute (ja 24.Juli 2022) alle Daten noch. Ich war nie ein Komponenten Enwickler - ich habe Software für normale Benutzer gemacht die vielfach das erste mal mit einem PC in Berührung kamen - und sie konnten sofort produktiv damit arbeiten. Meiner Ansicht nach ist es irrelevant in was die Anwendung geschieben ist. Relevant ist des Kunden Zufriedenheit im Bezug auf Stabilität Gechwindigkeit und Kontinuität. Die klare Struktur und der unkomplizierte Aufbau hilft bei der Weiterentwicklung und einer Portierung immens. Ich bin nun 74 und habe wieder begonnen, diesmal mit Lazarus und SQLite. Mit meinen eigenen Regeln die ich mir schon immer auferlegt habe: Wers wissen will: 1. bevor ich begonnen habe für Windows Apps zu schreiben habe ich das "Normenbuch" von Microsoft angesehen. 2. Meine ersten Programmieraufgaben waren in Assembler 8080, 8085, Z80 etc. Und die Datenspeicherung erfolgte auf Tonband, das Programm war 100m lang - ja auf Lochstreifen, dann auf Karten. Da hat man gelernt auf Effizienz zu achten. 3. Meine eigenen Regeln im Programm - eine Struktur zB auch mit den Variablen, Dateibezeichungen etc.. Ich kann meine Programme von 1985 noch lesen und problemlos verstehen. Ich hatte einmal was zu tun in VisualBasic. Und hatte grösste Mühe damit - ich war und bin eingefahren auf Pascal. Aber nie würde ich missionieren. Jeder nach seinem Gusto - das Ergebnis zählt. Gruss in die Runde von einem "alten Klaus" Erich
Erich R. schrieb: > Jeder nach seinem Gusto - das Ergebnis zählt. Da stimme ich auch zu. Ich bin nur 10 Jahre jünger und hatte damals Ender 90er auch MS-DOS, dBaseIII und Clipper gelernt. Hobbymäßig hatte ich dann mit Turbo Pascal 3.0 und später den ersten Delphi - Versionen weiter gemacht. Bis dann Borland an Embaraco verkauft wurde und Delphi unglaublich teuer wurde. Dann ist mir dann Profan (heute XProfan), das auch mit Delphi entwickelt wurde, über den Weg gelaufen. Mit dem arbeite ich heute noch sehr gerne. Natürlich mit den aktuellen Versionen. In dem Sinne wäre ich heute dann auch etwas rückständig. Aber wie gesagt, das Ergebnis zählt.
Peter K. schrieb: > Das scheint sich momentan etwas zu ändern:-) > https://www.tiobe.com/tiobe-index/ Einmal hätte gereicht: Beitrag "Re: Warum Pascal/Delphi/Lazarus oft unbeliebt?"
In his interview with Lex Fridman: "... the world might have been better if it had gone Pascal's route..." https://www.youtube.com/watch?v=I845O57ZSy4&t=5791s
Double Commander für Linux und Windows, beide in Free Pascal (steht dort, wenn man F1 drückt) geschrieben, wie sehr viele weitere Linux Programme
Gegeg J. schrieb: > "Object Pascal ist eine auf der Programmiersprachen Pascal von Niklaus > Wirth aufbauende Programmiersprache, deren Funktionsumfang mit C++ > vergleichbar ist. Als großer Vorteil gegenüber anderen Sprachen gilt > gemeinhin die bessere Lesbarkeit des Codes. " Wen interessiert denn heutzutage die nackte Sprache? Wir sind nicht mehr in den 80ern. Was heute zählt ist das drumherum. Wenn ich schon die beschissene Doku von Labskaus sehe ist das schon ein nogo. Ein zusammengewürfelter Lib-Haufen, nix standardisiert, alles wirkt irgendwie rangeflickt, damit es xy jetzt auch irgendwie kann, pseudo-pro-Argumente aus dem letzten Jahrtausend, das ist alles eher abstossend, man riecht und sieht den Ranz an jeder Stelle.
Franko S. schrieb: > Wen interessiert denn heutzutage die nackte Sprache? Meinst du, dein Kommentar auf einen fünf(!) Jahre alten Beitrag würde den Schreiber des Beitrags noch interessieren?
Diese Liste wird fortlaufend ergänzt, falls es dir noch nicht aufgefallen ist..nur mal so am Rande Herr Moderator!! Wen die interessiert, spielt überhaupt keine Rolle
Egon D. schrieb: > Der Umgang mit Feldern ist überhaupt ein Schwachpunkt in > Pascal; ich überlege schon länger, wie man das besser > machen könnte :) https://wiki.freepascal.org/Asm Das Beispiel ist aus verständlichen Gründen einfach, aber es geht noch eine Menge mehr bei Assembler. Hängt natürlich auch von der Plattform ab so dass man die Feinheiten bei der Hardware und seiner Programmierung gut kennen sollte. Parallelisierung wäre heutzutage auch noch eine Option.
Max M. schrieb: > Diese Liste wird fortlaufend ergänzt Der Kommentar bezog sich nicht auf dich, aber … > Wen die interessiert, spielt überhaupt keine Rolle … du schreibst etwas, bei dem du gleich davon ausgehst, dass das möglicherweise keinen interessiert?
ah ok. Jepp, mache ich, also auch wenn es nur einen kleinen kreis interessiert. Ob dem so ist, merkt man manchmal erst im Nachhinein. Wenn man immer davon ausgeht, etwas nicht zu tun, weil es aus irgendwie einem Grund nicht sinnvoll ist, sollte man sein generelles Handeln überdenken
Aha. Also einfach mal frei ins Internet kotzen, kost' ja nichts. Sich an Regeln, Umgangsformen oder gesunden Menschenverstand halten ist ja auch komplett überbewertet.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.