Ich programmiere seit ca. 30 Jahren. Ich kann die Stunden, die ich mit einem solchen Schei... verbracht hab schon gar nicht mehr zählen. Aber ich freue mich heute noch, wenn ich die Lösung finden konnte.zappa2 hat geschrieben:Unglaublich, wie viele Stunden ich an dem Problem gebastelt habe!!!
Nicht nur bei Delphi, das Problem kenne ich auch von MS-Studio. Ein Problem mit Datenbanken besteht dort seit über 10 Jahren, da tut sich nichts. Und der Workaround hat mich bei jeder neuen Version meines Programms Tage gekostet.af0815 hat geschrieben:... und da konntest du nicht mal was fixen, nur workarounds machen.
Andere Projekteinstellungen bedingen aber IMHO kein neu kompilieren von Lazarus. Das halte ich für ein Gerücht. Da musst du mir erklären was du da wirklich damit meinst.zappa2 hat geschrieben:Und ich denke, einige der Probleme in Lazarus sind hausgemacht: für einige Projekte benötige ich andere Projekteinstellungen, was ab und zu ein komplettes Neukompilieren von Lazarus zur Folge hat. Was da an Hinweisen und Warnungen(!!!) kommt, geht auf keine Kuhhaut! Für mich ist eine Warnung grundsätzlich ein Fehler und ein Hinweis kurz davor. Ich würde niemals auch nur eine Zeile Quellcode mit Warnungen ausliefern. Die Vermutung liegt nahe, dass einige der Fehler, mit denen wir uns herumschlagen nicht auftauchen würden, wenn diese ganzen Warnungen bereinigt würden.
Dort kostet jede neue Version so richtig Kohle und man kann ja nicht einmal nachsehen wieviele Fehler in den Biblitheken stecken, weil man darauf gar keinen Zugriff hat 
Für mich als einfachen 'Benutzer' von Lazarus sind diese Packages quasi Bestandteil von Lazarus, ich kann ohne sie nicht sinnvoll mit Lazarus arbeiten. Damit ändert die Unterscheidung zw. Lazarus selbst und eingebunden Packages/Komponenten nichts. Das betrifft ja wirklich essentielle Packages wie bspw. LazUtils, LCLBase, LCL. Die meisten Meldungen kommen vom Melander-Drag&Drop-Package, die habe ich hier mal rausgenommen, sind ja ThirdParty-Produkt.Daher muss man mal unterscheiden:
*) Kommt das Warning von FPC oder Lazarus.
*) Ist es ein Warning aus einer Komponente, die von Lazarus nur eingebunden ist.
Gebe ich Dir absolut Recht. Nur wie soll das aussehen? Die Warnungen und Hinweise sehen ja die betreffenden Entwickler selbst, das brauche ich denen nicht mitteilen.Auch wenn man das Firmenmässig verwendet ist es mehr als fair auch Firmenzeit zurück in das Projekt zu geben.
err.txtCode: Alles auswählen
var Counter: Integer;
...
begin
if DoDebugStuff then Counter := 0;
...
if DoDebugStuff then Inc(Counter);
...
if DoDebugStuff then WriteLn('Number of Iterations: ', Counter)Ja, der großteil ist ja Unused Parameter. Das ist halt bei event basierter Programmierung einfach der Fall das die aufkommen, und da kann man auch nix machen. Wenn man die Argumente von einem Event nicht braucht, braucht man sie einfach nicht. Soweit ich weiß kann man in Lazarus die aber mittlerweile (ich glaub nur projektweit, nicht global) unterdrücken lassen, bin mir aber nicht so sicher (Ich hab sie einfach akzeptieren gelerntzappa2 hat geschrieben:- Hints über unused vars oder units:
Geschenkt, droht keine unmittelbare Gefahr. Der Sauberkeit halber sollte doch aber der Entwickler, der als letzter an dieser Unit rumwerkelt das bereinigen. Denn wenn der Berg immer größer wird, den man vor sich herschiebt, wird keiner mehr die Zeit opfern, das in Ordnung zu bringen. 20 Meldungen => kostet ein paar Minuten, weg sind sie. 200 aber: das war ja nicht ich, soll wer anderes machen. Tendenz: Verschlimmerung.
)Grundsätzlich ja, aber Deprecation zu ersetzen ist nicht immer trivial. Ich hab mir die Codestellen nicht weiter angeschaut, aber ich habs schon selbst erlebt das die Funktion die genau das macht was man will deprecated ist, und es keine 1-zu-1 ersatz gibt, bzw. es echt kompliziert wird das selbe über andere Methoden zu erreichen. Eventuell warten die entwickler auch auf ein neues feature um das alte zu ersetzen (hatte ich schonmal in nem java projekt, wo wir n deprecated call nicht ersetzen konnten bis die nächste version von ner Lib draußen war die endlich die vernünftige alternative bildet). Da steckt man einfach nicht drin, und es sind immerhin nur 5 stück.zappa2 hat geschrieben:Depcrecatet finde ich einfach nur peinlich: 5 Stellen sind in 2 Minuten gefixed. So was sollte nicht vorkommen, darf nicht vorkommen. Meist steht sogar im Log, was man stattdessen nehmen sollte.
Solang man weiß was man tut ist alles in Ordnung. Problematisch wirds eher bei der Übersetzung auf andere Plattformen. x86 und x86_64 garantieren soweit ich weiß das das geht (was übrigens nicht trivial ist, 64 bit Betriebsysteme und Prozessoren arbeiten für gewöhnlich auf 48 bit pointern, das so schweinereien also überhaupt gehen ist mehr dem guten willen von Intel und Co zu verdanken statt der unterliegenden technik). Aber auf anderen architekturen sieht das direkt ganz anders aus. Auf ARM ist soweit ich weiß nicht jede Zahl ein gültiger Pointer, d.h. Pointer(x) und Pointer(x+1) kann den selben pointer ergeben (es ist also nicht möglich hin und her zu converten ohne informationen zu verlieren), und damit kann das programm von einem ganz schnell in die Hose gehen. Und grade weil ARM prozessoren mehr und mehr werden (Handies, Raspies, und in zukunft eventuell sogar desktops) Versuche ich mittlerweile sowas ganz und gar sein zu lassen, wer weiß ob ich in 5 jahren nicht eine meiner Anwendungen mal auf ARM porten möchtezappa2 hat geschrieben:Zum Signed/Unsigned: Das stimmt, da sollte man schon wissen was man tut. Ich vergewaltige übrigens auch hin und wieder gern negative Integer in Pointer, um sie als definierte Steuerungelemente z.B. TreeViews oder Grids als Object mitzugeben (z.B. negative sind IDs aus der einen Datenbanktabelle, positive aus einer anderen); funktioniert hervorragend. Und ich differenziere, wann ich PtrInt oder PtrUInt nehme - wie Du schon sagtest, man sollte schon wissen, was man wann nimmt.
Ja in der LCL (sowie auch der RTL und FCL) wird das normalerweise so gehandhabt das der ganze Plattform spezifische code in eigenen Include dateien hockt, die dann je nachdem eingebunden werden:zappa2 hat geschrieben:Wegen der Targetplatform-Abhängigkeiten: Es gibt doch die define/ifdef-Clauseln. Für systemnahe Packages halte ich die für Pflicht. Das machen doch selbst wir kleinen Anwendungsentwickler, wenn wir parallel für Linux/Unix und Windows entwickeln. Für Systemprogrammierer sollte das doch dann erst Recht Pflicht sein - oder?
Code: Alles auswählen
{$ifdef WINDOWS}
{$include ImplXYZWindows.inc}
{$else}
{$ifdef DARWIN}
{$include ImplXYZMacOS.inc}
{$else}
{$ifdef LINUX}
{$include ImplXYZLinux.inc}
{$endif}
{$endif}
{$endif}Man kann auch über Compiler Switches bestimmte Warnings oder Hints für einen Code abschnitt deaktivieren. Wenn man also weiß das ein No-Portable Hint auftreten soll, kann man theoretisch einfach sagen: Für die folgende Funktion ignoriere alle No-Portable Hints. Aber um ehrlich zu sein kann ich den Lazarusentwicklern nicht verübeln sich nicht den Aufwand zu machen, ich würds wahrscheinlich nicht besser machen (bzw. ich weiß das ichs in meinen projekten nicht besser mache)zappa2 hat geschrieben:Und ja: unkritische Hints, die der Entwickler wohlwissend in Kauf nimmt, weil er an dieser Stelle um ihre Nichtrelevanz weiß, könnte man ja einfach mal unterdrücken. Ein Rechtsklick mit der Maus und im Kontextmenü den Punkt 'Meldungen xyz unterdrücken' = Klick - fertig.
Auf jeden Fall. Vor allem wenn man sich ansieht was da auch in den Letzen jahren geschehen ist. Als ich damals zu Lazarus 0.9.28 angefangen hab (Ist mittlerweile 10 Jahre her) war Lazarus zwar schon benutzbar und für ne Open Source IDE recht solide, aber im vergleich was seit dem alles geschehen ist, ist Lazarus mittlerweile zu einer Echt Top IDE geworden. Wenn ich eine GUI anwendung schreiben will, gibts mMn. kaum vernünftige alternativen. Für C++ und QT darf man mindestens mit dem doppelten aufwand rechnen für das selbe ergebnis (und muss unter Windows noch die paar hundert MB QT Libs mitliefern), bei .Not darf man entweder seine Seele an Microsoft verkaufen (i.e. Visual Studio/Xamarin benutzen) oder mit MonoDevelop sich auf GTK festschießen und mit einer deutlich schlechteren IDE arbeiten, oder bei Java direkt auf seinen Formulareditor verzichten und alles über Code regeln.zappa2 hat geschrieben:Nochmal: die Jungs machen einen hervorragenden Job - das wird viel zu selten gewürdigt. Es sind nur diese kleinen Stolperstellen, die einen doch hin und wieder grübeln lassen.
Schnellere und unmittelbare Rückmeldung gibts matürlich auf der Maillingliste.Die Melander Suite habe ich damals aus purer Verzweiflung für Lazarus ge-forked.zappa2 hat geschrieben:Die meisten Meldungen kommen vom Melander-Drag&Drop-Package, die habe ich hier mal rausgenommen, sind ja ThirdParty-Produkt.
Verein
Links
Suche
