Lazarus vs. Delphi
Christof Kluß
was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung
relativ gut mit Delphi kompatibel [2-5]. Benutzt Lazarus eventuell schon
jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt?
Oder anders gefragt, wo seht ihr die Nachteile von Lazarus gegenï¿œber
Delphi?
Gruￜ,
Christof
_______
[1] http://www.lazarus.freepascal.org/
[2] http://wiki.lazarus.freepascal.org/Lazarus_For_Delphi_Users
[3] http://wiki.lazarus.freepascal.org/Code_Conversion_Guide
[4] http://wiki.lazarus.freepascal.org/Lazarus_Components
[5] http://wiki.lazarus.freepascal.org/Delphi_unit_status_list
Frank Esselbach
muss, nervig. Wer das will und kann, programiert bestimmt nicht in
Pascal.
Ich fand die Info interessannt und habe nach der Mac OSX-Version gesucht
und - wie gesagt - nur Bruchst�cke gefunden. Nette Idee, aber m.E. (!)
an der Clientel vorbei ...
Frank
Michael Fuchs
> Ich finde IDEs, die man sich selber aus dutzenden Libs zusammenzimmern
> muss, nervig. Wer das will und kann, programiert bestimmt nicht in
> Pascal.
Dunkel bleibt deiner Rede Sinn. Was muss man sich f�r Lazarus
zusammenzimmern?
mfg
Micha
Michael Fuchs
> Hallo,
>
> was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung
> relativ gut mit Delphi kompatibel [2-5]. Benutzt Lazarus eventuell schon
> jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt?
Umgestellt nix, aber viele Projekte damit schon neu gestartet. Wobei ein
Teil davon auch keine grafischen Programme waren und ich Lazarus einfach
als bequemes Frontend zu Freepascal genutzt habe.
> Oder anders gefragt, wo seht ihr die Nachteile von Lazarus gegenï¿œber
> Delphi?
Ein paar Komponenten weniger (wobei das massiv abnimmt, seitdem viele
Komponentenentwickler auch auf FPC-Kompatibilitï¿œt achte). Ansonsten:
ausprobieren. Hab schon eine ganze Weile nicht mehr mit Delphi
gearbeitet, weil ich Wert auf Portabilitï¿œt lege.
Und da ist Lazarus ideal. Einmal Formular designed und Quellcode
geschrieben und dann ganz schnell unter Linux und Win kompiliert.
mfg
Micha
Norbert Stellberg
> ausprobieren. Hab schon eine ganze Weile nicht mehr mit Delphi gearbeitet,
> weil ich Wert auf Portabilitï¿œt lege.
> Und da ist Lazarus ideal. Einmal Formular designed und Quellcode
> geschrieben und dann ganz schnell unter Linux und Win kompiliert.
gibt es dafï¿œr ein deutschsprachiges Forum?
Mit freundlichen Grￜￜen
Norbert
Björn Schreiber
> gibt es dafï¿œr ein deutschsprachiges Forum?
Grￜￜe,
Bjï¿œrn
--
Bjï¿œrn Schreiber, DRIGUS GmbH
new...@drigus.de
Bei Email NOSPAM in den Betreff aufnehmen.
Put NOSPAM in subject to reach me by email.
Michael Fuchs
> Hallo,
>
>> ausprobieren. Hab schon eine ganze Weile nicht mehr mit Delphi
>> gearbeitet, weil ich Wert auf Portabilitï¿œt lege.
>> Und da ist Lazarus ideal. Einmal Formular designed und Quellcode
>> geschrieben und dann ganz schnell unter Linux und Win kompiliert.
>
> gibt es dafï¿œr ein deutschsprachiges Forum?
Aber sicher:
http://www.lazarusforum.de/
Ansonsten sind Fragen zu FreePascal auch in de.comp.lang.pascal richtig.
mfg
Micha
Hans-Peter Diettrich
> was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung
> relativ gut mit Delphi kompatibel [2-5]. Benutzt Lazarus eventuell schon
> jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt?
> Oder anders gefragt, wo seht ihr die Nachteile von Lazarus gegenï¿œber
> Delphi?
Ich habe lange Zeit ï¿œber das Delphi Drag&Dock geflucht, und es fï¿œr
Lazarus etwas verbessert. Mehr ging leider nicht, aus
Kompatibilitï¿œtsgrï¿œnden. Siehe examples\dockmanager\.
DoDi
Michael Justin
> was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung
> relativ gut mit Delphi kompatibel [2-5]. Benutzt Lazarus eventuell schon
> jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt?
Meine Delphi-Komponenten und Libraries (Habari JMS Clients, ScroogeXHTML
RTF Konverter) waren mit sehr wenig Anpassungen sowohl unter Delphi (6
bis 2010) alsauch Free Pascal / Lazarus einsetzbar, die Kompatibilität
mit Delphi ist sehr hoch und es gibt einige gute Open Source Libraries
die beide Welten unterstützen - mein Eindruck war bisher also sehr positiv.
Cheers,
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphi™ and for the Java™ platform
http://www.mikejustin.com - http://www.betabeans.de
Ole Jansen
> was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung
> relativ gut mit Delphi kompatibel [2-5].
Kann ich bestï¿œtigen. So gefï¿œhlte 95% von meinem Code kann ich 1:1
ï¿œbernehmen.
> Benutzt Lazarus eventuell schon
> jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt?
Ja, wo ein Port nach Linux gewï¿œnscht war, da ich kein Kylix besitze.
So kann ich theoretisch mit der selben Codebasis beide Seiten pflegen.
Praktisch ist da aber die "Distro-Hell" auf der Linux Seite...
Kniffelige Hardware-Sachen waren noch nicht dabei, das "Schlimmste"
war ein Projekt, bei dem ich FTDI-Chips ï¿œber USB ansprechen muï¿œte.
> Oder anders gefragt, wo seht ihr die Nachteile von Lazarus gegenï¿œber
> Delphi?
Bei den verfï¿œgbaren Komponenten.
Die Entwicklung eigener Komponenten oder der Port von Delphi Packages
ist IMHO sehr kniffelig. Wer das will, kommt nicht drum herum, die
Sourcen zu verstehen und Lazarus selber zu bauen.
O.J.
Jens Lenge
Sprachfeatures von D2009/2010 aus, sprich sowas wie Generics und Unicode?
Weiￜ jemand, ob generell geplant ist, der Delphi-Entwicklung bei sowas
zu folgen?
Michael Fuchs
> Wie sieht es bei Lazarus bzw. FreePascal denn mit den neueren
> Sprachfeatures von D2009/2010 aus, sprich sowas wie Generics und Unicode?
Das gabs dort schon bevor es sowas bei Delphi gab.
> Weiￜ jemand, ob generell geplant ist, der Delphi-Entwicklung bei sowas
> zu folgen?
Da ist das Problem nur, dass es mï¿œglicherweise nicht den
Delphiimplementationen entspricht, einfach weil FPC da vorher da war. Da
ich schon ewig kein Delphi mehr benutzt habe, kann ich leider nicht
sagen wie die Unterschiede aussehen.
mfg
Micha
http://wiki.freepascal.org/LCL_Unicode_Support
http://wiki.freepascal.org/Generics
Heiko Rompel
Christof Kluￜ schrieb:
> was haltet ihr von Lazarus[1]?
Also, ich finde den Umstand das es eine "Portable" Version gibt
(http://portableapps.com/node/18088) sehr interessant.
Leider scheint diese Version sehr langsam zu sein und es scheint in der
IDE auch kein Docking der Fenster zu geben.
Werde es die Tage trotzdem mal testen, ob mein aktuelles Projekt dort
auch lï¿œuft.
MfG
Heiko
Jens Lenge
> Das gabs dort schon bevor es sowas bei Delphi gab.
> http://wiki.freepascal.org/Generics
Interessant. Leider beides ganz anders gelï¿œst als bei Delphi, da gï¿œbe es
beim Code-Anpassen also einiges umzustellen und zu beachten. Schade,
aber wohl der Tatsache geschuldet, dass es bei FreePascal vorher da war.
Zumindest beantwortet das die Frage, ob FreePascal zum Ziel hat, der
Delphi-Entwicklung zu folgen: Hat es nicht. ;)
Jens
Rudy Velthuis
> Jens Lenge schrieb:
> > Wie sieht es bei Lazarus bzw. FreePascal denn mit den neueren
> > Sprachfeatures von D2009/2010 aus, sprich sowas wie Generics und
> > Unicode?
>
> Das gabs dort schon bevor es sowas bei Delphi gab.
Aber ein bisserl anders:
http://www.freepascal.org/docs-html/ref/refse40.html
--
Rudy Velthuis http://rvelthuis.de
"So I rang up a local building firm, I said 'I want a skip outside
my house.' He said 'I'm not stopping you.'" -- Tommy Cooper
Michael Fuchs
Hier wï¿œre natï¿œrlich die beste Lï¿œsung, wenn sich die Hersteller von
Compilern auf einen gemeinsamen Standard fï¿œr ObjectPascal einigen
kï¿œnnten. Da Borland (oder wie auch immer) aber wenig Interesse an einer
vernï¿œnftigen Strategie zum Thema Delphi zeigt, wird das wohl nix.
Nun was solls, ich werde sowieso weiter bei Lazarus bleiben, schon aus
Linux-Grï¿œnden.
mfg
Micha
--
Meine Wanderungen durch Realitï¿œt und Cyberspace
auf --> http://www.michael-fuchs.net <--
Hans-Peter Diettrich
> Also, ich finde den Umstand das es eine "Portable" Version gibt
> (http://portableapps.com/node/18088) sehr interessant.
Aktuell ist inzwischen die Version 0.9.28 :-)
> Leider scheint diese Version sehr langsam zu sein und es scheint in der
> IDE auch kein Docking der Fenster zu geben.
Seltsam, Klagen ï¿œber die Geschwindigkeit der IDE lese ich auch bei RAD
Studio ;-)
Das Docking wird noch einige Zeit dauern, da die Delphi IDE mit einem
anderem Verfahren arbeitet als in der VCL implementiert. Die
Lazarus-Entwickler weigern sich standhaft, so ein VCL-inkompatibles
Docking zuzulassen :-(
Was mir am meisten fehlt sind mehrere Edit-Fenster. Zwar konnte ich via
Docking inzwischen mehrere solche Fenster implementieren, und viel
schￜner als in Delphi, aber diese Implementierung muￜ noch in die IDE
integriert werden.
Insgesamt denke ich seit lï¿œngerer Zeit daran, eine eigene Variante der
LCL und IDE zu entwickeln, die meinen Vorstellungen nï¿œher kommt. Dabei
dï¿œrften aber diverse Features wegfallen, die ich als problematisch empfinde.
DoDi
Rudy Velthuis
> Hier wï¿œre natï¿œrlich die beste Lï¿œsung, wenn sich die Hersteller von
> Compilern auf einen gemeinsamen Standard fï¿œr ObjectPascal einigen
> kï¿œnnten.
Wie das denn? Die beiden stammen von ObjectPascal ab, aber beide sind
NICHT ObjectPascal. Object Pascal war eine Sprache von Apple fï¿œr den
Mac und den Mac ToolBox.
Und warum sollte sich Delphi von irgendwelchen Standards einengen
lassen? Wenn Lazarus ein Delphi-Klon bleiben will, sollten sie keine
Alleingï¿œnge machen. Wenn sie unabhï¿œngig sein wollen, verlieren sie
vielleicht die Kompatibilitï¿œt. Deren Entscheidung.
--
Rudy Velthuis http://rvelthuis.de
"Missionaries are perfect nuisances and leave every place worse
than they found it."
-- Charles Dickens
Michael Fuchs
>> Hier wï¿œre natï¿œrlich die beste Lï¿œsung, wenn sich die Hersteller von
>> Compilern auf einen gemeinsamen Standard fï¿œr ObjectPascal einigen
>> kï¿œnnten.
>
> Wie das denn? Die beiden stammen von ObjectPascal ab, aber beide sind
> NICHT ObjectPascal. Object Pascal war eine Sprache von Apple fï¿œr den
> Mac und den Mac ToolBox.
> Und warum sollte sich Delphi von irgendwelchen Standards einengen
> lassen?
Weil Standards hilfreich sein kï¿œnnen um ein Sprache und damit die
zugehï¿œrigen Produkte zu promoten. Aber wie schon geschrieben, so richtig
nachdenken tut beim Delphihersteller anscheinend keiner.
> Wenn Lazarus ein Delphi-Klon bleiben will, sollten sie keine
> Alleingï¿œnge machen.
Lazarus ist kein Delphi-Klon, war auch nie als einer geplant.
mfg
Micha
Matthias Eissing
>> Und warum sollte sich Delphi von irgendwelchen Standards einengen
>> lassen?
> Weil Standards hilfreich sein kï¿œnnen um ein Sprache und damit die
> zugehï¿œrigen Produkte zu promoten.
ACK. Fï¿œr sich alleine genommen hat das durchaus seine Berechtigung.
Im Falle von Pascal fï¿œr den PC sehe ich die Notwendigkeit nicht. Die einzige
Firma, die Pascal in den letzten anderthalb Dekaden weiterentwickelt hat und
einen messbaren Marktanteil hat, ist Embarcadero.
> Aber wie schon geschrieben, so richtig nachdenken tut beim
> Delphihersteller anscheinend keiner.
Stimmt. Die sitzen nur rum und drehen Dï¿œumchen.
Wï¿œre ein Projekt FPC oder Lazarus ï¿œberhaupt entstanden, wenn es Delphi nicht
gegeben hï¿œtte? IMHO: Nein.
>> Wenn Lazarus ein Delphi-Klon bleiben will, sollten sie keine
>> Alleingï¿œnge machen.
> Lazarus ist kein Delphi-Klon, war auch nie als einer geplant.
Gut. Es war also nie als ein solcher geplant. Nur die Realitï¿œt sieht anders
aus. O.K.: Auf dem Stand von Delphi 7.
--
cu://Matthias.Eissing.de
Matthias Eissing
> Seltsam, Klagen ï¿œber die Geschwindigkeit der IDE lese ich auch bei RAD
> Studio ;-)
Schon mal Lazarus unter Linux gestartet und die Zeit genommen?
Schon mal Delphi 2010 gestartet und die Zeit genommen?
Delphi 2005/BDS 2006 war in der Tat gut fï¿œr die Entschleunigung geeignet :)
--
cu://Matthias.Eissing.de
Michael Fuchs
> ACK. Fï¿œr sich alleine genommen hat das durchaus seine Berechtigung.
> Im Falle von Pascal fï¿œr den PC sehe ich die Notwendigkeit nicht. Die
> einzige Firma, die Pascal in den letzten anderthalb Dekaden
> weiterentwickelt hat und einen messbaren Marktanteil hat, ist Embarcadero.
Firma: ja. Muss man deswegen die Community ignorieren? Und da gibt es
gerade um FreePascal herum eine durchaus starke.
>> Aber wie schon geschrieben, so richtig nachdenken tut beim
>> Delphihersteller anscheinend keiner.
>
> Stimmt. Die sitzen nur rum und drehen Dï¿œumchen.
> Wï¿œre ein Projekt FPC oder Lazarus ï¿œberhaupt entstanden, wenn es Delphi
> nicht gegeben hï¿œtte? IMHO: Nein.
Es ist wohl entstanden, weil irgendjemanden etwas bei Delphi fehlte. Zum
Beispiel Linuxunterstï¿œtzung, die ja von Borland nur halbherzig und dann
gar nicht mehr gegeben war.
Das meine ich mit nicht nachdenken. Ich fï¿œhle mich von Delphi nur
enttï¿œuscht. Deswegen nutze ich auch Lazarus.
>> Lazarus ist kein Delphi-Klon, war auch nie als einer geplant.
> Gut. Es war also nie als ein solcher geplant. Nur die Realitï¿œt sieht
> anders aus. O.K.: Auf dem Stand von Delphi 7.
Kann man wirklich nicht so sagen. Bestimmte Dinge kann es nicht, viele
andere Dinge kann Delphi nicht. Man kann Anwendungen *portieren* aber
nicht ein Projekt mit beiden Systemen bearbeiten.
Klon wï¿œre so etwas wie SharpDevelop im Vergleich zu VisualStudio wo
tatsï¿œchlich Kompatibilitï¿œt gegeben ist.
mfg
Micha
Heiko Rompel
Matthias Eissing schrieb:
> Schon mal Lazarus unter Linux gestartet und die Zeit genommen?
Nein.
> Schon mal Delphi 2010 gestartet und die Zeit genommen?
Aber ich habe doch garkein Delphi 2010 :-)
> Delphi 2005/BDS 2006 war in der Tat gut fï¿œr die Entschleunigung geeignet :)
Die 2006 habe ich hier und da gegen ist Lazarus portable echt langsam.
MfG
Heiko
Matthias Eissing
"Michael Fuchs" <mik...@gmx.de> schrieb
[Standardisierung von Pascal]
> Firma: ja. Muss man deswegen die Community ignorieren? Und da gibt es
> gerade um FreePascal herum eine durchaus starke.
Weder mï¿œchte ich die Lazarus Community gering schï¿œtzen, noch mï¿œchte ich eine
Zusammenarbeit/Standardisierung von vornherein kleinreden.
Wie groￜ schￜtzt Du die FPC/Lazarus-Community im Verhￜltnis zur Delphi
Community? Letzte sind gut 3 Millionen weltweit.
Welche Wege wurden von der FPC/Lazarus-Community beschritten um diesen
Wunsch auch umzusetzen?
> Es ist wohl entstanden, weil irgendjemanden etwas bei Delphi fehlte. Zum
> Beispiel Linuxunterstï¿œtzung, die ja von Borland nur halbherzig und dann
> gar nicht mehr gegeben war.
Damals hat Borland keinen Hehl darum gemacht ein kommerzielles Unternehmen
zu sein. Der Erfolg (und das wird in den Unternehmen am Umsatz bemessen)
blieb trotz dreier Releases von Kylix aus.
Embarcadero macht ï¿œbrigens auch keinen Hehl darum, dass sie Geld verdienen
wollen.
Drï¿œcken wir es so aus: Der Markt (auch bzw insbesondere der kommerzielle)
fï¿œr Kylix war zum damaligen Zeitpunkt in der Form nicht da. Das mag am
Produkt selbst gelegen haben (verkorkste IDE? Abhï¿œngigkeit zu den
Libraries?) Vielleicht wird er das in ein paar Monaten mit DelphiX
(X-Compiler fï¿œr Linux) ja sein.
> Das meine ich mit nicht nachdenken. Ich fï¿œhle mich von Delphi nur
> enttï¿œuscht. Deswegen nutze ich auch Lazarus.
Steht dir ja frei. Jeder kann seine Zeit so einteilen, wie er will.
[Lazarus ein Delphi Klon?]
> Klon wï¿œre so etwas wie SharpDevelop im Vergleich zu VisualStudio wo
> tatsï¿œchlich Kompatibilitï¿œt gegeben ist.
...fï¿œr passende Definition von Klon mag das stimmen.
--
cu://Matthias.Eissing.de
Arno Garrels
>> RAD Studio ;-)
>
> Schon mal Lazarus unter Linux gestartet und die Zeit genommen?
> Schon mal Delphi 2010 gestartet und die Zeit genommen?
Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit genommen?
Das dauert eine Ewigkeit! Und die EXE-Größe mal betrachtet?
Ich habe Lazarus öfter mal installiert und nach kurzer Spielerei
wieder von der Platte geputzt. Das Lazarus auf dem Stand von D7 sein
soll, bezüglich Stabilität und Benutzerfreundlichkeit, halte ich für
ein Gerücht.
--
Arno Garrels
Hubert Seidel
"Michael Fuchs" <mik...@gmx.de> schrieb im
Newsbeitrag news:7jl939F...@mid.individual.net...
> Rudy Velthuis schrieb:
...
> > Und warum sollte sich Delphi von irgendwelchen Standards einengen
> > lassen?
>
> Weil Standards hilfreich sein k�nnen um ein Sprache und damit die
> zugeh�rigen Produkte zu promoten. Aber wie schon geschrieben, so
richtig
> nachdenken tut beim Delphihersteller anscheinend keiner.
Und weil gro�e Firmen keine Sprachen einsetzen welche nicht
standardisiert sind...
mfg.
Herby
--
http://www.hubert-seidel.eu
Markus Gronotte
"Christof Kluￜ"
> was haltet ihr von Lazarus[1]? Das Projekt ist laut der Beschreibung relativ gut mit Delphi kompatibel [2-5]. Benutzt Lazarus
> eventuell schon jemand von euch, bzw. hat bestehende Delphi-Projekte darauf umgestellt? Oder anders gefragt, wo seht ihr die
> Nachteile von Lazarus gegenï¿œber Delphi?
Was ich an Lazarus nicht unbedingt notwendig oder nï¿œtzlich,
aber dafï¿œr lustig finde, ist die Tatsache, dass man fï¿œr logische
Ausdrï¿œcke C-Syntax verwenden kann z.B. != && ||
Aber das kommt vermutlich aus Freepascal und nicht von Lazarus selbst.
Gruￜ,
Markus
Markus Gronotte
"Michael Justin"
> und es gibt einige gute Open Source Libraries die beide Welten unterstützen
kannst du Beispiele nennen?
Wäre an allen nützlichen Freewarekomponenten
für Lazarus interessiert.
Gruß,
Markus
Markus Gronotte
"Arno Garrels"
>Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit genommen?
Das liegt daran, dass dort Debuginformationen mit
einkompiliert werden. es gibt irgendwo ein Tool,
mit denen man diesen "Schrott" entfernen kann.
Danach sind die EXEs meist etwas kleiner, als
unter Delphi.
Gruￜ,
Markus
Markus Gronotte
"Arno Garrels"
>Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit genommen?
>Das dauert eine Ewigkeit! Und die EXE-Grￜￜe mal betrachtet?
Felix Alter
Markus Gronotte schrieb am 14.10.2009 21:07:
> Das liegt daran, dass dort Debuginformationen mit
> einkompiliert werden. es gibt irgendwo ein Tool,
> mit denen man diesen "Schrott" entfernen kann.
Oder direkt in den Compilereinstellungen verhindern dass der Schrott
reinkommt (Stichworte: Smart linkbar und Smart linken an, Debuginfos
entfernen auch an, Zeilennummern zeigen aus). Das Tool "strip" war nur
eine Notlï¿œsung fï¿œr als das noch nicht so zu entfernen ging.
Genaueres in der FAQ im Lazarus-Wiki nachzulesen.
> Danach sind die EXEs meist etwas kleiner, als
> unter Delphi.
Bei groï¿œen Projekten schon, kleine LCL-Programme sind meist trotzdem
etwas grￜￜer als vergleichbare VCL-Programme.
Gruￜ
FAlter
--
Felix Alter Die folgenden Zeilen sind ein Smiley fï¿œr n3rd5:
001FF800 01F00F80 070000E0 1C181838 3118181C 60181806 60181806
670000E6 61FFFF16 7061160E 3833CC1C 1C1E7831 070000E0 01F00F80
001FF800 =B FAlter Kontakt: http://faltersoft.de/contact.php
Hans-Peter Diettrich
>>> Und warum sollte sich Delphi von irgendwelchen Standards einengen
>>> lassen?
>
>> Weil Standards hilfreich sein kï¿œnnen um ein Sprache und damit die
>> zugehï¿œrigen Produkte zu promoten.
>
> ACK. Fï¿œr sich alleine genommen hat das durchaus seine Berechtigung.
> Im Falle von Pascal fï¿œr den PC sehe ich die Notwendigkeit nicht. Die
> einzige Firma, die Pascal in den letzten anderthalb Dekaden
> weiterentwickelt hat und einen messbaren Marktanteil hat, ist Embarcadero.
Der Vergleich hinkt, da zu Free Pascal und Lazarus keine Firmen gehï¿œren.
>> Aber wie schon geschrieben, so richtig nachdenken tut beim
>> Delphihersteller anscheinend keiner.
>
> Stimmt. Die sitzen nur rum und drehen Dï¿œumchen.
Das nicht gerade (fehlt wohl ein Smily?), aber die Entscheidungen sind
nicht immer wohldurchdacht. Das hat angefangen mit der Erfindung einer
eigenen unsystematischen Syntax, statt einer Anlehnung an Modula oder
(spï¿œter) Oberon, und endete letzthin in der radikalen Einfï¿œhrung von
Unicode und dem neuen RTTI, beides ohne Mï¿œglichkeit zur Beibehaltung des
frï¿œheren Handlings.
Wenn ich alle Delphi-Pleiten der letzten Jahre aufzï¿œhle:
- Kylix, CLX
- Inprise
- VS Konkurrenz
- Delphi.NET, VCL.NET
- Online Hilfe
- Preisgestaltung
dann kommen mir heftige Bedenken an der ï¿œberlebensfï¿œhigkeit von Delphi,
auch unter der Fuchtel von Embarcadero :-(
> Wï¿œre ein Projekt FPC oder Lazarus ï¿œberhaupt entstanden, wenn es Delphi
> nicht gegeben hï¿œtte? IMHO: Nein.
Mï¿œglicherweise nicht, aber die Zielrichtung (Multi-Plattform) war ja
etwas, das nach dem miï¿œglï¿œckten Kylix Experiment von Borland nicht
weiter verfolgt wurde. Nun kaut CodeGear/Embarcadero an einem 64 Bit
Compiler und einer Multi-Plattform VCL, und schiebt den Termin dafï¿œr
seit Jahren vor sich her.
>>> Wenn Lazarus ein Delphi-Klon bleiben will, sollten sie keine
>>> Alleingï¿œnge machen.
>
>> Lazarus ist kein Delphi-Klon, war auch nie als einer geplant.
>
> Gut. Es war also nie als ein solcher geplant. Nur die Realitï¿œt sieht
> anders aus. O.K.: Auf dem Stand von Delphi 7.
Ohne die Mï¿œglichkeit, bestehenden Delphi-Code zu importieren, wï¿œre FPC
wie Lazarus in einer neuen Nische steckengeblieben, und kein Schwein
hï¿œtte sich dafï¿œr interessiert. Seitdem haben sich Delphi und FPC/Lazarus
fortwï¿œhrend auseinanderentwickelt, aufgrund der unterschiedlichen
Zielrichtungen. Delphi soll mit .NET Features aufpoliert werden, um die
Benutzer vom Abwandern zu VS abzuhalten, und Lazarus kï¿œmpft mit stï¿œndig
neu hinzukommenden Plattformen (Max OS X, Handhelds...), dazu noch mit
von Delphi ï¿œbernommenen Altlasten.
DoDi
Hans-Peter Diettrich
>> Seltsam, Klagen ï¿œber die Geschwindigkeit der IDE lese ich auch bei RAD
>> Studio ;-)
>
> Schon mal Lazarus unter Linux gestartet und die Zeit genommen?
4 Sekunden (SuSE 10.3 64 bit)
> Schon mal Delphi 2010 gestartet und die Zeit genommen?
Habe ich nicht
> Delphi 2005/BDS 2006 war in der Tat gut fï¿œr die Entschleunigung geeignet :)
Wenn man Delphi in eine virtuelle Maschine packt - die startet recht
flott ;-)
IMO hï¿œngt die Startzeit von den optionalen Features ab, die man sich
nicht unbedingt antun muￜ. Beim Compilieren ist Lazarus aufgrund der
Trennung von IDE und Compiler im Nachteil. Bei der Installation von
Updates dï¿œrfte Lazarus wieder die Nase vorn haben - sofern man fï¿œr
Delphi ï¿œberhaupt noch Updates bekommt.
DoDi
Michael Fuchs
>> Danach sind die EXEs meist etwas kleiner, als unter Delphi.
>
> Bei groï¿œen Projekten schon, kleine LCL-Programme sind meist trotzdem
> etwas grￜￜer als vergleichbare VCL-Programme.
Laut den Realeasenotes zur gerade erschienenen Version, hat sich das
wohl auch ein bisschen verbessert:
"Refactoring of LCL-Interface interface interoperability => size of
empty form application was reduced by 17-18% (qt, win32)and 15-16% for
Gtk applications."
Michael Fuchs
>> und es gibt einige gute Open Source Libraries die beide Welten
>> unterstützen
> kannst du Beispiele nennen?
Indy, tiOPF, synapse, JEDI code library (noch nicht vollständig glaube
ich), ...
> Wäre an allen nützlichen Freewarekomponenten
> für Lazarus interessiert.
Schon mal dort umgesehen:
http://wiki.lazarus.freepascal.org/Components_and_Code_examples
Micha
--
Meine Wanderungen durch Realität und Cyberspace
Michael Fuchs
> Wie groￜ schￜtzt Du die FPC/Lazarus-Community im Verhￜltnis zur Delphi
> Community? Letzte sind gut 3 Millionen weltweit.
Uh, da mï¿œchte ich keinerlei Schï¿œtzungen abgeben. Und sicherlich wird es
auch ï¿œberschneidungen mit der Delphi Community geben.
> Welche Wege wurden von der FPC/Lazarus-Community beschritten um diesen
> Wunsch auch umzusetzen?
Keine Ahnung. Vermutlich gar keine. Hab ja auch nicht gesagt, dass es
die Macher von FPC/Lazarus die besseren Diplomaten sind. Allerdings
haben sie natï¿œrlich auch ein bisschen weniger Ressourcen als
Borland/wasweiï¿œich.
>> Zum Beispiel Linuxunterstï¿œtzung, die ja von Borland nur halbherzig und
>> dann gar nicht mehr gegeben war.
> Damals hat Borland keinen Hehl darum gemacht ein kommerzielles
> Unternehmen zu sein. Der Erfolg (und das wird in den Unternehmen am
> Umsatz bemessen) blieb trotz dreier Releases von Kylix aus.
Lag vermutlich zum Groï¿œteil an den von dir auch weite runten
beschriebenen Grï¿œnden.
> Embarcadero macht ï¿œbrigens auch keinen Hehl darum, dass sie Geld
> verdienen wollen.
Dagegen spricht doch auch nix. Sie verhalten sich dabei bloss etwas
seltsam. Zum Beispiel auch indem sie den Einstieg zu ihren Produkten
nicht gerade erleichtern. Die kostenlose Turbo-Version gibt es ja auch
nicht mehr. Was passiert? Jeder Dï¿œdel der mit Programmieren anfï¿œngt
rennt zum VisualStudioExpress.
> Drï¿œcken wir es so aus: Der Markt (auch bzw insbesondere der
> kommerzielle) fï¿œr Kylix war zum damaligen Zeitpunkt in der Form nicht
> da. Das mag am Produkt selbst gelegen haben (verkorkste IDE?
> Abhï¿œngigkeit zu den Libraries?) Vielleicht wird er das in ein paar
> Monaten mit DelphiX (X-Compiler fï¿œr Linux) ja sein.
Sowas kommt? Na da bin ich mal gespannt.
Rudolf Ziegaus
Das halte ich f�r eine Fehleinsch�tzung, dann h�tte nie jemand in einer
gro�en Firma was mit VB programmieren d�rfen. Weiterhin gibt es ja auch
unterschiedliche Dialekte von vielen "standardsierten" Sprachen an (z. B.
SQL, C, C++)... dann h�tte zumindest kein Entwickler in einer gro�en Firma
die Erweiterungen nutzen d�rfen.
Rudi
Rudolf Ziegaus
> Das nicht gerade (fehlt wohl ein Smily?), aber die Entscheidungen sind
> nicht immer wohldurchdacht. Das hat angefangen mit der Erfindung einer
> eigenen unsystematischen Syntax, statt einer Anlehnung an Modula oder
> (sp�ter) Oberon, und endete letzthin in der radikalen Einf�hrung von
> Unicode und dem neuen RTTI, beides ohne M�glichkeit zur Beibehaltung des
> fr�heren Handlings.
>
> Wenn ich alle Delphi-Pleiten der letzten Jahre aufz�hle:
> - Kylix, CLX
> - Inprise
> - VS Konkurrenz
> - Delphi.NET, VCL.NET
> - Online Hilfe
> - Preisgestaltung
> dann kommen mir heftige Bedenken an der �berlebensf�higkeit von Delphi,
> auch unter der Fuchtel von Embarcadero :-(
>
>
> DoDi
Es ist nat�rlich auch nicht ganz einfach f�r die Hersteller von
Entwicklungsumgebungen - die wollen damit Geld verdienen und nat�rlich
m�glichst wenig investieren.
Ich kann mich noch an die Zeiten von OS/2 erinnern - alle wollten einen
Turbo-Pascal-Compiler f�r OS/2, leider gab's nie einen - aus der heutigen
Perspektive kann man sagen, dass das auch richtig war, OS/2 gibt's auch
schon lange nicht mehr. Der C++-Compiler f�r OS/2 war auch kein gro�er
Erfolg, wahrscheinlich kam er schon zu sp�t.
.NET sollte nach Meinung von MS ein gro�er Erfolg werden, sie haben sogar
Anders von Borland abgeworben. Wo steht .NET heute? Ich w�rde mal sagen,
dass es sich noch nicht auf breiter Front durchgesetzt hat.
Das mit der Preisgestaltung ist wirklich sehr schade. Fr�her war Borland
mal die Firma, die Microsoft vom Thron gesto�en hat, mit ihren schlechten
IDEs f�r viel Geld. Heute sind die IDEs von Borland mindestens genauso
teuer, wenn nicht sogar teurer... habe die aktuellen Preise nicht im Kopf.
Rudi
Rudy Velthuis
> Rudy Velthuis schrieb:
> > > Hier wï¿œre natï¿œrlich die beste Lï¿œsung, wenn sich die Hersteller von
> > > Compilern auf einen gemeinsamen Standard fï¿œr ObjectPascal einigen
> > > kï¿œnnten.
> >
> > Wie das denn? Die beiden stammen von ObjectPascal ab, aber beide
> > sind NICHT ObjectPascal. Object Pascal war eine Sprache von Apple
> > fï¿œr den Mac und den Mac ToolBox.
> Zumindest als ich zu Delphi stieￜ, hieￜ die Sprache dort so.
Sie wurde irrtï¿œmlicherwiese (auch von Borland) so genannt.
>
> > Und warum sollte sich Delphi von irgendwelchen Standards einengen
> > lassen?
>
> Weil Standards hilfreich sein kï¿œnnen um ein Sprache und damit die
> zugehï¿œrigen Produkte zu promoten.
Sie kï¿œnnen auch sehr effektiv Innovationen verhindern oder wenigstens
sehr stark verzï¿œgern. Warum sollte Embarcadero sich das antun, ohne
irgendeinen ersichtlichen Vorteil? Nee danke.
--
Rudy Velthuis http://rvelthuis.de
"The spirit of resistance to government is so valuable on
certain occasions that I wish it to be always kept alive."
-- Thomas Jefferson
Rudy Velthuis
> Die
> einzige Firma, die Pascal in den letzten anderthalb Dekaden
> weiterentwickelt hat und einen messbaren Marktanteil hat, ist
> Embarcadero.
Naja, hauptsï¿œchlich Borland. Embarcadero erst seit geringer Zeit. <g>
--
Rudy Velthuis http://rvelthuis.de
"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
-- Edsger Dijkstra
Rudy Velthuis
> Matthias Eissing schrieb:
>
> > ACK. Fï¿œr sich alleine genommen hat das durchaus seine Berechtigung.
> > Im Falle von Pascal fï¿œr den PC sehe ich die Notwendigkeit nicht.
> > Die einzige Firma, die Pascal in den letzten anderthalb Dekaden
> > weiterentwickelt hat und einen messbaren Marktanteil hat, ist
> > Embarcadero.
>
> Firma: ja. Muss man deswegen die Community ignorieren?
Welchen Vortail hat Embarcadero davon, sich einengen zu lassen? Der
vielleicht irgendwann zu erwartende Nutzen (Sprache promoten) wiegt IMO
nicht auf gegen die sehr klaren Kosten (keine Freiheit mehr).
--
Rudy Velthuis http://rvelthuis.de
"It is far easier to make war than peace." -- Georges Clemenceau
Rudy Velthuis
> Seltsam, Klagen ï¿œber die Geschwindigkeit der IDE lese ich auch bei
> RAD Studio ;-)
ï¿œber RAD Studio 2010? Ich bis jetzt noch nicht einmal, und ich lese
sehr viel darï¿œber. Im Gegenteil, 2010 ist extrem spritzig.
--
Rudy Velthuis http://rvelthuis.de
"All warfare is based on deception."
-- Sun tzu
Rudy Velthuis
> > Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit
> > genommen? Das dauert eine Ewigkeit! Und die EXE-Grￜￜe mal
> > betrachtet?
>
> Das liegt daran, dass dort Debuginformationen mit
> einkompiliert werden.
Das tut Delphi auch, normalerweise.
--
Rudy Velthuis http://rvelthuis.de
"I don't know anything about music. In my line you don't have
to." -- Elvis Presley (1935-1977)
Matthias Eissing
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb
>>> Aber wie schon geschrieben, so richtig nachdenken tut beim
>>> Delphihersteller anscheinend keiner.
>> Stimmt. Die sitzen nur rum und drehen Dï¿œumchen.
> Das nicht gerade (fehlt wohl ein Smily?)
Ich kann es mir erlauben den Smiley an dieser Stelle auszulassen.
--
cu://Matthias.Eissing.de
Hubert Seidel
"Rudolf Ziegaus" <Rudolf....@gmx.de> schrieb im
Newsbeitrag news:j8yn6pcq3e9m$.zowgl81qvh5.dlg@40tude.net...
> On Wed, 14 Oct 2009 19:17:56 +0200, Hubert Seidel wrote:
...
> > Und weil gro�e Firmen keine Sprachen einsetzen welche nicht
> > standardisiert sind...
> Das halte ich f�r eine Fehleinsch�tzung, dann h�tte nie jemand in
einer
Meine Formulierung war wohl nicht pr�zise genug.
Und weil gro�e Firmen keine Sprachen mehr einsetzen wollen
welche nicht standardisiert sind...
> gro�en Firma was mit VB programmieren d�rfen. Weiterhin gibt es ja
auch
> unterschiedliche Dialekte von vielen "standardsierten" Sprachen an (z.
B.
> SQL, C, C++)... dann h�tte zumindest kein Entwickler in einer gro�en
Firma
> die Erweiterungen nutzen d�rfen.
Das wird aus verschiedenen Gr�nden doch nur _geduldet_.
Und nat�rlich gibt es immer Ausnahmen.
Matthias Eissing
"Michael Fuchs" <mik...@gmx.de> schrieb
>> Welche Wege wurden von der FPC/Lazarus-Community beschritten um diesen
>> Wunsch auch umzusetzen?
> Keine Ahnung. Vermutlich gar keine. Hab ja auch nicht gesagt, dass es
> die Macher von FPC/Lazarus die besseren Diplomaten sind.
Wie stellst Du dir dann eine Standardisierung vor? Die fï¿œllt nicht so vom
Himmel.
Generell versprechen sich die beteiligten Parteien Vorteile durch die
Standardisierung. Die Vorteile fï¿œr Embarcadero sind mir nicht ersichtlich.
>> Damals hat Borland keinen Hehl darum gemacht ein kommerzielles
>> Unternehmen zu sein. Der Erfolg (und das wird in den Unternehmen am
>> Umsatz bemessen) blieb trotz dreier Releases von Kylix aus.
> Lag vermutlich zum Groï¿œteil an den von dir auch weite runten
> beschriebenen Grï¿œnden.
Die Grï¿œnde fï¿œr den Misserfolg von Kylix? Keiner hat's gekauft. Und die
Version 3 (die es zum Abschluss auch bei SuSE fï¿œr 29,- EUR gab) war durchaus
brauchbar.
> Die kostenlose Turbo-Version gibt es ja auch
> nicht mehr. Was passiert? Jeder Dï¿œdel der mit Programmieren anfï¿œngt
> rennt zum VisualStudioExpress.
Das ist in der Tat ein Herausforderung.
--
cu://Matthias.Eissing.de
Heiko Nocon
>Die Gr�nde f�r den Misserfolg von Kylix? Keiner hat's gekauft.
Richtig.
>Und die
>Version 3 (die es zum Abschluss auch bei SuSE f�r 29,- EUR gab) war durchaus
>brauchbar.
Falsch. Versuche doch einfach mal, Kylix selbst oder die damit erzeugten
Programme unter aktuellen Linuxversionen laufen zu lassen. Dann wird
sofort klar, wo das grundlegende Problem von Kylix lag.
Linuxer erkannten das potentielle Problem damals sofort und haben wohl
vor allem auch deshalb nicht gekauft. Warum sollte man auch Geld
ausgeben f�r etwas, was vorhersehbar �rger machen wird, den man
obendrein vorhersehbar nicht selbst beheben k�nnen wird, sondern im
allerbesten Fall gegen erneute Zahlungen irgendwann mal behoben bekommt,
wenn der Lieferant meint, der Leidensdruck w�re nun gro� genug, um ein
teures Update verticken zu k�nnen?
Die Leute sind halt OS gewohnt. Da funktionieren solche
Vendor-LockIn-Mechanismen nicht.
--
Wer Komponenten ohne Quelltext oder richtig miese Komponenten
oder gute Komponenten mit Quelltext, ohne die Source zu verstehen, sich verschafft,
um sie in Form "eigener" Programme in Verkehr zu bringen,
der wird mit Gef�ngnis nicht unter 5 Jahren bestraft.
Hans-Peter Diettrich
> Die Grï¿œnde fï¿œr den Misserfolg von Kylix? Keiner hat's gekauft. Und die
> Version 3 (die es zum Abschluss auch bei SuSE fï¿œr 29,- EUR gab) war
> durchaus brauchbar.
Dem ersten Anschein nach mag Kylix brauchbar gewesen sein, auf Dauer
aber nicht (lief bald nicht mehr), und die Verwendung von Wine hat viele
Linux-Benutzer angewidert.
Im Nachhinein vermute ich, daￜ Wine fￜr das Debuggen unverzichtbar war -
ansonsten bleibt die Frage, wieso der Hersteller nicht in der Lage war,
mit seinem Produkt eine native Linux IDE herzustellen. Sowas gibt
erfahrenen Programmierern schon zu denken...
DoDi
Hans-Peter Diettrich
> Ich kann mich noch an die Zeiten von OS/2 erinnern - alle wollten einen
> Turbo-Pascal-Compiler f�r OS/2, leider gab's nie einen - aus der heutigen
> Perspektive kann man sagen, dass das auch richtig war, OS/2 gibt's auch
> schon lange nicht mehr. Der C++-Compiler f�r OS/2 war auch kein gro�er
> Erfolg, wahrscheinlich kam er schon zu sp�t.
Da liegen mir andere Informationen vor. Etliche Firmen scheinen heute
immer noch OS/2 zu benutzen, und auch den C++ Compiler. Aber das Rennen
um Entwicklungsumgebungen ist dort nat�rlich l�ngst gelaufen.
DoDi
Hans-Peter Diettrich
>> Und weil gro�e Firmen keine Sprachen einsetzen welche nicht
>> standardisiert sind...
>>
>> mfg.
>> Herby
>
> Das halte ich f�r eine Fehleinsch�tzung, dann h�tte nie jemand in einer
> gro�en Firma was mit VB programmieren d�rfen.
Stimmt, bis VB3 war VB ein richtiger Renner, vergleichbar mit .NET heute.
> Weiterhin gibt es ja auch
> unterschiedliche Dialekte von vielen "standardsierten" Sprachen an (z. B.
> SQL, C, C++)... dann h�tte zumindest kein Entwickler in einer gro�en Firma
> die Erweiterungen nutzen d�rfen.
Anfangs haben viele Firmen mehrere C/C++ Compiler eingesetzt, f�rs
Entwickeln und Debuggen andere als f�r die Produktion. Inzwischen d�rfte
das aber kaum noch der Fall sein, jede Firma mu� mit dem
Entwicklungssystem leben, auf das sie sich irgendwann einmal festgelegt hat.
DoDi
Hans-Peter Diettrich
>>> Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit
>>> genommen? Das dauert eine Ewigkeit! Und die EXE-Grￜￜe mal
>>> betrachtet?
>> Das liegt daran, dass dort Debuginformationen mit
>> einkompiliert werden.
>
> Das tut Delphi auch, normalerweise.
Nￜ, die Anwendungen lassen sich mit der Debug-Information fￜr externe
Debugger (TD32...) ganz schï¿œn aufblasen. Eben mal getestet: von 1.2 auf
5.4 MB fï¿œr mein aktuelles Delphi Projekt. Das entspricht dem, was
Lazarus fￜr den gdb verfￜgbar machen muￜ.
Ab Delphi 2010 werden die Anwendungen nochmal um ein paar MB grￜￜer,
durch die neue RTTI, die nicht nur vom Debugger verwendet werden kann,
sondern auch von jedem Decompiler. Mal sehen, ob sich CodeGear doch noch
entschlieï¿œen kann, die neue RTTI einfacher abschaltbar zu machen.
Derzeit haben alle Offiziellen und Halboffiziellen (TeamB) alle Hï¿œnde
voll zu tun, die Auswirkungen klein zu reden...
DoDi
Rudolf Ziegaus
Kann man das heute noch kaufen? Gibt's da noch Weiterentwicklung? Das meine
ich n�mlich mit "gibt's nicht mehr".
Dass das noch jemand einsetzt, mag ja schon sein - aber wie viele sind das
wirklich? Es gibt sicherlich auch noch einige, die DOS einsetzen, aber die
Zahl d�rfte nicht sehr hoch sein.
Rudi
Rudolf Ziegaus
> Hallo Rudolf,
>
> "Rudolf Ziegaus" <Rudolf....@gmx.de> schrieb im
> Newsbeitrag news:j8yn6pcq3e9m$.zowgl81qvh5.dlg@40tude.net...
>
>> On Wed, 14 Oct 2009 19:17:56 +0200, Hubert Seidel wrote:
> ...
>
> Das wird aus verschiedenen Gr�nden doch nur _geduldet_.
> Und nat�rlich gibt es immer Ausnahmen.
>
> mfg.
> Herby
Hm, wei� nicht so recht - wenn man sich mal SQL anschaut, da d�rfte doch
kaum ein Entwickler sich auf "Standard-SQL" beschr�nken, z. B. bei der
Oracle-Variante - ist z. B. PL-SQL im Standard enthalten?
Ich behaupte mal, dass es vielen F�llen gar nicht m�glich ist, vern�nftig
in einem "Standard" zu entwickeln. Es gab ja auch mal vor Unzeiten
"Standard-PASCAL". Allerdings war das ja eher auf die Ausbildung
ausgerichtet. Turbo-Pascal bot von Anfang an mehr (ok, ich kenne es erst
seit Version 3). Ich h�tte jedenfalls schon damals nicht auf die
Erweiterungen verzichten m�gen - so waren im Standard z. B. keine
Random-Zugirffe f�r Dateien vorgesehen.
Das geht nat�rlich mit einer Sprache wie Java leichter - zumindest ging es
bisher einfacher, weil lediglich Sun die Kontrolle dar�ber hatte und die
Weiterentwicklung in einem normierten Prozess ablief. Ob das nun besser
ist, das ist eine ganz andere Frage.
Rudi
Holger Lembke
>Das geht nat�rlich mit einer Sprache wie Java leichter
Ach, ich weiss nicht. Meine letzte Java-Geschichte handelt, wimre (!), von
Marketing-Hubschraubern aus dem Hause IBM und einer kleinen Klitsche ausm
Automobilsektor, die ihr Entwicklungsfassung auf die Produktionsumgebung
schob und einen Produktionsstillstand erlitt. Obwohl das alles
supereinfach, plattformunabh�ngig, hardwareabstrahierend, fast
selbstheilend und mit Sicherheit Weihwasser produzierend ist, lief die
Anwendung lang Zeit nicht wirklich gut in der Produktion. Da brannten
Millionen und Nachtflugverbote wurden zu St�rfaktoren im Personaleinsatz.
R�tsels L�sung war dann irgendeine Bibliothek, die eine wirklich (wirklich,
so 1.0.0.1 zu 1.0.0.2) minimale Versionsnummernabweichung hatte.
Aber klar, an Java hats nicht gelegen.
--
mit freundlichen Gr��en! Password Must Be at Least 18770 Characters
Holgi, +49-531-3497854 ! Can't Repeat Any of Your Previous 30689 Passwords
Rudy Velthuis
> Rudy Velthuis schrieb:
>
> > > > Schon mal ein Hallo Welt mit Lazarus compiliert und die Zeit
> > > > genommen? Das dauert eine Ewigkeit! Und die EXE-Grￜￜe mal
> > > > betrachtet?
> > > Das liegt daran, dass dort Debuginformationen mit
> > > einkompiliert werden.
> >
> > Das tut Delphi auch, normalerweise.
>
> Nￜ, die Anwendungen lassen sich mit der Debug-Information fￜr externe
> Debugger (TD32...) ganz schï¿œn aufblasen. Eben mal getestet: von 1.2
> auf 5.4 MB fï¿œr mein aktuelles Delphi Projekt. Das entspricht dem, was
> Lazarus fￜr den gdb verfￜgbar machen muￜ.
Dan hat Lazarus Pech, dass das soviel ist. Delphi kann seh wohl
Debug-Info einschlieￜen ohne die Grￜￜe so stark auf zu blasen.
> Ab Delphi 2010 werden die Anwendungen nochmal um ein paar MB grￜￜer,
> durch die neue RTTI, die nicht nur vom Debugger verwendet werden
> kann, sondern auch von jedem Decompiler. Mal sehen, ob sich CodeGear
> doch noch entschlieï¿œen kann, die neue RTTI einfacher abschaltbar zu
> machen. Derzeit haben alle Offiziellen und Halboffiziellen (TeamB)
> alle Hï¿œnde voll zu tun, die Auswirkungen klein zu reden...
Da gibt es nichts "kleinzureden". Reflektion/RTTI sind normale
Bestandteile moderner Sprachen, die die Sprache enorm bereichern. Ein
Decompiler kann auch ohne Reflektion gut funktionieren, und es war
immer schon mï¿œglich, Delphi-Programme zu knacken. Daran ï¿œndert RTTI
auch nicht viel.
--
Rudy Velthuis http://rvelthuis.de
"Patriotism is the virtue of the vicious."
-- Oscar Wilde
Heiko Nocon
>Hm, wei� nicht so recht - wenn man sich mal SQL anschaut, da d�rfte doch
>kaum ein Entwickler sich auf "Standard-SQL" beschr�nken
Oh doch. Ich z.B. mu� mich, wo immer es geht, darauf beschr�nken. Unsere
Kunden wollen selbst entscheiden, auf welcher Datenbank unsere L�sungen
ihren Solms ablegen.
Hubert Seidel
"Rudolf Ziegaus" <Rudolf....@gmx.de> schrieb im
Newsbeitrag news:rt7bnngba0dk$.1ge72iy4w5sbf.dlg@40tude.net...
> On Thu, 15 Oct 2009 09:57:37 +0200, Hubert Seidel wrote:
> > "Rudolf Ziegaus" schrieb:
> >> On Wed, 14 Oct 2009 19:17:56 +0200, Hubert Seidel wrote:
> > ...
> > Das wird aus verschiedenen Gr�nden doch nur _geduldet_.
> > Und nat�rlich gibt es immer Ausnahmen.
> Hm, wei� nicht so recht - wenn man sich mal SQL anschaut, da d�rfte
doch
> kaum ein Entwickler sich auf "Standard-SQL" beschr�nken, z. B. bei der
> Oracle-Variante - ist z. B. PL-SQL im Standard enthalten?
(Abgesehen von Heiko's Beispiel mit den aufgef�hrten Einschr�nkungen)
Wenn als Datenbank "Oracle" gesetzt ist, dann bestimmt auch PL/SQL.
Das ist dann der geduldete Teil.
Zudem jede DB seine Performance- bzw. Tuning-Tricks hat.
Ich meine mich zu erinnern, das C# genau aus diesem Grund
standardisiert und offen gelegt wurde, da viele Firmen
sich sonst geweigert h�tten dies einzusetzen.
(Hab jetzt auf die Schnelle keine Literaturhinweise gefunden)
Hans-Peter Diettrich
> Ich behaupte mal, dass es vielen F�llen gar nicht m�glich ist, vern�nftig
> in einem "Standard" zu entwickeln. Es gab ja auch mal vor Unzeiten
> "Standard-PASCAL". Allerdings war das ja eher auf die Ausbildung
> ausgerichtet. Turbo-Pascal bot von Anfang an mehr (ok, ich kenne es erst
> seit Version 3). Ich h�tte jedenfalls schon damals nicht auf die
> Erweiterungen verzichten m�gen - so waren im Standard z. B. keine
> Random-Zugirffe f�r Dateien vorgesehen.
Sobald eine Sprache oder Compiler die Verwendung von (fremdsprachigen)
Bibliotheken erlaubt, sind funktionalen Erweiterungen keine Grenzen mehr
gesetzt.
DoDi
Hans-Peter Diettrich
> Ich meine mich zu erinnern, das C# genau aus diesem Grund
> standardisiert und offen gelegt wurde, da viele Firmen
> sich sonst geweigert h�tten dies einzusetzen.
> (Hab jetzt auf die Schnelle keine Literaturhinweise gefunden)
Welche Sprache (au�er Delphi's OPL) hat keine derartige Spezifikation?
Wie soll man denn �berhaupt Programme schreiben, ohne die Sprachmittel
zu kennen?
DoDi
Hans-Peter Diettrich
>>>> Das liegt daran, dass dort Debuginformationen mit
>>>> einkompiliert werden.
>>> Das tut Delphi auch, normalerweise.
>> Nￜ, die Anwendungen lassen sich mit der Debug-Information fￜr externe
>> Debugger (TD32...) ganz schï¿œn aufblasen. Eben mal getestet: von 1.2
>> auf 5.4 MB fï¿œr mein aktuelles Delphi Projekt. Das entspricht dem, was
>> Lazarus fￜr den gdb verfￜgbar machen muￜ.
>
> Dan hat Lazarus Pech, dass das soviel ist. Delphi kann seh wohl
> Debug-Info einschlieￜen ohne die Grￜￜe so stark auf zu blasen.
Was heiï¿œt hier Pech? Lazarus erlaubt genau wie Delphi auch das Weglassen
der Debug-Information.
>> Ab Delphi 2010 werden die Anwendungen nochmal um ein paar MB grￜￜer,
>> durch die neue RTTI, die nicht nur vom Debugger verwendet werden
>> kann, sondern auch von jedem Decompiler. Mal sehen, ob sich CodeGear
>> doch noch entschlieï¿œen kann, die neue RTTI einfacher abschaltbar zu
>> machen. Derzeit haben alle Offiziellen und Halboffiziellen (TeamB)
>> alle Hï¿œnde voll zu tun, die Auswirkungen klein zu reden...
>
> Da gibt es nichts "kleinzureden". Reflektion/RTTI sind normale
> Bestandteile moderner Sprachen, die die Sprache enorm bereichern. Ein
> Decompiler kann auch ohne Reflektion gut funktionieren, und es war
> immer schon mï¿œglich, Delphi-Programme zu knacken. Daran ï¿œndert RTTI
> auch nicht viel.
Sag ich doch: heftige Versuche, die Sache kleinzureden ;-)
Mï¿œglicherweise war das ja nur ein Pausenfï¿œller, um die Benutzer bei der
Stange zu halten, solange die wirklich wichtigen Neuerungen (64 Bit
Compiler, Multi-Plattform...) nicht fertig werden - und die schiebt
CodeGear seit Jahren immer weiter vor sich her. Oder die schiere
Notwendigkeit, die Benutzer vom Abwandern auf andere
Entwicklungsplattformen abzuhalten...
Es mag zwar chic sein, Features von anderen Sprachen zu importieren, es
ist aber was anderes, diese Features mit ihren unvermeidbaren Nachteilen
allen Benutzern zwangsweise aufzudrï¿œngen. Wie ein Decompiler kï¿œnnen auch
andere Programme ganz gut ohne Reflection funktionieren. Ob sich
Reflection mit Generics vertrï¿œgt, und was sich damit fï¿œr Unfug anstellen
lￜￜt, lasse ich erst mal auￜen vor.
Sobald ich die neue Delphi-Version in die Finger kriege, werde ich mal
testen, ob die IDE die neue RTTI enthï¿œlt. Falls ja, kï¿œnnte eines meiner
nï¿œchsten Projekte ein Decompiler sein, der allen Benutzern klarmacht,
was sie sich damit einhandeln. Und falls nicht, dann ist das der Beweis,
daￜ selbst so komplexe Programme wie die Delphi IDE ohne Reflection
auskommen.
DoDi
Matthias Eissing
"Heiko Nocon" <Heiko...@gmx.net> schrieb
> Dann wird sofort klar, wo das grundlegende Problem von Kylix lag.
Manche sagen, dass das das grundlegende Probleme von Linux ist.
--
cu://Matthias.Eissing.de
Rudy Velthuis
> > Dan hat Lazarus Pech, dass das soviel ist. Delphi kann seh wohl
> > Debug-Info einschlieￜen ohne die Grￜￜe so stark auf zu blasen.
>
> Was heiï¿œt hier Pech? Lazarus erlaubt genau wie Delphi auch das
> Weglassen der Debug-Information.
Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel und
das ist Pech. In Delphi kann ich Debug-Infos einbinden ohne dass das
sehr viel ausmacht.
--
Rudy Velthuis http://rvelthuis.de
"Freedom is not something that anybody can be given, freedom is
something people take."
-- James Baldwin
Heiko Nocon
>Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel und
>das ist Pech. In Delphi kann ich Debug-Infos einbinden ohne dass das
>sehr viel ausmacht.
Du begreifst es offensichtlich nicht. Man kann in Delphi zwei
verschiedene, ich nenne es mal "Level" von Debuginformationen
exportieren.
Das eine Level (was du offensichtlich als einziges kennst), ist das, ich
nenne es mal: "IDE-Level". Das nimmt nur wenig Platz ein, weil der
gr��te Teil der Information dadurch geshared wird, da� zu debuggendes
Programm und Debugger aus derselben M�hle stammen und der Debugger �ber
den Quelltext des zu debuggenden Programmes verf�gt. Genau deswegen und
nur deswegen kann das Datenvolumen f�r die Debuginfos im Executable
derart klein sein.
Das andere Level ist der Export von generischen Debuginformationen, die
f�r jeglichen Debugger nutzbar sind, ob mit oder ohne Quelltext. Die
kann Delphi auch exportieren. Und die sind dann auch �hnlich fett wie
die von Lazarus/FreePascal exportierten.
W�rdest du bitte mal die Checkboxen in den Projektoptionen und deren
Auswirkungen einer n�heren Betrachtung unterziehen, bevor du hier
weitere tendenzi�se Blasen blubberst (dies wahrscheinlich einzig mangels
echter Argumente gegen die OS-L�sung)?
Arno Garrels
> Rudy Velthuis wrote:
>
>> Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel
>> und das ist Pech. In Delphi kann ich Debug-Infos einbinden ohne dass
>> das sehr viel ausmacht.
>
> Du begreifst es offensichtlich nicht. Man kann in Delphi zwei
> verschiedene, ich nenne es mal "Level" von Debuginformationen
> exportieren.
>
> Das eine Level (was du offensichtlich als einziges kennst), ist das,
> ich nenne es mal: "IDE-Level". Das nimmt nur wenig Platz ein, weil der
> Programm und Debugger aus derselben Mühle stammen und der Debugger
> über den Quelltext des zu debuggenden Programmes verfügt. Genau
> deswegen und nur deswegen kann das Datenvolumen für die Debuginfos im
> Executable derart klein sein.
>
> Das andere Level ist der Export von generischen Debuginformationen,
> Die kann Delphi auch exportieren. Und die sind dann auch ähnlich fett
> wie die von Lazarus/FreePascal exportierten.
>
> Auswirkungen einer näheren Betrachtung unterziehen, bevor du hier
> weitere tendenziöse Blasen blubberst (dies wahrscheinlich einzig
> mangels echter Argumente gegen die OS-Lösung)?
OK, nach allem was ich hier lese, kann man neuerdings die Erzeugung von
Debuginformationen über eine Option in der Lazarus IDE steuern, toll.
Aber was ist mit Unicode? Ist die LVCL nun Unicode oder ANSI?
--
Arno Garrels
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7jq3qcF...@mid.individual.net...
Mit "standardisiert und offen gelegt" ist _nicht_ die Hilfe gemeint.
Offen gelegt hin oder her, man kann es auch sch�n reden:
http://www.golem.de/0203/19080.html ;-)
Der finalzielle Druck ist/war mir da etwas plausibler :-)
Aus Sicht eines Auftraggebers:
Der Sinn eines Standards ist u.A. jemand ganz klipp und klar zu
sagen unter welchen Voraussetzungen etwas zu funktionieren hat,
und das ohne tonnen von B�cher (oder Hilfen) auszudrucken.
Beispiel:
a) Ich kann Dich beauftragen etwas zu realisieren was mit dem
"Standard ECMA-334 C# Language Specification" klar kommt.
b) Ich kann Dich beauftragen etwas zu realisieren was mit dem
"Delphi 5" klar kommt.
Und nun folgende Szenarien/�berlegungen:
1. Jemand erstellt ein Konkurenz-Produckt mit
identischen oder gar korrekteren Eigenschaften
Bei a) Wechsel m�glich
Bei b) Vermutlich kommt es gar nicht so weit wg. Patente etc.
2. Es soll Firmen geben welche nur in Sprachen entwickeln
lassen, dessen Compiler im Quellcode offen gelegt ist.
(Irgendwie so, oder �hnlich) Hier kommt Delphi gar nicht zum Zug.
3. Das Produkt wird pl�tzlich eingestellt und enth�llt noch
ein Bug welcher die Produktivit�t stark beeintr�chtigt.
Bei a) besteht die M�glichkeit selber das Problem zu l�sen
Bei b) Kaum eine Chance
4...
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hbacu3$j0m$03$1...@news.t-online.com...
...
> 2. Es soll Firmen geben welche nur in Sprachen entwickeln
> lassen, dessen Compiler im Quellcode offen gelegt ist.
> (Irgendwie so, oder �hnlich) Hier kommt Delphi gar nicht zum Zug.
Vorweg:
Das geschieht sicher nicht ausschlie�lich....
...aber eben halt in sensilen Bereichen.
Hans-Peter Diettrich
> Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel und
> das ist Pech.
Pech ist, wenn Du *ï¿œberhaupt* Debug-Information brauchst :-]
DoDi
Rudy Velthuis
> Du begreifst es offensichtlich nicht.
Ich begreife es nur allzu gut. Siehe den Rest meines Antwortes.
> Man kann in Delphi zwei verschiedene, ich nenne es mal "Level" von
> Debuginformationen exportieren.
Genau. Und in Lazarus nicht. Pech f�r den Lazarus-User. Der muss
entweder das Gro�e Paket einbinden, oder v�llig verzichten.
> Das eine Level (was du offensichtlich als einziges kennst), ist das,
> ich nenne es mal: "IDE-Level".
Ich kenne beide, danke. Es ist mir klar, dass man f�r externe Debugger
viel mehr einbinden muss, aber das muss man ja so selten.
--
Rudy Velthuis http://rvelthuis.de
"Simplicity is prerequisite for reliability" -- Edsger W. Dijkstra
Rudy Velthuis
> Rudy Velthuis schrieb:
>
> > Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel
> > und das ist Pech.
>
> Pech ist, wenn Du ï¿œberhaupt Debug-Information brauchst :-]
Ich mï¿œchte den kennen lernen, der erfolgreich nicht-triviale Programme
schreibt und nie einen braucht.
--
Rudy Velthuis http://rvelthuis.de
"The ink of the scholar is holier than the blood of the
martyr."
-- Prophet Muhammad
Hans-Peter Diettrich
> Mit "standardisiert und offen gelegt" ist _nicht_ die Hilfe gemeint.
> Offen gelegt hin oder her, man kann es auch sch�n reden:
> http://www.golem.de/0203/19080.html ;-)
> Der finalzielle Druck ist/war mir da etwas plausibler :-)
>
> Aus Sicht eines Auftraggebers:
> Der Sinn eines Standards ist u.A. jemand ganz klipp und klar zu
> sagen unter welchen Voraussetzungen etwas zu funktionieren hat,
> und das ohne tonnen von B�cher (oder Hilfen) auszudrucken.
Dazu w�re z.B. bei der C++ Spezifikation schon das Hinzuziehen von
Juristen oder anderweitig vorbelasteten Leuten notwendig, um die vielen
verstreuten Klauseln im Zusammenhang richtig zu interpretieren :-(
Der C# Standard mag da etwas besser konstruiert sein, aber:
> Beispiel:
> a) Ich kann Dich beauftragen etwas zu realisieren was mit dem
> "Standard ECMA-334 C# Language Specification" klar kommt.
> b) Ich kann Dich beauftragen etwas zu realisieren was mit dem
> "Delphi 5" klar kommt.
Meinst Du jetzt: Du gibst einen entsprechenden Compiler in Auftrag?
Wieviele derartige F�lle sind weltweit �berhaupt jemals aufgetreten?
Oder meinst Du eine Anwendung, die dem angegebenen Standard entspricht?
"Delphi 5" umfa�t auch die Standardbibliotheken, so da� bei C# noch die
.NET Version angegeben werden m��te. Womit wir bei vergleichbaren
Situationen landen: funktioniert der Code dann auch mit Delphi 6, oder
mit einer neueren .NET Version oder mit Mono? Wobei "funktionieren"
nicht nur bedeutet, da� der Compiler keine Fehlermeldungen ausspuckt...
> Und nun folgende Szenarien/�berlegungen:
>
> 1. Jemand erstellt ein Konkurenz-Produckt mit
> identischen oder gar korrekteren Eigenschaften
"korrektere Eigenschaften" impliziert, da� m�glicherweise keines der
Produkte v�llig den Spezifikationen entspricht :-(
> Bei a) Wechsel m�glich
Die meisten Spezifikation von Programmiersprachen haben Grauzonen, mit
"undefined" oder "compiler specific" Verhalten. Womit die Verwendung
anderer Compiler (sogar anderer Versionen vom gleichen Hersteller) zu
unerwarteten Ergebnissen f�hren kann.
> Bei b) Vermutlich kommt es gar nicht so weit wg. Patente etc.
Software-Patente gibt es hierzulande nicht.
Ansonsten existieren DotGNU, Mono, Free Pascal und Lazarus bereits...
Aus der Entwicklung von DotGNU wei� ich, da� viele L�cken in der
Spezifikation durch Experimente mit dem .NET Compiler gef�llt werden
mu�ten. Wer garantiert denn f�r die *Vollst�ndigkeit* und *Konsistenz*
irgendeiner Spezifikation?
> 2. Es soll Firmen geben welche nur in Sprachen entwickeln
> lassen, dessen Compiler im Quellcode offen gelegt ist.
> (Irgendwie so, oder �hnlich) Hier kommt Delphi gar nicht zum Zug.
Nun ja, ich kenne keine derartige Firma. Bei Compilern ist
erfahrungsgem�� ein ordentlicher Support viel wichtiger als der
Quellcode. Eine Firma f�ngt doch nicht damit an, eine Truppe f�r die
Pflege des Compilers aufzustellen, sondern damit, einen Compiler f�r die
Entwicklung *eigener* Programme einzusetzen.
> 3. Das Produkt wird pl�tzlich eingestellt und enth�llt noch
> ein Bug welcher die Produktivit�t stark beeintr�chtigt.
> Bei a) besteht die M�glichkeit selber das Problem zu l�sen
> Bei b) Kaum eine Chance
S.o.
Die Chance, einen Bug im Quelltext zu finden und einen brauchbaren
Bugfix zu entwickeln, geht stark gegen Null. Wenn schon der Hersteller
das nicht konnte, und der sollte sich mit seinem Produkt eigentlich
auskennen, dann ist das Au�enstehenden eher v�llig unm�glich.
BTW, hast Du Dir schon mal den Quelltext eines Compilers angeschaut?
Ich habe vor langer Zeit versucht, den gcc Code mit dem CBuilder
�berhaupt nur zum Laufen zu kriegen. Nach ein paar Wochen habe ich dann
aufgegeben, das Projekt war absolut un�bersichtlich :-(
Und AFAIR gab es CygWin oder MinGW damals noch nicht, und damit keine
Chance, den gcc unter Windows zum Laufen zu kriegen.
DoDi
Hans-Peter Diettrich
> OK, nach allem was ich hier lese, kann man neuerdings die Erzeugung von
> Debuginformationen �ber eine Option in der Lazarus IDE steuern, toll.
Wer (au�er Dir) redet von "neuerdings"?
> Aber was ist mit Unicode? Ist die LVCL nun Unicode oder ANSI?
Da sich UTF-8 im Handling nicht wesentlich von Ansi unterscheidet,
betrifft diese Frage ausschlie�lich Delphi. Was der
Anwendungsprogrammierer verwendet, und das jeweilige Target-System,
bleibt diesen �berlassen. AFAIK machen andere Plattformen keine
Unterscheidung zwischen Unicode und Ansi, so wie Windows das macht.
DoDi
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7js3qpF...@mid.individual.net...
> Hubert Seidel schrieb:
>
> > Mit "standardisiert und offen gelegt" ist _nicht_ die Hilfe gemeint.
> > Offen gelegt hin oder her, man kann es auch sch�n reden:
> > http://www.golem.de/0203/19080.html ;-)
> > Der finalzielle Druck ist/war mir da etwas plausibler :-)
> >
> > Aus Sicht eines Auftraggebers:
> > Der Sinn eines Standards ist u.A. jemand ganz klipp und klar zu
> > sagen unter welchen Voraussetzungen etwas zu funktionieren hat,
> > und das ohne tonnen von B�cher (oder Hilfen) auszudrucken.
>
> Dazu w�re z.B. bei der C++ Spezifikation schon das Hinzuziehen von
> Juristen oder anderweitig vorbelasteten Leuten notwendig, um die
vielen
> verstreuten Klauseln im Zusammenhang richtig zu interpretieren :-(
Nur weil ab und an (oder gar oft?) bei Ampeln �ber Rot
gefahren wird, schafft man ja nicht gleich alle Ampel ab ;-)
> Der C# Standard mag da etwas besser konstruiert sein, aber:
>
> > Beispiel:
> > a) Ich kann Dich beauftragen etwas zu realisieren was mit dem
> > "Standard ECMA-334 C# Language Specification" klar kommt.
> > b) Ich kann Dich beauftragen etwas zu realisieren was mit dem
> > "Delphi 5" klar kommt.
>
> Meinst Du jetzt: Du gibst einen entsprechenden Compiler in Auftrag?
Nein. Wenn es kein vern�nftigen Compiler gibt/g�be,
findet sich schon jemand der daran verdienen m�chte und kann.
> Oder meinst Du eine Anwendung, die dem angegebenen Standard
entspricht?
Das meine ich.
> > Und nun folgende Szenarien/�berlegungen:
> >
> > 1. Jemand erstellt ein Konkurenz-Produckt mit
> > identischen oder gar korrekteren Eigenschaften
>
> "korrektere Eigenschaften" impliziert, da� m�glicherweise keines der
> Produkte v�llig den Spezifikationen entspricht :-(
Du machst Ausnahmen zur Regel, oder von welcher Sprache sprichst Du?
Man kann Bugs nicht selten auch mit (Standard-)Bordmittel umgehen.
> > Bei a) Wechsel m�glich
>
> Die meisten Spezifikation von Programmiersprachen haben Grauzonen, mit
> "undefined" oder "compiler specific" Verhalten. Womit die Verwendung
> anderer Compiler (sogar anderer Versionen vom gleichen Hersteller) zu
> unerwarteten Ergebnissen f�hren kann.
Da der Entwickler ggf. in Gew�hrleistung treten muss,
wird er sich an "Best Practice" halten, oder stark bluten.
Undefiniertes Verhalten sollte man eben meiden.
z.b.
procedure TForm1.Button1click(Sender:TObject);
var
a:integer;
begin
Caption:=IntToStr(a);
end;
(Mir f�llt auf die Schnelle kein besseres Beispiel ein,
trifft den Nagel aber nicht unbedingt auf den Kopf...
evtl. eher das NILen von frei gegebenen Instanzen?
neee, eigentlich auch nicht... egal...)
> > Bei b) Vermutlich kommt es gar nicht so weit wg. Patente etc.
>
> Software-Patente gibt es hierzulande nicht.
> Ansonsten existieren DotGNU, Mono, Free Pascal und Lazarus bereits...
Wird schon was �hnliches geben,...
(Copyright, Urheberrecht, oder wasweisich).
> Aus der Entwicklung von DotGNU wei� ich, da� viele L�cken in der
> Spezifikation durch Experimente mit dem .NET Compiler gef�llt werden
> mu�ten. Wer garantiert denn f�r die *Vollst�ndigkeit* und *Konsistenz*
> irgendeiner Spezifikation?
Keine Ahnung. Ist nicht meine Baustelle :-)
> > 2. Es soll Firmen geben welche nur in Sprachen entwickeln
> > lassen, dessen Compiler im Quellcode offen gelegt ist.
> > (Irgendwie so, oder �hnlich) Hier kommt Delphi gar nicht zum Zug.
>
> Nun ja, ich kenne keine derartige Firma. Bei Compilern ist
> erfahrungsgem�� ein ordentlicher Support viel wichtiger als der
> Quellcode. Eine Firma f�ngt doch nicht damit an, eine Truppe f�r die
> Pflege des Compilers aufzustellen, sondern damit, einen Compiler f�r
die
> Entwicklung *eigener* Programme einzusetzen.
Sofern der Quellcode eines Compilers eingesehen werden kann,
reichen Code-Reviews f�r ein gewisses Vertrauen...
> > 3. Das Produkt wird pl�tzlich eingestellt und enth�llt noch
> > ein Bug welcher die Produktivit�t stark beeintr�chtigt.
> > Bei a) besteht die M�glichkeit selber das Problem zu l�sen
> > Bei b) Kaum eine Chance
>
> S.o.
> Die Chance, einen Bug im Quelltext zu finden und einen brauchbaren
> Bugfix zu entwickeln, geht stark gegen Null. Wenn schon der Hersteller
> das nicht konnte, und der sollte sich mit seinem Produkt eigentlich
> auskennen, dann ist das Au�enstehenden eher v�llig unm�glich.
Bug im Quelltext finden ist unm�glich wenn man den Quelltext nicht hat.
Hat man den Quelltext, ist die Warscheinlichkeit unendlich gr��er...
Hubert Seidel
Hallo DoDi,
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7js3qpF...@mid.individual.net...
...
> Die Chance, einen Bug im Quelltext zu finden und einen brauchbaren
> Bugfix zu entwickeln, geht stark gegen Null. Wenn schon der Hersteller
> das nicht konnte, und der sollte sich mit seinem Produkt eigentlich
> auskennen, dann ist das Au�enstehenden eher v�llig unm�glich.
Hast Du schon mal die Wartung f�r ein fremdes Projekt �bernommen?
Ich ja.... und ich habe sowohl Bugs gefunden, also auch gefixt.
Und das ohne der urspr�nglich Hersteller zu sein. Komisch, was ;-?
Warum sollte das bei einem Compiler nicht auch gehen?
Rudy Velthuis
> Hallo *,
>
> "Michael Fuchs" <mik...@gmx.de> schrieb im
> Newsbeitrag news:7jl939F...@mid.individual.net...
>
> > Rudy Velthuis schrieb:
> ...
> > > Und warum sollte sich Delphi von irgendwelchen Standards einengen
> > > lassen?
> >
> > Weil Standards hilfreich sein k�nnen um ein Sprache und damit die
> > zugeh�rigen Produkte zu promoten. Aber wie schon geschrieben, so
> richtig
> > nachdenken tut beim Delphihersteller anscheinend keiner.
>
> Und weil gro�e Firmen keine Sprachen einsetzen welche nicht
> standardisiert sind...
Stimmt nicht.
--
Rudy Velthuis http://rvelthuis.de
"The problem with people who have no vices is that
generally you can be pretty sure they're going to
have some pretty annoying virtues."
-- Elizabeth Taylor
Hans-Peter Diettrich
>>> Wenn man in Lazarus Debug-Information einbindet, ist das sehr viel
>>> und das ist Pech.
>> Pech ist, wenn Du ï¿œberhaupt Debug-Information brauchst :-]
>
> Ich mï¿œchte den kennen lernen, der erfolgreich nicht-triviale Programme
> schreibt und nie einen braucht.
Und dann stￜrt es Dich, daￜ Deine Programme in der Debug-Version ein
wenig grￜￜer werden? Das ist doch lￜcherlich :-O
Was meinst Du dann zur Vergrￜￜerung durch die neuen RTTI?
DoDi
Hans-Peter Diettrich
>> Die Chance, einen Bug im Quelltext zu finden und einen brauchbaren
>> Bugfix zu entwickeln, geht stark gegen Null. Wenn schon der Hersteller
>> das nicht konnte, und der sollte sich mit seinem Produkt eigentlich
>> auskennen, dann ist das Au�enstehenden eher v�llig unm�glich.
>
> Hast Du schon mal die Wartung f�r ein fremdes Projekt �bernommen?
Des�fteren.
> Ich ja.... und ich habe sowohl Bugs gefunden, also auch gefixt.
> Und das ohne der urspr�nglich Hersteller zu sein. Komisch, was ;-?
Da war aber vermutlich auch kein Compiler dabei.
> Warum sollte das bei einem Compiler nicht auch gehen?
Oder bei einem Betriebssystem, oder...
Zum �ben k�nntest Du Dich mal an openXP32 versuchen, oder an Abbrevia.
DoDi
Arno Garrels
> Arno Garrels schrieb:
>
>> OK, nach allem was ich hier lese, kann man neuerdings die Erzeugung
>> toll.
>
> Wer (außer Dir) redet von "neuerdings"?
Als ich Lazarus getestet habe wurde dafür noch ein externes Tool
benötigt.
>
>> Aber was ist mit Unicode? Ist die LVCL nun Unicode oder ANSI?
>
> Da sich UTF-8 im Handling nicht wesentlich von Ansi unterscheidet,
> betrifft diese Frage ausschließlich Delphi.
Nein, meine Frage betrifft ausschließlich das Unicodehandling der
Lazarus VCL unter _Windows. Genauer gefragt, welche Win API, Wide
oder Ansi, benutzt eine LVCL Windows GUI Anwendung?
Windows verwendet intern UTF-16 und nicht UTF-8.
> Was der
> Anwendungsprogrammierer verwendet, und das jeweilige Target-System,
> bleibt diesen überlassen.
Das klingt interessant, dann gibt es die Möglichkeit entweder eine
Unicode oder Ansi Windows GUI Anwendung zu erstellen?
--
Arno Garrels
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7jsl22F...@mid.individual.net...
...
> > Ich ja.... und ich habe sowohl Bugs gefunden, also auch gefixt.
> > Und das ohne der urspr�nglich Hersteller zu sein. Komisch, was ;-?
>
> Da war aber vermutlich auch kein Compiler dabei.
Daf�r gab es andere _einmalige_ Herausforderungen.
Die Anwendung war so umfangreich, das ich die h�tte gar
nicht (vor allem nicht alleine) programieren k�nnen.
Aber die Analyse von gemeldeten Bugs konnte ich sehr
gut/effizient eingrenzen/analysieren und beheben.
> > Warum sollte das bei einem Compiler nicht auch gehen?
> Oder bei einem Betriebssystem, oder...
Genau, Nagel auf den Kopf getroffen!!
Die Frage bleibt von Dir dennoch unbeantwortet ;-)
> Zum �ben k�nntest Du Dich mal an openXP32 versuchen, oder an Abbrevia.
Was glaubst Du, was _mich_ (derzeit) Abbrevia oder openXP32
interessiert?
Und ohne Interesse werde ich mich wohl kaum damit besch�ftigen ;-)
Hab mal gelernt das man nicht immer von sich auf andere schlie�en soll.
Damit Du Dich nicht auf den Schlips getreten f�hlst:
Es gibt viele Dinge die _ich_ nicht kann, aber andere daf�r umso besser.
Ich kann daf�r andere Dinge sehr gut. Da kommt schon einiges zusammen
:-)
Und wenn man f�r etwas Interesse hat, gehts vielfach einfacher...
Man muss aber nicht gleich das Interesse haben das Rad neu zu erfinden.
Aber wenn, dann sollte auch das kein Problem sein.
Rudy Velthuis
> Rudy Velthuis schrieb:
>
> > > > Wenn man in Lazarus Debug-Information einbindet, ist das sehr
> > > > viel und das ist Pech.
> > > Pech ist, wenn Du ï¿œberhaupt Debug-Information brauchst :-]
> >
> > Ich mï¿œchte den kennen lernen, der erfolgreich nicht-triviale
> > Programme schreibt und nie einen braucht.
>
> Und dann stￜrt es Dich, daￜ Deine Programme in der Debug-Version ein
> wenig grￜￜer werden? Das ist doch lￜcherlich :-O
Das stï¿œrt MICH gar nicht. Es waren andere, die das als Nachteil sahen.
--
Rudy Velthuis http://rvelthuis.de
"And the users exclaimed with a laugh and a taunt: 'It's just what
we asked for but not what we want.'"
Heiko Nocon
>Heiko Nocon wrote:
>> Man kann in Delphi zwei verschiedene, ich nenne es mal "Level" von
>> Debuginformationen exportieren.
>
>Genau. Und in Lazarus nicht. Pech f�r den Lazarus-User. Der muss
>entweder das Gro�e Paket einbinden, oder v�llig verzichten.
Ja. Ich sehe allerdings das Problem nicht (oder sagen wir mal: kaum).
Solange ein Programm sich auf dem Entwicklungssystem befindet, spielt
die Menge der Debuginformationen im Executable absolut keine Rolle. Also
der Teil ist damit wohl schonmal abgehakt.
Kommen wir also zur Release-Version. Die sollte normalerweise keinerlei
Debuginformationen ben�tigen, schlie�lich ist sie zum Arbeiten da und
nicht zum Debuggen. Also normalerweise auch kein Problem, man bindet
einfach keine Debuginformationen ein. Der Teil ist also auch abgehakt.
Was als einziges bleibt, ist der Sonderfall "RTTI-Nutzung". Nun, wessen
Programm davon abh�ngig ist, der hat per Definition einen schweren
Designfehler begangen, denn sowas widerspricht den Grundkonzepten von
ObjectPascal.
Ich gebe allerdings gerne zu, da� es Aufgabenstellungen geben kann, bei
denen sowas wie Delphi-RTTI (oder, allumfassende Ausformung desselben
Prinzips: .Net-Reflection) n�tzlich sein k�nnen.
Aber wenn mich nicht alles t�uscht (ausprobiert habe ich das allerdings
noch nicht, deswegen bitte diesen Absatz nicht als stichhaltiges
Argument, sondern nur als Spekulation werten), dann sollte es mit
Lazarus/FP sogar m�glich sein, gezielt eventuell ben�tigten
RTT-Informationen in das Release-Executable zu exportieren.
Falls ich mit meiner Analyse richtig liegen sollte, dann d�rfte die
Sache bez�glich dieses Problems sogar erheblich effizienter sein als der
"IDE-Level" von Delphi, weil eben nur der unbedingt ben�tigte Teil
exportiert wird und kein bissel mehr.
Michael Fuchs
> Generell versprechen sich die beteiligten Parteien Vorteile durch die
> Standardisierung. Die Vorteile fï¿œr Embarcadero sind mir nicht ersichtlich.
Bessere Verbreitung von Pascal. Stï¿œrkere Community. Damit wird es
interessanter fï¿œr. Und damit gibt es mehr potentielle Abnehmer.
Nebenbei kann man auch voneinander lernen. Freepascal kann zum Beispiel
schon 64Bit.
mfg
Micha
--
Meine Wanderungen durch Realitï¿œt und Cyberspace
auf --> http://www.michael-fuchs.net <--
Rudy Velthuis
> Was als einziges bleibt, ist der Sonderfall "RTTI-Nutzung". Nun,
> wessen Programm davon abh�ngig ist, der hat per Definition einen
> schweren Designfehler begangen, denn sowas widerspricht den
> Grundkonzepten von ObjectPascal.
Inwiefern? RTTI hat es immer gegeben und war immer wichtig f�r Delphi
(f�r den Object Inspector, f�r das DFM-System, aber auch z.B. f�r die
Initialisierung und Finalisierung von referenzz�hlenden Typen). Delphi
entwickelt sich weiter, und es gibt schon viele Leute die sch�ne Dinge
mit der erweiterten RTTI planen. Es ist f�r viele eine richtige
Bereicherung.
Erweiterte RTTI ist vielleicht nicht so wichtig f�r geschlossene,
statische Programme von einem Autor or Autorenteam, aber es ist sehr
hilfreich f�r Bibliotheken die Dinge automatisieren wollen und f�r
alles Dynamische, wo diese Informationen nicht zur Entwicklingszeit
bekannt sind.
--
Rudy Velthuis http://rvelthuis.de
"It is better to have a permanent income than to be fascinating."
-- Oscar Wilde (1854-1900)
Rudy Velthuis
> dann
> sollte es mit Lazarus/FP sogar m�glich sein, gezielt eventuell
> ben�tigten RTT-Informationen in das Release-Executable zu exportieren.
> Falls ich mit meiner Analyse richtig liegen sollte, dann d�rfte die
> Sache bez�glich dieses Problems sogar erheblich effizienter sein als
> der "IDE-Level" von Delphi, weil eben nur der unbedingt ben�tigte Teil
> exportiert wird und kein bissel mehr.
Was f�r ein "IDE-Level"? Ick kriege den Eindruck, du verstehst gar
nicht, was das neue RTTI in Delphi ist oder wozu es dienen kann,oder
was die neuen Attribute sind. Die Delphi-RTTI wird im Release-Excutable
exportiert und hat mit Debug-Information nichts zu tun. Man benutzt die
Delphi-Runtime um sie auszulesen, und Attribute um selber RTTI zu
definieren.
--
Rudy Velthuis http://rvelthuis.de
"We all agree that your theory is crazy, but is it crazy enough?"
-- Niels Bohr (1885-1962)
Björn Schreiber
> Aber was ist mit Unicode? Ist die LVCL nun Unicode oder ANSI?
Leider nicht einheitlich:
Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
weiterhin ANSI (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
Und damit das Durcheinander noch komplett wird entwickel ich momentan
mit Lazarus f�r Windows CE - und das "spricht" nur WideString ;).
Gr��e,
Bj�rn
--
Bj�rn Schreiber, DRIGUS GmbH
new...@drigus.de
Bei Email NOSPAM in den Betreff aufnehmen.
Put NOSPAM in subject to reach me by email.
Arno Garrels
> Arno Garrels schrieb:
>
>> Aber was ist mit Unicode? Ist die LVCL nun Unicode oder ANSI?
>
> Leider nicht einheitlich:
>
> Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
> weiterhin ANSI
> (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
Da wird einem ja schwindelig vor lauter String-Konvertiererei. Ob das
wohl performant ist? Ich weiß zwar nicht wie UTF8ToAnsi und AnsiToUTF8
implementiert sind, aber in Windows sind das sogar zwei Konvertierungen,
einmal nach UTF-16 und danach wieder zurück nach Ansi mit der anderen
Ansi-Codepage. Und für die Anzeige in Windows muss dann nochmal nach
UTF-16 konvertiert werden. Ein überzeugendes String-Konzept ist das
m.E. nicht.
--
Arno Garrels
Björn Schreiber
> Ob das wohl performant ist?
Kann ich nicht sagen. Ist f�r unsere geplante Anwendung aber auch
nicht ausschlaggebend.
> Ein �berzeugendes String-Konzept ist das
> m.E. nicht.
Ja, im Moment bereitet mir das ganze auch noch etwas Kopfzerbrechen.
Hans-Peter Diettrich
>> Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
>> weiterhin ANSI
>> (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
>
> Da wird einem ja schwindelig vor lauter String-Konvertiererei. Ob das
> wohl performant ist?
In den meisten F�llen ist der Aufwand f�r die Konvertierung
vernachl�ssigbar, gegen�ber dem, was in dem Aufruf sonst noch passiert.
> Ich wei� zwar nicht wie UTF8ToAnsi und AnsiToUTF8
> implementiert sind, aber in Windows sind das sogar zwei Konvertierungen,
> einmal nach UTF-16 und danach wieder zur�ck nach Ansi mit der anderen
> Ansi-Codepage.
IMO hast Du da was falsch verstanden. UTF-8 steht im AnsiString drin und
wird in einem Rutsch nach WideString konvertiert. Wenn ein Programm
sowieso mit Unicode arbeitet, werden keine anderen Ansi-Codepages ben�tigt.
> Und f�r die Anzeige in Windows muss dann nochmal nach
> UTF-16 konvertiert werden. Ein �berzeugendes String-Konzept ist das
> m.E. nicht.
Es ist das flexibelste Multi-Plattform Konzept. Viele Plattformen k�nnen
mit UTF-16 weniger anfangen als mit UTF-8, und es wird kein weiterer
String Typ ben�tigt, der i.d.R. nur mehr Platz braucht als ein
entsprechender UTF-8 String (von Chinesisch mal abgesehen). Wer speziell
f�r Windows programmiert, kann ja auch WideString verwenden, der AFAIR
von FPC so verwaltet wird wie der neue UnicodeString. Die Controls des
Win32 Widgetset k�nnen den �bergebenen String intern ja als WideString
speichern, so da� nur bei �nderungen eine Konvertierung notwendig wird -
und dann ist der Aufwand rund um die �nderung auch wieder meist h�her
als die Konvertierung selbst. Daneben kennt FPC auch einen echten (UCS4)
Unicode String.
M�glicherweise ist Dir auch entgangen, da� UTF-16 kein UCS4 ist, ein
Text also auch Zeichen mit mehr als einem WideChar enthalten kann. Wer
sich von seinem liebgewordenen Ansi Stringhandling nicht trennen m�chte,
und weiterhin davon ausgehen m�chte, da� 1 Zeichen = 1 Char ist, der
kann ja (im Gegensatz zu Delphi) auch mit UCS4String arbeiten.
Andernfalls fliegt er irgendwann auf die Schnauze, wenn ein WideChar
dummerweise nur ein halbes Unicode-Zeichen enth�lt. Delphi-Programmierer
haben noch viel �ber Unicode zu lernen, wenn sie tats�chlich mit Zeichen
au�erhalb ihrer gewohnten Ansi-Codepage arbeiten wollen.
DoDi
Arno Garrels
> Arno Garrels schrieb:
>
>>> Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
>>> weiterhin ANSI
>>> (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
>>
>> Da wird einem ja schwindelig vor lauter String-Konvertiererei. Ob das
>> wohl performant ist?
>
> vernachlässigbar, gegenüber dem, was in dem Aufruf sonst noch
> passiert.
String-Konvertierungen sind teuer und sollten, wenn möglich,
vermieden werden.
>> Ich weiß zwar nicht wie UTF8ToAnsi und AnsiToUTF8
>> implementiert sind, aber in Windows sind das sogar zwei
>> Konvertierungen, einmal nach UTF-16 und danach wieder zurück nach
>> Ansi mit der anderen Ansi-Codepage.
>
> IMO hast Du da was falsch verstanden. UTF-8 steht im AnsiString drin
> und wird in einem Rutsch nach WideString konvertiert. Wenn ein
> Programm sowieso mit Unicode arbeitet, werden keine anderen
> Ansi-Codepages benötigt.
Verstehe ich nicht. Nehmen wir doch mal das erste Bsp.:
var
MyString: string; // utf-8 encoded
begin
MyString := MyTEdit.Text;
SomeRTLRoutine(UTF8ToAnsi(MyString));
end;
Dann ist die Eigenschaft TEdit.Text ein UTF-8 kodierer Ansistring.
Das bedeutet doch, dass sogar ein WideString noch explizit nach
UTF-8 gewandelt werden muss, oder nehmen die Controls optional auch
WideString?
Also z.B.:
var
MyString: WideString; // utf-16 encoded
begin
MyString := UTF8ToWide(MyTEdit.Text); // TM
SomeRTLRoutine(WideToAnsi(MyString)); // TM
end;
Nächster Punkt ist drohender Datenverlust bei der Umwandlung von
Unicode nach ANSI vor dem Aufruf der RTL Routine. Mal angenommen
der Benutzer gibt Zeichen aus einer anderen als der aktuellen
System-Ansi-Codepage ein, schon hast du ein Problem.
>
>> Und für die Anzeige in Windows muss dann nochmal nach
>> UTF-16 konvertiert werden. Ein überzeugendes String-Konzept ist das
>> m.E. nicht.
>
> Es ist das flexibelste Multi-Plattform Konzept. Viele Plattformen
> können mit UTF-16 weniger anfangen als mit UTF-8, und es wird kein
> weiterer String Typ benötigt, der i.d.R. nur mehr Platz braucht als
> ein entsprechender UTF-8 String (von Chinesisch mal abgesehen).
Keine Ahnung, arbeitet MAC-OS denn intern mit UTF-8?
> Wer
> speziell für Windows programmiert, kann ja auch WideString verwenden,
Meinem Beispiel oben folgend geht das auch nicht nicht ohne Konvertierung.
> der AFAIR
> von FPC so verwaltet wird wie der neue UnicodeString.
Es ist zumindest ein referenzgezählter Typ, nicht zu verwechseln mit
dem WideString von Delphi.
> Die Controls des
> Win32 Widgetset können den übergebenen String intern ja als WideString
> speichern, so daß nur bei Änderungen eine Konvertierung notwendig
> wird - und dann ist der Aufwand rund um die Änderung auch wieder
> meist höher
> als die Konvertierung selbst.
Meine Vergleiche zwischen Ansi- und UTF16-Delphi sagen da etwas anderes.
> Daneben kennt FPC auch einen echten
> (UCS4) Unicode String.
Auch mit UCS4String ist man nicht sämtliche Sorgen los, Stichwort
"Normalisierung".
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbhp2f$e09$1...@online.de...
>Bj�rn Schreiber wrote:
...
>> Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
>> weiterhin ANSI
>> (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
>
>Da wird einem ja schwindelig vor lauter String-Konvertiererei. Ob das
>wohl performant ist? Ich weiďż˝ zwar nicht wie UTF8ToAnsi und
Das ist/war auch meine Bef�rchtung...
>AnsiToUTF8 implementiert sind, aber in Windows sind das sogar zwei
>Konvertierungen,
>einmal nach UTF-16 und danach wieder zur�ck nach Ansi mit der anderen
>Ansi-Codepage. Und f�r die Anzeige in Windows muss dann nochmal nach
>UTF-16 konvertiert werden.
Wenn ich richtig recherchiert habe, und sich bei neueren
Versionen (>fpc 2.2.3) nichts ge�ndert hat, auch da!
>Ein �berzeugendes String-Konzept ist das m.E. nicht.
Anbei meine Recherchen dazu:
Also... laut ...\lazarus\fpc\2.2.3\source\rtl\inc\readme\readme
systemh.inc Interface part of the system unit.
und dann, via systemh.inc nach wstringh.inc, darin findet man:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
function UTF8Decode(const s : UTF8String): WideString;
var
i : SizeInt;
hs : WideString;
begin
result:='';
if s='' then
exit;
SetLength(hs,length(s));
i:=Utf8ToUnicode(PWideChar(hs),length(hs)+1,pchar(s),length(s));
if i>0 then
begin
SetLength(hs,i-1);
result:=hs;
end;
end;
function Utf8ToAnsi(const s : UTF8String) : ansistring;{$ifdef
SYSTEMINLINE}inline;{$endif}
begin
Result:=Utf8Decode(s);
end;
...
UTF8ToUnicode dann in utf8bidi.pp:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
type
TUTF8Char = String[4];
...
function UTF8ToUCS16(const UTF8Char:TUTF8Char):TUCS16Char;
begin
case Length(UTF8Char) of
1:{regular single byte character (#0 is a normal char, this is
UTF8Charascal ;)}
Result := ord(UTF8Char[1]);
2:
Result := ((ord(UTF8Char[1]) and %00011111) shl 6)
or (ord(UTF8Char[2]) and %00111111);
else
Result := $FFFF;
end;
end;
...
function UTF8ToUnicode(const Src:TUTF8String):TString;
var
lp, vp:Integer;
c:TUTF8Char;
begin
lp := 1;
vp := 0;
SetLength(Result, Length(Src));
while lp <= Length(Src) do
begin
vp += 1;
c := LCharOf(Src, lp);
Result[vp] := WideChar(UTF8ToUCS16(c));
lp += Length(c);
end;
SetLength(Result, vp);
end;
...
Wenn das nichts ist.... ;-)
Kein Wunder:
Die CPUI's werden immer schneller,
die Programme immer langsamer!-((
Was kann da der Optimizer optimieren?
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7k3eitF...@mid.individual.net...
> Arno Garrels schrieb:
...
> > Ich wei� zwar nicht wie UTF8ToAnsi und AnsiToUTF8
> > implementiert sind, aber in Windows sind das sogar zwei
Konvertierungen,
> > einmal nach UTF-16 und danach wieder zur�ck nach Ansi mit der
anderen
> > Ansi-Codepage.
>
> IMO hast Du da was falsch verstanden. UTF-8 steht im AnsiString drin
und
> wird in einem Rutsch nach WideString konvertiert. Wenn ein Programm
> sowieso mit Unicode arbeitet, werden keine anderen Ansi-Codepages
ben�tigt.
Was habe ich in news:hbiear$k38$02$1...@news.t-online.com falsch
recherchiert?
In welcher Funktion geschieht die Konvertierung in einem Rutsch?
(Ich denke, Du kannst bestimmt eine Datei/Unit/Include nennen)
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hbiear$k38$02$1...@news.t-online.com...
...
> function Utf8ToAnsi(const s : UTF8String) : ansistring;{$ifdef
> SYSTEMINLINE}inline;{$endif}
> begin
> Result:=Utf8Decode(s);
> end;
> ...
...
Bevor die Frage aufkommt...
UTF8String = type ansistring;
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hbiear$k38$02$1...@news.t-online.com...
> "Arno Garrels" schrieb:
...
> >Da wird einem ja schwindelig vor lauter String-Konvertiererei. Ob das
> >wohl performant ist? Ich wei� zwar nicht wie UTF8ToAnsi und
> Das ist/war auch meine Bef�rchtung...
Ich habe die FPC-Anteile f�r UTF8toAnsi nach Delphi5
(mit bestem Wissen und Gewissen) portiert, und komme
bei einer Konvertierung von nur einem Euro-Zeichen
auf rund 5000 CPU-Takte... naja... wenn das _nichts_ ist?
Dabei ist das bereits der _beste_ Wert von 1000 in einer
Schleife, ber der der 1st-Level-Cache nat�rlich greift!!
Da die Units bei FPC auf zwei Units verteilt sind, habe
ich diese ebenfalls auf u01 und u02 entsprechend verteilt.
Nat�rlich habe ich beim Portieren festgestellt das noch
viel mehr Code ben�tigt wird, als urspr�nglich angenommen.
Um evtl. "Verfahrensfehler" zu identifizieren, hier der Code:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[main.pas]
...
uses
u01;
function RdTsc:Int64; assembler;
asm
db $0F,$31 { rdtsc }
end;
procedure TForm1.Button1Click(Sender: TObject);
var
utf8:UTF8String;
s:ansistring;
i:integer;
t1,t2,t3,m12,m23:Int64;
begin
utf8:=#$E2#$82#$AC;
m12:=MaxInt;
m23:=m12;
for i:=0 to 1000 do
begin
t1:=RdTsc;
t2:=RdTsc;
s:=Utf8ToAnsi(utf8);
t3:=RdTsc;
if (t2-t1<m12) then m12:=t2-t1;
if (t3-t2<m23) then m23:=t3-t2;
end;
Caption:=s+' '+IntToStr(m23-m12);
end;
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[u01.pas]
unit u01;
interface
type
UTF8String = type ansistring;
TUTF8String = UTF8String;
SizeInt = integer;
SizeUInt = cardinal;
function Utf8ToAnsi(const s:UTF8String):ansistring;
function Utf8ToUnicode(Dest: PWideChar; Source: PChar; MaxChars:
SizeInt): SizeInt;{$ifdef SYSTEMINLINE}inline;{$endif} overload;
function Utf8ToUnicode(Dest: PWideChar; MaxDestChars: SizeUInt; Source:
PChar; SourceBytes: SizeUInt): SizeUInt; overload;
implementation
uses
u02;
function strlen(const Source: PChar):integer;
begin
Result:=Length(Source);
end;
function Utf8ToUnicode(Dest: PWideChar; Source: PChar; MaxChars:
SizeInt): SizeInt;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
if assigned(Source) then
Result:=Utf8ToUnicode(Dest,MaxChars,Source,strlen(Source))
else
Result:=0;
end;
function Utf8ToUnicode(Dest: PWideChar; MaxDestChars: SizeUInt; Source:
PChar; SourceBytes: SizeUInt): SizeUInt;
var
i,j : SizeUInt;
w: SizeUInt;
b : byte;
begin
if not assigned(Source) then
begin
result:=0;
exit;
end;
result:=SizeUInt(-1);
i:=0;
j:=0;
if assigned(Dest) then
begin
while (j<MaxDestChars) and (i<SourceBytes) do
begin
b:=byte(Source[i]);
w:=b;
inc(i);
// 2 or 3 bytes?
if b>=$80 then
begin
w:=b and $3f;
if i>=SourceBytes then
exit;
// 3 bytes?
if (b and $20)<>0 then
begin
b:=byte(Source[i]);
inc(i);
if i>=SourceBytes then
exit;
if (b and $c0)<>$80 then
exit;
w:=(w shl 6) or (b and $3f);
end;
b:=byte(Source[i]);
w:=(w shl 6) or (b and $3f);
if (b and $c0)<>$80 then
exit;
inc(i);
end;
Dest[j]:=WideChar(w);
inc(j);
end;
if j>=MaxDestChars then j:=MaxDestChars-1;
Dest[j]:=#0;
end
else
begin
while i<SourceBytes do
begin
b:=byte(Source[i]);
inc(i);
// 2 or 3 bytes?
if b>=$80 then
begin
if i>=SourceBytes then
exit;
// 3 bytes?
b := b and $3f;
if (b and $20)<>0 then
begin
b:=byte(Source[i]);
inc(i);
if i>=SourceBytes then
exit;
if (b and $c0)<>$80 then
exit;
end;
if (byte(Source[i]) and $c0)<>$80 then
exit;
inc(i);
end;
inc(j);
end;
end;
result:=j+1;
end;
function UTF8Decode(const s : UTF8String): WideString;
var
i : SizeInt;
hs : WideString;
begin
result:='';
if s='' then exit;
SetLength(hs,length(s));
i:=Utf8ToUnicode(PWideChar(hs),length(hs)+1,pchar(s),length(s));
if i>0 then
begin
SetLength(hs,i-1);
result:=hs;
end;
end;
function Utf8ToAnsi(const s:UTF8String):ansistring;
begin
Result:=Utf8Decode(s);
end;
end.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[u02.pas]
unit u02;
interface
uses
u01;
type
TUTF8Char = String[4];
TUCS16Char = Word;
TString = WideString;
function UTF8ToUnicode(const Src:TUTF8String):TString;
implementation
function UTF8ToUCS16(const UTF8Char:TUTF8Char):TUCS16Char;
begin
case Length(UTF8Char) of
1:{regular single byte character (#0 is a normal char, this is
UTF8Charascal ;)}
Result := ord(UTF8Char[1]);
2:
Result := ((ord(UTF8Char[1]) and $1F) shl 6)
or (ord(UTF8Char[2]) and $3F);
else
Result := $FFFF;
end;
end;
function ComputeCharLength(p:PChar):Cardinal;
begin
if ord(p^)<$C0
then
{regular single byte character (#0 is a normal char, this is
UTF8Charascal ;)}
Result:=1
else if ((ord(p^) and $E0) = $C0)
then
if (ord(p[1]) and $C0) = $80 then
Result:=2
else
Result:=1
else if ((ord(p^) and $F0) = $E0)
then
if ((ord(p[1]) and $C0) = $80)
and ((ord(p[2]) and $C0) = $80)
then
Result:=3
else
Result:=1
else if ((ord(p^) and $F8) = $F0)
then
if ((ord(p[1]) and $C0) = $80)
and ((ord(p[2]) and $C0) = $80)
and ((ord(p[3]) and $C0) = $80)
then
Result:=4
else
Result:=1
else
Result:=1
end;
function LCharOf(UTF8String:TUTF8String; lp:Integer):TUTF8Char;
begin
if lp > Length(UTF8String)
then
Result:='';
Exit;
while(lp > 0) and ((Ord(UTF8String[lp]) and $F0) in [$80..$B0]) do
begin
Dec(lp);
end;
if lp = 0
then
Result:='';
Exit;
Move(UTF8String[lp], Result[1], SizeOf(TUTF8Char) - 1);
SetLength(Result, ComputeCharLength(@Result[1]));
end;
function UTF8ToUnicode(const Src:TUTF8String):TString;
var
lp, vp:Integer;
c:TUTF8Char;
begin
lp := 1;
vp := 0;
SetLength(Result, Length(Src));
while lp <= Length(Src) do
begin
vp := vp + 1;
c := LCharOf(Src, lp);
Result[vp] := WideChar(UTF8ToUCS16(c));
lp := lp + Length(c);
end;
SetLength(Result, vp);
end;
end.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Viel Spa� bei Testen!
mfg.
Herby
P.S:
Bei so vielen CPU-Takte, erspare ich
mir den Einzelschritt im Debugger ;-)
P.P.S:
Zu meinem Erstaunen ;-) kommt tats�chlich ein Euro-Zeichen raus!
--
http://www.hubert-seidel.eu
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im Newsbeitrag
news:hbiklc$1ju$02$1...@news.t-online.com...
> Und weil ich es nun ganz genau wissen wollte...
Okay... es lag daran das ich es zuvor nicht geschafft hatte
RDTSC unter FPC zu implementieren,... jetzt geht es...
...habe ich nun den Test wie folgt unter FPC wiederholt:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[main.pas]
...
{$asmmode intel}
function RdTsc:Int64; assembler;
asm
db $0F,$31 { rdtsc }
end;
procedure TForm1.Button1Click(Sender: TObject);
var
utf8:UTF8String;
s:ansistring;
i:integer;
t1,t2,t3,m12,m23:Int64;
begin
utf8:=AnsiToUtf8('?'); // Euro-Zeichen //
m12:=MaxInt;
m23:=m12;
for i:=0 to 1000 do
begin
t1:=RdTsc;
t2:=RdTsc;
s:=Utf8ToAnsi(utf8);
t3:=RdTsc;
if (t2-t1<m12) then m12:=t2-t1;
if (t3-t2<m23) then m23:=t3-t2;
end;
Caption:=s+' '+IntToStr(m23-m12);
end;
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Und komme auf Rund 5500 CPU-Takte.
Das sind sogar 500 mehr als in der Delphi5-Version!
Sind glatte 10% nochmal oben drauf... fast wie Sonderangebot ;-)
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im Newsbeitrag
news:hbim6t$i2$00$1...@news.t-online.com...
...
> Und komme auf Rund 5500 CPU-Takte.
> Das sind sogar 500 mehr als in der Delphi5-Version!
> Sind glatte 10% nochmal oben drauf... fast wie Sonderangebot ;-)
Au�erhalb der IDE sind beide Versionen schneller:
Delphi 5: ca. 1800 CPU-Takte
FPC 2.2.3: ca. 2000 CPU-Takte
(immer noch 10% bzw. gar 11% langsamer als bei D5)
mfg.
Herby
P.S:
Was man dabei nicht vergessen sollte...
wenn ein einfaches Kopieren pro Zeichen 4 Takte ben�tigen
w�rde, w�ren das bereits 500 mal langsamer!!!
Vermutlich werden gar weniger ben�tigt, was
den Faktor vermutlich weit �ber 1000 bringt...
--
http://www.hubert-seidel.eu
Christian Gudrian
<DrDiet...@aol.com>:
> Da sich UTF-8 im Handling nicht wesentlich von Ansi unterscheidet,
Man darf sich dadurch aber nicht verleiten lassen, UTF-8 mit Ansi
gleichzusetzen. Ansi braucht immer noch die Angabe einer Codepage, um
eindeutig zu sein, UTF-8 nicht. Solange man sich auf nacktes ASCII
beschränkt (also alles unterhalb von Zeichencode 128), kann einem gar
nichts passieren. Doch spätestens bei Umlauten trennen sich die Wege: die
brauchen UTF-8-kodiert nämlich schon zwei Bytes.
Christian
Hans-Peter Diettrich
>> In den meisten F�llen ist der Aufwand f�r die Konvertierung
>> vernachl�ssigbar, gegen�ber dem, was in dem Aufruf sonst noch
>> passiert.
>
> String-Konvertierungen sind teuer und sollten, wenn m�glich,
> vermieden werden.
Nenne mal Beispiele. Mir fallen vor allem CreateFile und FindFile ein,
und da dauern die Plattenzugriffe l�nger als die Konvertierung.
>> IMO hast Du da was falsch verstanden. UTF-8 steht im AnsiString drin
>> und wird in einem Rutsch nach WideString konvertiert. Wenn ein
>> Programm sowieso mit Unicode arbeitet, werden keine anderen
>> Ansi-Codepages ben�tigt.
>
> Verstehe ich nicht. Nehmen wir doch mal das erste Bsp.:
>
> var
> MyString: string; // utf-8 encoded
> begin
> MyString := MyTEdit.Text;
> SomeRTLRoutine(UTF8ToAnsi(MyString));
> end;
Setze die Codepage Deiner Anwendung auf UTF-8, dann kannst Du Dir die
Konvertierung sparen.
> Dann ist die Eigenschaft TEdit.Text ein UTF-8 kodierer Ansistring.
> Das bedeutet doch, dass sogar ein WideString noch explizit nach
> UTF-8 gewandelt werden muss, oder nehmen die Controls optional auch
> WideString?
Wozu extra WideString, wenn UTF-8 ohne Erweiterungen auskommt?
> Also z.B.:
> var
> MyString: WideString; // utf-16 encoded
> begin
> MyString := UTF8ToWide(MyTEdit.Text); // TM
> SomeRTLRoutine(WideToAnsi(MyString)); // TM
> end;
Sofern vorhanden, kannst Du die Unicode-Version von SomeRTLRoutine
direkt aufrufen.
> N�chster Punkt ist drohender Datenverlust bei der Umwandlung von
> Unicode nach ANSI vor dem Aufruf der RTL Routine. Mal angenommen
> der Benutzer gibt Zeichen aus einer anderen als der aktuellen
> System-Ansi-Codepage ein, schon hast du ein Problem.
Mit der UTF-8 Codepage gibt es keine derartigen Probleme.
> Keine Ahnung, arbeitet MAC-OS denn intern mit UTF-8?
Auch Kai Neahnung :-(
>> Wer
>> speziell f�r Windows programmiert, kann ja auch WideString verwenden,
>
> Meinem Beispiel oben folgend geht das auch nicht nicht ohne Konvertierung.
Die WideString Versionen des WinAPI kannst Du wie in Delphi auch direkt
aufzurufen.
>> der AFAIR
>> von FPC so verwaltet wird wie der neue UnicodeString.
>
> Es ist zumindest ein referenzgez�hlter Typ, nicht zu verwechseln mit
> dem WideString von Delphi.
Was gibt es da zu verwechseln? Der Komfort ist gr��er, sonst �ndert sich
nichts.
>> Die Controls des
>> Win32 Widgetset k�nnen den �bergebenen String intern ja als WideString
>> speichern, so da� nur bei �nderungen eine Konvertierung notwendig
>> wird - und dann ist der Aufwand rund um die �nderung auch wieder
>> meist h�her
>> als die Konvertierung selbst.
>
> Meine Vergleiche zwischen Ansi- und UTF16-Delphi sagen da etwas anderes.
Delphi ist ja auch nicht multi-platform :-(
Lazarus kennt neben dem Win32 widgetset auch noch qt, gtk, gtk2 usw.,
was eben so auf den verschiedenen Plattformen verwendet wird.
>> Daneben kennt FPC auch einen echten
>> (UCS4) Unicode String.
>
> Auch mit UCS4String ist man nicht s�mtliche Sorgen los, Stichwort
> "Normalisierung".
Wer sich auf Unicode einl��t, handelt sich diverse Sorgen ein. Und jeder
mu� auf seine Art damit klarkommen...
DoDi
Hans-Peter Diettrich
>>> Die LCL nutz UTF8 per AnsiString (also Unicode), die FCL und RTL
>>> weiterhin ANSI
>>> (http://wiki.lazarus.freepascal.org/LCL_Unicode_Support).
Wenn man dort nachliest, unter Migration To Unicode, da steht doch
explizit drin, da� alle Widgetsets (au�er dem alten gtk1) intern UTF-8
verwenden. Wer da noch Ansi Codepages statt UTF-8 verwendet, ist selbst
schuld.
>> AnsiToUTF8 implementiert sind, aber in Windows sind das sogar zwei
>> Konvertierungen,
>> einmal nach UTF-16 und danach wieder zur�ck nach Ansi mit der anderen
>> Ansi-Codepage. Und f�r die Anzeige in Windows muss dann nochmal nach
>> UTF-16 konvertiert werden.
>
> Wenn ich richtig recherchiert habe, und sich bei neueren
> Versionen (>fpc 2.2.3) nichts ge�ndert hat, auch da!
Klar, wer das so will, der kriegt das so :-(
Wer Ansi verwenden will, der kann bei Ansi bleiben. Wer Unicode
verwenden will, der soll UTF-8 nehmen. Wer sich nicht entscheiden kann,
der darf munter hin und her konvertieren, so viel er m�chte.
DoDi
Hans-Peter Diettrich
>> IMO hast Du da was falsch verstanden. UTF-8 steht im AnsiString drin
> und
>> wird in einem Rutsch nach WideString konvertiert. Wenn ein Programm
>> sowieso mit Unicode arbeitet, werden keine anderen Ansi-Codepages
> ben�tigt.
>
> Was habe ich in news:hbiear$k38$02$1...@news.t-online.com falsch
> recherchiert?
Sorry, mein Thunderbird kann mit solchen Links nichts anfangen :-(
> In welcher Funktion geschieht die Konvertierung in einem Rutsch?
> (Ich denke, Du kannst bestimmt eine Datei/Unit/Include nennen)
Die WinAPI Funktionen (MultiByteToWideChar...) k�nnen das von Haus aus.
DoDi
Hans-Peter Diettrich
> Und weil ich es noch ganz genauer wissen wollte ;-)
> Okay... es lag daran das ich es zuvor nicht geschafft hatte
> RDTSC unter FPC zu implementieren,... jetzt geht es...
> ....habe ich nun den Test wie folgt unter FPC wiederholt:
...
> Und komme auf Rund 5500 CPU-Takte.
> Das sind sogar 500 mehr als in der Delphi5-Version!
> Sind glatte 10% nochmal oben drauf... fast wie Sonderangebot ;-)
Was mich viel mehr interessiert: wozu brauchst Du so eine Konvertierung?
Und wie lange dauert eine einfache Ansi/WideChar Konvertierung, unter
Delphi bzw. Lazarus?
IMO sitzt das Problem wieder einmal *vor* dem Bildschirm.
DoDi