Warum Delphi 64-Bit-IDE

[Sinspin]

Zitat:

Zitat von arnof (Beitrag 1463893)

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Ich war zum Schluss soweit dass ich alles an Komponenten raus gehauen habe was nur ging.

Das war für uns der Grund auf Rio umzusteigen. Aber wenn Du ein Projekt in der größe hast dass es mit XE2 Speicherprobleme gibt würde ich versuchen noch zu warten. Rio wirft zwar bisher keine Speicherfehler, aber dafür ist die IDE voller Bugs (MouseOver Hinweise: sporadisch; Autovervollständigung: sporadisch; Menüzeilen nach einer Größenänderung zerhagelt: jedesmal, ...), und der Compiler findet alle paar mal beim übersetzen Fehler die es nicht gibt. Und ErrorInsight ...nunja... wozu ist das eigentlich nochmal da? Zum abschalten!

Warum solche Fehler nicht in Revisionen der aktuellen Version behoben werden kann ich nicht verstehen. Aber es war bisher immer so das einige IDE Schrott waren und es geblieben sind. Dafür aber alle X Jahre mal eine stabile dabei war die man dann nutzen konnte.

Zur 64 Bit IDE. Das klingt schon verlockend. Ich habe eines meiner Projekte mit bestehenden Sourcen in 64Bit umgesetzt und muss sagen, das es schon eine ganze Weile gedauert hat bis es nicht mehr geknallt hat.
Eine 64 Bit IDE würde dann voraussetzen dass alle Komponenten die Du verwendest auch 64 Bit können.
Ich habe noch immer gekaufte Komponenten dabei die kein 64 Bit können. So lange das noch so ist würde auch eine 64 Bit IDE keinen Sinn machen.

Interessanter ist da eher den Compiler als 64 Bit auszulegen und in einem eigenen Prozess laufen zu lassen.

€dit: CodeInsight war falsch, ErrorInsight war gemeint. Und letzteres ist das Böse. Das andere funktioniert nur zu oft nicht.

[DasWolf]

Zitat:

Zitat von DieDolly (Beitrag 1463901)

Ich muss die IDE zwar mehrmals täglich wegen irgendwelcher unbehandelten Fehler, von denen es viele gibt, neustarten. Aber an Speicherlimits bin ich bisher nie gekommen.

Na dann provoziere mal zirkuläre Unit-Referenzen. Das legt nicht nur die IDE lahm, sondern auch gleich den ganzen Rechner.

[DieDolly]

Zitat:

Na dann provoziere mal zirkuläre Unit-Referenzen.

Bei mir weder noch. Es kommt eine nichtssagende Fehlermeldung im unteren Ausgabebereich und der Kompiliervorgang wird normal abgebrochen.

[Uwe Raabe]

Zitat:

Zitat von DasWolf (Beitrag 1463911)

Na dann provoziere mal zirkuläre Unit-Referenzen.

Umgekehrt: Die Empfehlung ist zirkuläre Unit-Referenzen zu eliminieren! Ohne lebt es sich gleich viel besser.

[himitsu]

Darum auch möglichst alle Uses nur im Interface und bei den Uses in der Implementation gut überlegen, ob es so richtig und nötig ist.

Zitat:

Und CodeInsight ...nunja... wozu ist das eigentlich nochmal da?

Sicher dass du dass Code-Insight meinst und nicht vielleicht doch das Error-Insight?

Error-Insight = Fehlerhervorhebung (das nie funktionierende Untersteichen usw.)
Code-Insight = Codevervollständigung und Hints mit den Infos (Unit der Delkarations und die Parameter)
Help-Insight = die Hints mit dem Hilfetext
andere-Insights = ...

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1463915)

Zitat:

Und CodeInsight ...nunja... wozu ist das eigentlich nochmal da?

Sicher dass du dass Code-Insight meinst und nicht vielleicht doch das Error-Insight?

Danke. :oops: Verbessert.

[freimatz]

Was habe ich da schcon wieder angeleiert? :oops:

Habe zwar alles gelesen, aber eine eine Antwort habe ich noch nicht. hoika hat zwar geantwortet (Danke), aber die Argumente sind hinfällig - oder? Es ging viel um Speicher und ein Update auf neueste Delphi-Version sollte da doch reichen.
Zumindest bei uns sind Speicherprobleme weg - und wir haben im Hauptprojekt 333 dproj (incl. 142 von Fremdkomponenten)

[Moombas]

Dann bringe ich mal ein anderes Argument, das wohl aber erst in der (?fernen?) Zukunft greifen wird:

Keine Unterstützung von 32-Bit Programmen mehr, so wie es bereits für 16-Bit passiert ist.

Und je eher man umstellt, umso eher kann man ggf. Baustellen schon umgehen und ist vorbereitet.

[win568]

Hi

Also wir würden dringendst eine 64 Bit IDE benötigen. Der Umfang unseres Projektes sprengt derzeit fast die IDE.
Laden des Projektes und einmal Compilieren und 4GB erreicht. Neustart, nochmal compilieren und es geht mal gerade so (3,7 GB virtueller Speicherverbrauch). Und ja, bevor jemand da zum Belehren anfängt, wir haben unser Projekt bereits in Packages
aufgeteilt (95 Stück an der Zahl). Leider ist hier die Unterstützung der IDE Funktionen (CodeInsight, ErrorInsight, CodeCompletion usw.) mehr als Mangelhaft, weshalb ich lieber noch mit dem Monolithen arbeite. Dort funktionieren die genannten Funktionen
interessanterweise.

[himitsu]

Zitat:

Zitat von win568 (Beitrag 1463922)

wir haben unser Projekt bereits in Packages aufgeteilt (95 Stück an der Zahl)

Jo, unmengen an Packages und DLLs, die nicht alle bei Programmstart geladen werden, sondern erst wenn benötigt,
aber die komplette Projektgruppe auf einmal kompilieren, naja ...

Zitat:

Zitat von himitsu (Beitrag 1463905)

Problem ist auch, dass der Inline-Compiler gern ein Speicherleck hat.
Nja, nicht direkt Leck ... beim gleichzeitigen beim Kompilieren mehrerer Projekte, wird der Cache erst am Ende geleert, was ihn vorher gern mal volllaufen lässt.