Welche Konsequenzen zieht ihr aus den Features für XE2?

[stahli]

[OT]Jetzt macht auch Dein NickName Sinn. [/OT]

[Florian Hämmerle]

Zitat von stahli:

[OT]Jetzt macht auch Dein NickName Sinn. [/OT]

[OT]Ich hab schon anderes vermutet. Jetzt bin ich ja grad beruhigt [/OT]

[QuickAndDirty]

Zitat von stahli:

[OT]Jetzt macht auch Dein NickName Sinn. [/OT]

^^
Ich dachte das wäre von vorneherrein klar! Mein highlight...object-adressen-strings+Objekte eben in einer THashedStringlist speichern...

HashedStringlist.addObject(inttostr(integer(meinOb jekt)),meinObjekt);
Mit sowas sollte eine Garbage Collection umgehen können!!! *verrückt kicher*

[bernerbaer]

Zurück zur Ausgangsfrage:
_ich_ habe etwas Angst vor der "Überladenheit" von XE2. Mir persönlich hätte ein 64Bit Compiler gereicht, dafür das ausgereift und dazu alte seit Jahren mitgeschleifte Bugs endlich beheben. Besteht jetzt nicht die Gefahr, dass zwar alles integriert ist, aber auch hunderte von neuen Bugs auftauchen werden? Was ich von Firemonkey zu halten habe, werde ich erst wissen, wenn ich es mal gesehen habe, doch als reiner Windowsentwickler, der sich (leider) nur mit dem Windows API auskennt, denke ich, dass ich mich kaum mehr vertieft in neue Betriebssysteme einarbeiten werde bzw kann. So schnell schnell ein bestehendes oder neues Projekt für ein anderes OS zu kompilieren, vermute ich, wird so oder so nicht funktionieren und ich befürchte, dass sich da viele falsche Hoffnungen machen und dann frustriert das Handtuch werfen werden bezüglich Firemonkey. Ein Code mehrere OS das funktioniert m.E nur für die wenigsten Projekte. Nun ich lasse mich gerne überraschen von XE2 und wenn es denn erhältlich ist, werde ich mich natürlich auch mit Firemonkey mal auseinandersetzen.

[EarlyBird]

Ein Statement von devexpress.
Interessant für für Devexpress VCL USER

[himitsu]

Zitat von stahli:

Es wäre m.E. schön, wenn der Compiler dies automatisch für alle Objekte regeln würde (zumindest für Objekte der eigenen Application) und neben Property-Pointern auch für Variablen.

Gibt es doch schon?
Interfaces

Außer wenn jemand deren Zeiger schmutzig herumcastet, aber dafür gibt es ja die Möglichkeit die Referenzzählung manuell anzupassen.

[Bernhard Geyer]

Zitat von himitsu:

Zitat von stahli:

Es wäre m.E. schön, wenn der Compiler dies automatisch für alle Objekte regeln würde (zumindest für Objekte der eigenen Application) und neben Property-Pointern auch für Variablen.

Gibt es doch schon?
Interfaces

Interfaces wie sie Delphi implementiert haben Schwachstellen die bei einem System mit GC nicht auftreten. Du wirst auch schon in die Falle getreten sein in dem du noch ein Nicht-Interface-Referenz gehalten hast und die automatische Refernzzählung die die instanz hinterm rücken zerstört hat. Oder mal versucht GUI-Controls per Interfaces zu Verwaltung wo dann die Parent-Freigabe zur freigabe des Childs geführt hat - trotz noch gültigem Interface-Zeiger.

[mquadrat]

Das FireMonkey Statement von DevExpress ist interessant. Entweder alle Komponentenhersteller halten sich wie DevExpress zurück, oder wir erleben das Rennen um das erste FireMonkey Grid Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

[Bernhard Geyer]

Zitat von mquadrat:

Das FireMonkey Statement von DevExpress ist interessant. Entweder alle Komponentenhersteller halten sich wie DevExpress zurück, oder wir erleben das Rennen um das erste FireMonkey Grid Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

Das sie sich zurückhalten sehe ich nicht als Problem. Vermutlich werden sie ähnlch wie andere Hersteller (LMD) schön fleißig für VCL.NET und CLX Portierung vorgenommen haben um dann wenn sie fertig waren festzustellen das diese Libraries wieder eingestellt wurden - Was hätte man mit dieser vergeudeten Entwicklerzeit alles machen können. Deshalb will man erstmal sehen wie das wirklich aufgenommen wird.

[mquadrat]

Jep, so hat es DevExpress ja auch geschrieben. Das Problem ist nur das ohne sinnvolles Grid FireMonkey zum Scheitern verurteilt ist. Es muss ja nicht dermaßen überfrachtet sein, wie manche der Third-Party-Grids, aber mehr als das VCL StringGrid braucht es schon.

Wenn also alle so wie DevExpress reagieren haben wir die Situation, dass keiner FireMonkey einsetzt, weil ein Grid fehlt und es kein Grid gibt weil keiner FireMonkey benutzt

Aber warten wir erstmal ab, bis wir die ersten FireMonkey Programme am laufen haben