- Nachträglich durch die Entwickler-Ecke gelöscht -

wo ich noch mit delphi gearbeitet hatte habe ich mir ganz stark angewöhnt alle dll-sachen immer dynamisch zu laden, hatte sonst auch immer komische bugs.......

Hallo Frühlingsrolle,

könntest Du etwas mehr über die Umstände berichten?

Ich habe Deinen Code mit minimalen Änderungen (ein Int-Parameter für die Prozedur wo Du drei Punkte hattest)
sowohl in D6 als auch XE2 übersetzt bekommen, nicht einmal Warnungen kamen.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Hallo,

nach langem Rumgrübeln habe ich ich endlich verstanden dass Du nicht von Compilerfehlern sprichst, sondern von der Hintergrundübersetzung.

Ich verwende den Mist schon lange nicht mehr, da es immer und immer wieder zu Geisterfehlern kommt.

Es ist reine Zeitverschwendung sich damit abzugeben.
Alles was nicht vom Compiler an Fehlern, Warnungen oder Hinweisen ausgegeben wird ist nicht da.

Wenn man als Entwickler nicht lernt, Tage lang wegzuprogrammieren ohne irgendwelchen Hilfstöölchen Aufmerksamkeit zu schenken die einen zwischendurch mit blöden Meldungen aufmuntern, wird man es sicher nicht weit bringen.

Mach die Hintergrundübersetzung aus.
Glaub mir, das macht das Leben leichter und hilft Dir gleich von vornherein weniger Tippfehler zu machen.

- Nachträglich durch die Entwickler-Ecke gelöscht -

> nach langem Rumgrübeln habe ich ich endlich verstanden dass Du nicht von Compilerfehlern sprichst, sondern von der Hintergrundübersetzung.

Und ich dachte es sind sowohl diese als auch Compilerwarnungen gemeint gewesen. Wenn es nur die roten Kringel sind macht das alles Sinn.

Und zum Verdacht mit der Unit Windows - JA, dort ist die betr. Funktion ebenfalls deklariert. Daher wird bei deren Einbinden wohl die Fehlermarkierung aufgehoben.

Die Kringelung sollte man nur als Hinweis sehen, ich habe es öfters daß Code mal markiert wird, mal nicht, obwohl er unverändert bleibt.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Hallo Mandras,

den Ausdruck "Hintergrundübersetzung" habe ich noch nicht gehört. Klassisch ist es doch so:

Der Compiler macht aus der lesbaren Progrmmiersprache einen Maschinencode. Unbekannte Funktionen werden in einer Liste vermerkt.

Der Linker durchsucht die angegebenen Units nach den fehlenden Funktionen, packt den Code zu dem Programm dazu und füllt die Lücken im Maschinencode.

Eine DLL ist ähnlich einer Unit, der Header wird vom Compiler verarbeitet, aber der Linker fügt sie nur bei "statischen Laden" anm den Code an.

Wo findet da eine "Hintergrundübersetzung" statt.

Vielleicht hilt Deine Antwort bei meinem Problem, dass ich gelegentlich einen Unterschied zwischen dynamasch und statisch finde.

Vile Grüß GuaAck

GuaAck hat folgendes geschrieben :

Der Compiler macht aus der lesbaren Progrmmiersprache einen Maschinencode. Unbekannte Funktionen werden in einer Liste vermerkt. Der Linker durchsucht die angegebenen Units nach den fehlenden Funktionen, packt den Code zu dem Programm dazu und füllt die Lücken im Maschinencode.

In D7 gibt es noch keinen Mitdenker/Falschdenker inm Hintergrund. Daher wirst Du das wohl auch nicht kennen. Es hat jedenfalls nicht mit Compilieren und Linken zu tuen.
Ist eigentlich eine schöne Sache um schon beim Schreiben zu erkennen wenn man mal eine Variable falsch geschrieben hat.
Aber leider wird es nervig wenn die Projekte größer werden. Anstatt einfach Tippfehler anzuzeigen oder falsche Parameter bei einem Aufruf, wird über irgendwelche nicht gefundenen Klassen lamentiert die der Compiler beim "echten" übersetzen problemlos findet. Alles wird lahm und mit roten Linien zugepiselt. Also ist das Feature bei mir immer aus.

Das ganze nennt sich Error Insight. Das ist schon durchaus praktisch, wurde mit den Delphiversionen auch immer besser. Allerdings funktioniert es am besten in sauberen kleinen Units, die nicht so stark voneinander abhängig sind (Decoupling, Clean Code, ...).

In einem mittelgroßen Projekt mit ein paar Hunderttausend Zeilen Code werden bei uns zwar ein paar falsche Fehler angezeigt, aber bei weitem nicht so viele wie früher. Da die "falschen" Fehler meistens ähnlich aussehen, ignoriere ich die einfach. Trotzdem hilft Error Insight beim Tippen durchaus, wenn direkt angezeigt wird, wenn es da ein Problem gibt.

Warum sie es bis heute nicht geschafft haben, das fehlerfrei zu bekommen, ist mir aber auch ein Rätsel. Selbst Fremdhersteller schaffen das ja besser...

- Nachträglich durch die Entwickler-Ecke gelöscht -

Frühlingsrolle hat folgendes geschrieben :

Fremdhersteller wie die Leute von Lazarus?

Ich denke vor allem an ModelMakers Code Explorer. Da funktioniert das Refactoring anders als bei Delphi auch.

jaenicke hat folgendes geschrieben :

Frühlingsrolle hat folgendes geschrieben : Fremdhersteller wie die Leute von Lazarus? Ich denke vor allem an ModelMakers Code Explorer. Da funktioniert das Refactoring anders als bei Delphi auch.

// EDIT:
Und auch die Live-Codeanalyse:
modelmakertools.com/...mmx-live-metrics.htm

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ich konnte (im Gegensatz zu Error Insight) keinerlei solche Effekte feststellen, auch nicht bei größeren Projekten.

So nebenbei, wenn wir bei unterstützenden Tools sind:
Echt nett ist auch CodeInsightPlus (wenn man sich drauf einlässt und dran gewöhnt hat ).

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ohne Code Insight würde ich um Größenordnungen länger brauchen. Ich tippe zwar schnell, aber insbesondere die Möglichkeit durch Abkürzungen auch komplexe Begriffe zu ergänzen spart schon extrem viel Zeit.

Ja, Documentation Insight benutzen wir auch. Durch den integrierten visuellen Editor in der IDE sparen wie viel Zeit beim Erstellen der Dokumentation und es ist deutlich einfacher z.B. Links oder Bildinhalte oder andere Formatierungen hinzuzufügen. Natürlich könnte man die Tags auch alle manuell schreiben. Aber das dauert deutlich länger.
Und das ist bei weitem nicht so angenehm.