Das with-Statement in XE4

[Codehunter]

Ich zitiere jetzt mal aus dem inzwischen geschlossenen Thread:

Zitat:

Zitat von Insider2004 (Beitrag 1212275)

Ausserdem ist das with-Statement auch nicht mehr gerne gesehen.

Wie bitte? Was soll denn dann verwendet werden? Alles wieder lang ausschreiben? Na schönen Schrank auch! Wenn ich mir z.B. die TMS-Komponenten anschaue... Gigantische TPersistent-Kaskaden. Soll so die Zukunft aussehen:

Delphi-Quellcode:

FormComponent.Property1.SubProperty2.SubProperty3.BoolValue:= xyz;
FormComponent.Property1.SubProperty2.SubProperty3.IntValue:= 123;
FormComponent.Property1.SubProperty2.SubProperty3.StringValue:= 'xyz';

Statt so:

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 do 
begin
  BoolValue:= xyz;
  IntValue:= 123;
  StringValue:= 'xyz';
end;

Oder

Delphi-Quellcode:

var
  fFForm: TForm;
begin
  fForm:= TForm.Create;
  try
    fForm.AnyThing:= Foo;
    fForm.OtherThing:= Bar;
  finally
   fForm.Free;
  end;
end;

Statt

Delphi-Quellcode:

with TForm.Create do try
  AnyThing:= Foo;
  OtherThing:= Bar;
finally
  Free;
end;

WTF?

[uligerhardt]

Ich sag mal: mit einer Variablen, wie in deinem zweiten Beispiel. Das erste finde ich, gelinde gesagt, sch*****. :mrgreen:
Und wirklich überraschend kommt der Move ja auch nicht.

[Phoenix]

Nein, das erwartet keiner.
Das Problem mit with ist, dass es Scopes verschleiert.

Was ist, wenn Du in einem With-Block, den Wert von Tag des aktuellen Forms auf Sub-Controls schreiben willst? Bam-Scope-Konflikt.

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 do 
begin
  BoolValue:= self.BoolValue;
  IntValue:= self.IntValue;
  StringValue:= self.StringValue;
end;

// wird dann zu
var myObject: TypeOfSubProperty3;

//...

myObject := FormComponent.Property1.SubProperty2.SubProperty3;
myObject.BoolValue:= BoolValue;
myObject.IntValue:= IntValue;
myObject.StringValue:= StringValue;

Letzlich sparst Du Dir damit sogar noch eine Zeile ;-)

[DeddyH]

Eben. Eine kleine Variable erspart die Tipparbeit, und übersichtlicher als with ist es auch noch.

Delphi-Quellcode:

var
  MyRecord: TSomeRecord;
begin
  MyRecord := SomeClass.SomeListClass[0].SomeSubClass.RecordProp;
  MyRecord.SomeInt := 42;
  MyRecord.SomeString := 'Wuppdi';

[edit] 2 L8 :( [/edit]

[Bernhard Geyer]

Zitat:

Zitat von DeddyH (Beitrag 1212293)

Eben. Eine kleine Variable erspart die Tipparbeit, und übersichtlicher als with ist es auch noch.

:thumb:


Und der Scope-Konflikt hat uns schon einige Tage Fehlersuche gekostet :wall:
Mittlerweile bauen wir es überall aus wenn wir eh was an der entsprechenden stelle ändern müssen.

[dataspider]

Und einen Ausdruck anzeigen im Debugger wird dann auch zur Freude...

Frank

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212295)

Und der Scope-Konflikt hat uns schon einige Tage Fehlersuche gekostet :wall:

Vor allen Dingen, wenn das durch Einführungen eines properties Width in TRect mal eben so mit einem Delphi-Update rein rutscht und Code, der vorher problemlos lief, plötzlich nur noch Müll produziert.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1212298)

Vor allen Dingen, wenn das durch Einführungen eines properties Width in TRect mal eben so mit einem Delphi-Update rein rutscht und Code, der vorher problemlos lief, plötzlich nur noch Müll produziert.

Genau. Hier liegt der Fehler an der Sprachdefinition. Hätte man es wie bei VB gemacht mit einem Punkt davor wäre alles klar gewesen.

[Mavarik]

Ohne with ist voll daneben...

Besonders beim Zugriff auf XML Dateien über ein Interface...

Aktuelles Beispiel

Delphi-Quellcode:

GrundDaten.Verfahrensdaten.Beteiligung.Beteiligter.Organisation.Registereintragung.Items[0].Inlaendisches_Registergericht.Registergericht_Ort.Content := 'Bonn'

Ohne With kann man das nicht mehr lesen oder mit arbeiten...
Und jedesmal ne Variable vom entsprechenden Untertypen definieren?

Schlechte wahl...

Mavarik

[jaenicke]

Zudem gibt es immer wieder Probleme, weil Code nicht mehr kompilierbar ist. Ein Beispiel ist die Einführung von zusätzlichen Features in TRect. Dort gibt es ja nun Offset, was aber leider in der VirtualStringTree genau innerhalb eines with benutzt wurde. Und schon war nur deswegen der Code nicht mehr kompilierbar.

Andere Punkte wurden ja schon genannt, wie der dass ein einfaches Debuggen so gut wie unmöglich wird, da man für jede einzelne Auswertung einer Variablen diese komplett in den Auswerten-Dialog schreiben bzw. kopieren muss (zusammen mit dem Anteil in with).

Das Zwei-Augen Prinzip beim Einchecken wird auch zur Farce, weil dabei niemand den Überblick wahren kann, wenn überall with steht. Da bleibt daher immer ein Unsicherheitsfaktor.
Welche Eigenschaften wo existieren, kann niemand immer auswendig wissen, zumal sich dies auch durch neue Features in der RTL ändert.

Davon abgesehen macht with in meinen Augen auch keinen Sinn. Der einzige "Vorteil" ist, dass man vielleicht etwas weniger tippen muss. Aber als Entwickler darf man ja nun wirklich nicht tippfaul sein, viel tippen gehört schließlich dazu...:shock:
Der riesige Zeit- und damit Kostenaufwand, der dann aber folgt, weil der Code schlechter zu warten ist, ist damit jedenfalls gar nicht vergleichbar. Ein Musterbeispiel für eine Milchmädchenrechnung.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212295)

Mittlerweile bauen wir es überall aus wenn wir eh was an der entsprechenden stelle ändern müssen.

Wir auch...

Ich selbst habe es auch nie wirklich viel benutzt. Gut, am Anfang als ich noch nicht beruflich entwickelt habe, da habe ich über die Folgen nicht so sehr nachgedacht und es kam schon mal in meinen Quelltexten vor, aber nur selten.

Zitat:

Zitat von Mavarik (Beitrag 1212301)

Und jedesmal ne Variable vom entsprechenden Untertypen definieren?

Das ist allemal besser als with.

[Codehunter]

Mal ganz davon abgesehen, dass mir das so ziemlich auf den Zünder geht (persönliche Meinung) dürfte das dazu führen dass viele Drittanbieter-Komponenten ziemlich lange brauchen werden bis sie für XE5 (oder wo auch immer with dann rausfliegt) verfügbar sind.

Am Rande bemerkt, ich habe in 16 Jahren Delphi-Coderei keinen Scope-Konflikt erlebt der mich Tage der Sucherei gekostet hätte. Vielleicht liegts ja auch an meinem Programmierstil oder wie ich die IDE bediene, was weiß ich.

Jedenfalls käme ich aus heutiger Sicht kaum ohne with-Statement aus. Andererseits, wenn ich meinen 7-Jahre-Migrationszyklus in Betracht ziehe und das "with-CutOff" in 3 Jahren kommt, träfe es mich erst in 10 Jahren. Vielleicht habe ich bis dahin meine betreffenden Synapsen neu vernetzt ^^

Oder ich geh in Rente...

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1212303)

Am Rande bemerkt, ich habe in 16 Jahren Delphi-Coderei keinen Scope-Konflikt erlebt der mich Tage der Sucherei gekostet hätte.

Ich habe ja nicht gesagt das es ein einzelnes With-Statment war.
Bei mittlerweile über 1,5 Mio. Quellcodezeilen und einigen Bibliotheken die man selbst portieren musste (u. a. weil die Entwicklung eingestellt wurde ist man schon auf einge with-Fallen gestoßen die Teilweise sich gut in der SW-Versteckt hatten und man an ganz anderer Stelle zuerst gesucht hatte.

[uligerhardt]

BTW: Tool to refactor “with” blocks
Soweit ich mich erinnere, hat das Castalia-"Eliminate with" aber nicht sooo toll funktioniert. Es wundert mich, dass das weder bei Delphi selbst noch bei Modelmaker dabei ist.

[Mavarik]

Zitat:

Zitat von Codehunter (Beitrag 1212303)

Andererseits, wenn ich meinen 7-Jahre-Migrationszyklus in Betracht ziehe und das "with-CutOff" in 3 Jahren kommt, träfe es mich erst in 10 Jahren. Vielleicht habe ich bis dahin meine betreffenden Synapsen neu vernetzt ^^

Oder ich geh in Rente...

Ich stimme Dir zu 100% zu...

"7-Jahre-Migrationszyklus" klingt nach "ich arbeite auch noch mit D2007 wegen Unicode Umstellung".. :oops:

Ich möchte wissen wieviel prozent der Entwickler immer noch mit D2007 arbeiten, weil die "alten" Projekte zu groß sind um diese auf Unicode um zu stellen... (Aber das ist ein anderer Thread)

Ich möchte mal behaupten ich hatte NOCH NIE einen Fehler der aus einen With resultierte...

Liegt vielleicht daran, das ich With nicht in der 1. Ebene benutze... Beispiel:

Delphi-Quellcode:

MyClass.Subclass.Coole.Text := 'Bla'

Dann schreibe ich

Delphi-Quellcode:

With MyClass.Subclass do
  Cool.Text := 'Bla'

und nicht

Delphi-Quellcode:

With MyClass.Subclass.Cool do
  Text := 'Bla'

So läßt sich das auch nachher immernoch super lesen...

Mavarik

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1212307)

So läßt sich das auch nachher immernoch super lesen...

Super finde ich nicht, aber lesbarer ist es, das stimmt. Debuggen lässt es sich trotzdem nicht sinnvoll bzw. nur mit unnötigem Zeitaufwand.

Zitat:

Zitat von Codehunter (Beitrag 1212303)

Mal ganz davon abgesehen, dass mir das so ziemlich auf den Zünder geht (persönliche Meinung) dürfte das dazu führen dass viele Drittanbieter-Komponenten ziemlich lange brauchen werden bis sie für XE5 (oder wo auch immer with dann rausfliegt) verfügbar sind.

Dass with immer wieder Probleme macht, ist ja nun nichts Neues. Es wird aber (leider) trotzdem nicht aus der Sprache rausfliegen, sondern wird nur in der RTL nicht mehr benutzt. Ob andere da mitziehen, ist eine andere Sache.

Das Debuggen geht deshalb heute mit XE3 auch sehr viel schneller, weil ich nicht ständig Ausdrücke in Strg + F7 auswerten muss, wenn ich in den Delphiquelltexten debugge, sondern einfach die Maus drüberhalten kann. Das hat mich die ganzen Jahre schon genervt...

[dataspider]

Zitat:

Zitat von uligerhardt (Beitrag 1212306)

Es wundert mich, dass das weder bei Delphi selbst noch bei Modelmaker dabei ist.

Modelmaker zeigt es aber in den Live Metrics an und bietet auch einen brauchbaren Dialog zum Konvertieren...

Frank

[Elvis]

Zitat:

Zitat von Mavarik (Beitrag 1212307)

Ich möchte mal behaupten ich hatte NOCH NIE einen Fehler der aus einen With resultierte...

Ich überhole immer links...
Habe mir nie die Hände gewaschen, bevor ich die Kontaktlinsen wechsel'...
... ist mir noch nie was bei aufgefallen. Also KANN da ja garnix schiefgehen.
Wirklich geile Logik und auch sehr professionell, wirklich. :thumb:

Es gibt Sachen, die kann man persönlichem Geschmack überlassen, selbst beim Programmieren. Zum Beispiel bescheuerte Naming-Conventions, die Studien schon vor Jahrzehnten als sinnlos bis hinderlich überführt haben.
Sind bescheuert: ja. Lassen sich nur entziffern, aber nicht lesen: ja.
Aber sie schaffen keine wirklich fiesen Scoping Issues, da der Code selbst ja nur bescheuert aussieht, aber nicht per-se falsch ist.

Manche Sachen sind aber objektiv schlechter als mind. eine ihrer Alternativen. Dann ist es falsch belehrungsresistent weiterhin darauf zu bestehen, dass linksüberholen sicher ist.

"With" war mal im alten TP eine Optimierung im Umgang mit Records. d.h. Obwohl es sprachl. Mist war und eigentlich hätte gemieden werden müssen, gab es damals einen Grund das zu nutzen. (Weil es es einen vllt. messbaren Geschwindigkeitsvorteil brachte)
Heute gibt es das nicht. Es ist ein Feature, das schlimmer als Goto ist. Denn Goto kann nicht plötzlich die Beudeutung deines Codes ändern, wenn du eine neue Version einer Library nutzt.
Dein "super lesbares" Beispiel ist auch ganz toll geeignet um "With"s Problem aufzuzeigen:
Die Library, die "Cool" deklariert, bekommt ein Update und "Text" heißt jetzt "Title".
Jetzt änderst du "Text" aus dem nächsthöheren Scope. Super :thumb:

Zitat:

So läßt sich das auch nachher immernoch super lesen...

Lässt sich mit einer Variablen nicht schlechter lesen, wahrscheinlich sogar besser. Denn diese Variable kann deinen wirklichen use-case besser abbilden als es die Property könnte, welche ja nicht für genau diese Verwendung deklariert wurde.

[Uwe Raabe]

Zitat:

Zitat von dataspider (Beitrag 1212311)

Modelmaker zeigt es aber in den Live Metrics an und bietet auch einen brauchbaren Dialog zum Konvertieren...

... der auf Wunsch sogar eine passende lokale Variable anlegt. Beim Konvertieren muss man halt genau wissen, an welchen Stellen denn nun das Präfix hin muss und wo nicht. Aber das entspricht ja eben genau der Kenntnis, welche Identifier zu dem with gehören, und die muss man ja eh haben, um den Code zu verstehen.

[uligerhardt]

Zitat:

Zitat von Uwe Raabe (Beitrag 1212313)

Beim Konvertieren muss man halt genau wissen, an welchen Stellen denn nun das Präfix hin muss und wo nicht. Aber das entspricht ja eben genau der Kenntnis, welche Identifier zu dem with gehören, und die muss man ja eh haben, um den Code zu verstehen.

Die Kenntnis hat doch der Compiler/Parser - das ist doch der Sinn eines solchen with-Entfernungstools. Oder versteh ich dich jetzt falsch?

[sx2008]

So hätte man das With-Statement auch gestalten und die Unsicherheiten beim Scope vermeiden können:

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 as x do
begin
  x.BoolValue:= xyz;
  x.IntValue:= 123;
  x.StringValue:= 'xyz';
end;

Und als verschärfte Variante:

Delphi-Quellcode:

with FormComponent.Property1.SubProperty2.SubProperty3 as x, Gameboard.Player[1] as y do
begin
  x.BoolValue:= y.Active;
  x.IntValue:= y.Score;
  x.StringValue:= y.Name;
end;

[Elvis]

Zitat:

Zitat von uligerhardt (Beitrag 1212314)

Die Kenntnis hat doch der Compiler/Parser - das ist doch der Sinn eines solchen with-Entfernungstools. Oder versteh ich dich jetzt falsch?

Ich schreibe selbst statische Code-Analysen für dyn. Sprachen. Und "with" gehört lustigerweise fast in diese Kategorie, auch wenn Delphi (bis auf OleVariant) statisch typisiert ist.
Man müsste alle Bezeichner innerhalb des with-Statements auflösen. Also den nächstmöglichen Scope finden, aus dem sie kommen können.
Das ist aber fehleranfälliger als man es erwartet. Gerade in Delphi, wo man als Tool nie weiß, ob man jetzt die Saucen nehmen kann, oder die .DCU hernehmen muss.

[jaenicke]

Zitat:

Zitat von uligerhardt (Beitrag 1212314)

Die Kenntnis hat doch der Compiler/Parser - das ist doch der Sinn eines solchen with-Entfernungstools. Oder versteh ich dich jetzt falsch?

Der Parser kann diese Kenntnis nicht haben bzw. müsste einen riesigen Aufwand betreiben (genau eines der Probleme von with), das kann nur der Compiler. Und deshalb könnte ein solches Tool diese Daten auch nur aus dem Compiler bekommen, aber der hat dafür ja keine Schnittstelle. ;-)

Zitat:

Zitat von sx2008 (Beitrag 1212315)

So hätte man das With-Statement auch gestalten und die Unsicherheiten beim Scope vermeiden können

Stimmt, aber Variablen werden in Delphi nun einmal vor dem begin deklariert und nicht irgendwo. Ob man das gut findet oder nicht, sei jedem selbst überlassen, ich persönlich finde es gut (auch wenn ich diese Art der Deklaration durchaus nett fände).

[Elvis]

Zitat:

Zitat von sx2008 (Beitrag 1212315)

So hätte man das With-Statement auch gestalten und die Unsicherheiten beim Scope vermeiden können:

In Oxygene sieht es so aus:

Delphi-Quellcode:

with x := SomeExpression() do
   x.DoSomething();

Man hat also nicht nur eine Variable, sondern diese existiert auch nur innerhalb des Blockes. :thumb:

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1212309)

Es wird aber (leider) trotzdem nicht aus der Sprache rausfliegen, sondern wird nur in der RTL nicht mehr benutzt. Ob andere da mitziehen, ist eine andere Sache.

Die Diskussion im Netz (die ich ehrlich zugegeben bisher überhaupt nicht wahrgenommen habe) scheint aber das Gegenteil anzudeuten.

Mag sein dass with allgemein nicht sehr beliebt ist. Aber das ist genauso eine persönliche Sicht der Dinge. Wenn es with nie gegeben hätte würde es mir wahrscheinlich gar nicht fehlen. So aber habe ich sogar in anderen Sprachen nach einem with-Äquivalent gesucht und enttäuschenderweise keins gefunden (z.B. PHP). Jetzt dürft ihr frohlocken... Zum Glück! Egal, es soll keine philosophische Diskussion werden.

Zitat:

Zitat von jaenicke

Das Debuggen geht deshalb heute mit XE3 auch sehr viel schneller, weil ich nicht ständig Ausdrücke in Strg + F7 auswerten muss, wenn ich in den Delphiquelltexten debugge, sondern einfach die Maus drüberhalten kann. Das hat mich die ganzen Jahre schon genervt...

Dafür vergeudet man die so gewonnene Zeit mit den anderen Unzulänglichkeiten der IDE. Ich denke da nur an die reine Startzeit der IDE und den sich immer wieder aufklappenden Strukturbaum ohne jegliche Such- oder Organisationsfunktionen.

Ok, um wieder auf das Thema zurück zu kommen: Angenommen, with ist tatsächlich so unschön wie ihr es beschreibt und ich hatte es bisher bloß nicht als Problem wahrgenommen. Ganz ehrlich: Der Compiler (egal ob das alte D7 oder das neuere XE2) geben Hinweise und Warnungen en masse aus für jeden erdenklichen Firlefanz. Variablen, die deklariert und nicht verwendet werden z.B. Aber wenn with tatsächlich solche Scope-Probleme impliziert, warum gabs dafür bisher keine Hinweise?

Ich meine, dann braucht sich wirklich niemand wundern, dass so eine Kreuzung aus Gewohnheitstier und Betonschädel wie ich sich dann aufregt ^^

@sx2008: Dein Vorschlag zur Erweiterung der with-Syntax finde ich exzellent! x und y könnten sogar untypisierte Ausdrücke sein, der Compiler wüßte durch das with-Statement auf was sie sich beziehen. Die Lösung wäre viel besser als das ersatzlose Streichen von with.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1212319)

Ich denke da nur an die reine Startzeit der IDE

So viel finde ich die 10 Sekunden nicht. Wie oft starte ich denn Delphi pro Tag? Das ist bei mir in der Regel eine niedrige einstellige Zahl.

Zitat:

Zitat von Codehunter (Beitrag 1212319)

und den sich immer wieder aufklappenden Strukturbaum ohne jegliche Such- oder Organisationsfunktionen.

Dafür gibt es ja die DDevExtensions. :wink:

Zitat:

Zitat von Codehunter (Beitrag 1212319)

Aber wenn with tatsächlich solche Scope-Probleme impliziert, warum gabs dafür bisher keine Hinweise?

Weil der Compiler die Probleme kaum erkennen geschweige denn genau identifizieren kann. Zudem würde es da bei den meisten Projekten mit with-Verwendung schlicht viel zu viele Meldungen geben und außerdem war with bis vor kurzem ja auch in den RTL-Quelltexten weit verbreitet.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1212319)

Ich denke da nur an die reine Startzeit der IDE und den sich immer wieder aufklappenden Strukturbaum ohne jegliche Such- oder Organisationsfunktionen.

Ist zwar jetzt OT, aber mein XE3 startet um einiges schneller als D7.

Zitat:

Zitat von Codehunter (Beitrag 1212319)

Der Compiler (egal ob das alte D7 oder das neuere XE2) geben Hinweise und Warnungen en masse aus für jeden erdenklichen Firlefanz. Variablen, die deklariert und nicht verwendet werden z.B. Aber wenn with tatsächlich solche Scope-Probleme impliziert, warum gabs dafür bisher keine Hinweise?

Für den Compiler ist es ja nichts besonderes, innerhalb eines anderen Scopes zu arbeiten. Du bekommst ja auch keine Warnung vom Compiler, wenn eine lokale Variable eine gleichnamige globale verdeckt.

Andererseits hat ein Tool wie der Pascal Analyzer extra einen Report für mehrdeutige Referenzen in with-Anweisungen (obwohl sie für den Compiler ja gar nicht mehrdeutig sind).

[bernau]

Zitat:

Zitat von Elvis (Beitrag 1212318)

In Oxygene sieht es so aus:

Delphi-Quellcode:

with x := SomeExpression() do
   x.DoSomething();

Man hat also nicht nur eine Variable, sondern diese existiert auch nur innerhalb des Blockes. :thumb:

Hä? Wo ist denn da der Vorteil? Kann ich doch direkt so schreiben:

Delphi-Quellcode:

x := SomeExpression();
x.DoSomething();

Übrigens: Bei mir fliegt "With" auch überall raus, wo ich es finde. Aber Emba sollte es nicht einfach so aus dem Compiler entfernen. Ein deprecated oder ein anderer Compilerhinweis würde erst mal genügen.

[jaenicke]

Der Vorteil ist, dass mit der Zeile die Variable nicht nur zugewiesen, sondern auch deklariert wird.

[bernau]

Ach so. Muss man in Oxygen nicht extra deklarieren? So so! Würde aber der Pascal-Syntax wiedersprechen, da alle Variablen eigendlich deklariert werden müssen. Oder?

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1212327)

Ach so. Muss man in Oxygen nicht extra deklarieren? So so! Würde aber der Pascal-Syntax wiedersprechen, da alle Variablen eigendlich deklariert werden müssen. Oder?

Eigentlich handelt es sich auch nicht um Variablen, sondern um benannte Scopes, die bei Delphi einfach (unbenannt) so daruntergejubelt und auch nirgends deklariert werden ;)

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1212322)

Ist zwar jetzt OT, aber mein XE3 startet um einiges schneller als D7.

Ich kann nur von XE2 reden. In der Blanko-Installation bei mir ohne Extensions 40 Sekunden. Mit CnPack usw. dann 55 Sekunden. Alles von HDD zu laden, kein Netzwerk und keine toten URNs dabei. Bis allein der Splashscreen erscheint dauerts bei mir 15 Sekunden. Ein leeres Projekt laden 7 Sekunden. Ein "dickes" Projekt laden dauert noch länger. Woher das kommt kann ich nicht sagen, ist ein Phenom X6 mit Win7-Leistungsindex 4,7 wobei der schlechteste Wert die Graka ist, HDD hat 5,9 und CPU als auch RAM jeweils 7,5.

[bernau]

Zitat:

Zitat von Sir Rufo (Beitrag 1212334)

Eigentlich

;-)

[Phoenix]

Zitat:

Zitat von Codehunter (Beitrag 1212339)

HDD hat 5,9

Ich würde ne SSD beantragen. Die paar Euro investition hast Du durch weniger Wartezeiten in spätestens nem Monat wieder rausgearbeitet.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1212339)

Zitat:

Zitat von Uwe Raabe (Beitrag 1212322)

Ist zwar jetzt OT, aber mein XE3 startet um einiges schneller als D7.

Ich kann nur von XE2 reden. In der Blanko-Installation bei mir ohne Extensions 40 Sekunden.

Das ist genau das Problem, da fehlt das IDEFixPack. Dass Delphi ohne langsam ist, ist klar.

Und eine SSD beschleunigt das ganze natürlich enorm, da hat Phoenix Recht, aber hier ist grad keine drin und es sind 10 Sekunden Startzeit.

[musicman56]

Zitat:

Zitat von jaenicke (Beitrag 1212345)

Und eine SSD beschleunigt das ganze natürlich enorm....

Die XE2-Startzeit mit nur dem OS und Programmen auf einer SSD, und den Projekten auf einer HDD, bei mir 7 Sekunden.

[jensw_2000]

With nutze ich auch häufig und gerne. Scope Probleme hatte ich ebenfalls noch nicht.

Ich hoffe nur, dass es in "XE5" (oder wann es auch immer soweit sein wird, dass with wegfällt und wir im x86/x64 Compiler 0-based Strings haben) einen ordentlichen, stabilen und zuverlässigen Project Migration Wizard im Delphi geben wird, der alle with Blöcke ersetzen kann, alle String Deklarationen anpasst und alle aufgerufenen Stringfunktionen "korrigiert".
Das ganze natürlich so, dass der Code mit IFDEFs optional auch noch abwärtskompatibel zu der Quell-Delphiversion bleibt.

Wenn ich mir vorstelle, dass ich demnächst meine 10 Jahre "Tipparbeit" wieder einmal auf den Kopf stellen darf um irgendeiner aufgezwungenen RTL Umstellung gerecht zu werden, dann ... :kotz: ... weis ich nicht, wie lange ich überhaupt noch neue Projekte mit Delphi beginnen werde ...

[Bernhard Geyer]

Zitat:

Zitat von jensw_2000 (Beitrag 1212353)

Das ganze natürlich so, dass der Code mit IFDEFs optional auch noch abwärtskompatibel zu der Quell-Delphiversion bleibt.

Abwärtskompatiblität wirds nicht geben. Aber die umbauarbeiten bezüglich Strings auf .net/java-"Kompatibilität" ist ja mit den entsprechenden String-Methoden möglich.

[jensw_2000]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212355)

Zitat:

Zitat von jensw_2000 (Beitrag 1212353)

Das ganze natürlich so, dass der Code mit IFDEFs optional auch noch abwärtskompatibel zu der Quell-Delphiversion bleibt.

Abwärtskompatiblität wirds nicht geben. Aber die umbauarbeiten bezüglich Strings auf .net/java-"Kompatibilität" ist ja mit den entsprechenden String-Methoden möglich.

Warum sollen IFDEFS nicht gehen?

Code:

IFDEF RTLVERSION < "XE.n.Version"
  i := pos('x',s);
  if i > 0 then ...
ELSE
  i := s.indexof('x');
  if i > -1 then ...
ENDIF

Am schönsten wäre es aber, wenn der String ein "1-based String" bleibt und für die zerobased Strings einfach ein neuer Typ mit eigenem Namen eingeführt wird. Der XE"n" Compiler könnte dann im Hintergrund die Strings in zerobased Strings verdrehen und "ZString" 1:1 als 0-basierten String verarbeiten. Dann eventuell noch ein Hinweis beim kompilieren "Variable S ist aus String deklariert. Ändern Sie die Deklaration in "S:ZString" um die interne Konvertierung zu umgehen...".

[Phoenix]

Äh.. wir entfernen und gerade mit Warp 4 von den With-Statements...

Und ja ich weiss, bei der Startup-Time hab ich mit dem SSD-Hinweis auch schon Offtopic geantwortet...

Wir sollten dennoch hier und jetzt weiter auf die With-Statements konzentrieren und für andere Themen dann neue Threads aufmachen.

[Bernhard Geyer]

Bezüglich 0-Based Strings ab XE4 gehts hier weiter