mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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. "

: Bearbeitet durch User
Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++.

Autor: Zeno (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: Joggel E. (jetztnicht)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Prima Klima (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Tobi P. (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Irgend W. (Firma: egal) (irgendwer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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ß.

Autor: loeti2 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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"....

Autor: test (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: loeti2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Geradezieher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;>

Autor: Geradezieher (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Bedenkt das!

Warum liest dann hier mit?

Autor: Franko S. (frank_s866)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Nick M. (muellernick)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ramon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich sehe gerade, der Double Commander fuer Linux ist auch in Freepascal 
/ Lazarus Pascal geschrieben

Autor: Mariella M. (mauriella)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
STM32prog ist ebenfalls in PAscal geschrieben und nutzt dTS und RTS etc 
um Boot0 und Reset anzusteuern
Beitrag "STM32Fxxx Bootlader Programmer STM32Prog"

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
>...kompletter Unsinn.

Na klardo! Alles, was dir nicht passen, sind Unsinn.

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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? ...

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TriHexagon (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:
> Aber manche Leute haben halt recht kleine Teller...

...aber schönen Teller, der schönsten Teller der Welt. :-)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Nop (Gast)
Datum:

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

Doch, in Javascript. Nicht relevant? Naja, Du nutzt es jeden Tag, so wie 
jeder andere Internetnutzer.

Autor: TriHexagon (Gast)
Datum:

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

PHP...

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido B. (guido-b)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. :-)

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxe schrieb:
> Also Synaser und LazSerial sind die Standardbibliotheken fuer die
> Serielle

https://sourceforge.net/projects/comport/

Autor: Tany (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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. :-)

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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?

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sepp (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
@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

: Bearbeitet durch User
Autor: Maxe (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hoffe das bleibt sie auch!

Karl K. schrieb:
> Hiere wird jeder Thread über Pascal sofort
> ... gekapert


JEP :-(

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon D. (egon_d)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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")

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Carl D. (jcw2)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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."

Autor: Jens Jensen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> "kacke" und "scheiße"
ist Hardware, hat hier nichts zu suchen!

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :)

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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..

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tina P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Egon D. (egon_d)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido B. schrieb:
> Beispielprojekt angucken, das geht am schnellsten. ;-)

Wenn man für diesen speziellen Anwendungsfall (eigenes USB-Gerät an 
libusb) eins findet.

Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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++.

Autor: Tany (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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".

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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:
#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;
}

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?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Egon D. (egon_d)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vincent H. (vinci)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Zeno (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
W.S. schrieb:

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

In der Tat.
Aber das ist ja angeblich "nicht der Anspruch" von
Pascal.

Naja.

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Karl K. (karl2go)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.
Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:

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

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

Jörg W. schrieb:

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

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

: Bearbeitet durch Moderator
Autor: Nop (Gast)
Datum:

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

Sagst Du.

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

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

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

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

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

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:

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

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

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

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

Autor: Karl K. (karl2go)
Datum:

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

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

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

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

Autor: Maxe (Gast)
Datum:

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

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

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

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

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

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

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

Autor: Karl K. (karl2go)
Datum:

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

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

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

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

Autor: Zeno (Gast)
Datum:

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

Hallo Jörg,

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

Autor: mh (Gast)
Datum:

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

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

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

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

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

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

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

Autor: Gegeg J. (cdfgdfgdfhsdklklk)
Datum:

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

: Bearbeitet durch User
Autor: Andreas W. (crazywolff)
Datum:

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


Hi,

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

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

CU, Crazy

Autor: Zeno (Gast)
Datum:

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

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

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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