Na, schon Delphi XE gekauft?

[mkinzler]

Zitat von mleyen:

Zitat von mkinzler:

Was bedeutet, dass nicht die wenigen Programme, die von einer festen Breite ausgehen angepasst werden müssen, sondern allen anderen, welche auch ohne Anpassung funktionieren würden!!

Die machen´s doch gerade weil man weder Integer auf LongInt, noch Integer auf BigSuperGr8Int anpassen muss.

Die Natur von generischen Tpen ist, dass diese automatisch den apssenden Tap haben. Bei Integertypen den der Plattform. Integer in einem 16Bit OS war 16Bit, bei einem 32Bit OS 32Bit. Jetzt würde ich7man erwarten, das der bei einem 64Bit OS 64Bit hat; wäre dann aber nicht mehr so, da Integer jetzt ein weiterer Alias von LonInt wäre. Will man, wie meisst gewünscht immer die Standradbreite haben, muss man dann Integer durch Int64 oder einem neuen generischen Typ (NativeInt) ersetzen.

[Robotiker]

Zitat von mkinzler:

Integer in einem 16Bit OS war 16Bit, bei einem 32Bit OS 32Bit. Jetzt würde ich7man erwarten, das der bei einem 64Bit OS 64Bit hat;

Es ist leider noch etwas komplizierter, da das bei 64-Bit nicht mehr einheitlich ist:

http://en.wikipedia.org/wiki/64-bit#...ge_data_models

[Win32.API]

So, habe die Trial jetzt auch mal 2 Stunden getestete. Die IDE musste ich in dieser Zeit _3_ mal Neustarten!

1. Es gab einen Crash, gefolgt von dem Windows Dialog: "Delphi funktioniert nicht mehr...".
2. Das zweite mal konnte ich in Editor keine Tasten mehr drücken. Neuladen des Projekts brachte nix.
3. Und gerade eben habe ich einen reproduzierbaren Bug gefunden, der Delphi soviel Speicher allozieren lässt, dass Delhi erst abbricht, wenn eine OutOfMemory-Exception geworfen werden müsste. Diese Exception wird von Delphi einfach geschluckt.

Super Arbeit!

Desweiteren sind von AQ-Time und CodeSite nur abgespeckte Versionen enthalten, die wesentliche Features nicht mitbringen.

Alles in allem also keine Kaufempfehlung. Zumal gibt es für Student/Hobby-Entwickler keine Versionen - Schade Delphi, die Jahre mit Dir waren trotzdem was feines.

[MEissing]

Zitat von Win32.API:

So, habe die Trial jetzt auch mal 2 Stunden getestete. Die IDE musste ich in dieser Zeit _3_ mal Neustarten!

1. Es gab einen Crash, gefolgt von dem Windows Dialog: "Delphi funktioniert nicht mehr...".
2. Das zweite mal konnte ich in Editor keine Tasten mehr drücken. Neuladen des Projekts brachte nix.
3. Und gerade eben habe ich einen reproduzierbaren Bug gefunden, der Delphi soviel Speicher allozieren lässt, dass Delhi erst abbricht, wenn eine OutOfMemory-Exception geworfen werden müsste. Diese Exception wird von Delphi einfach geschluckt.

Ich hab hier Delphi XE schon seit gut 3 Monaten auf dem Rechner. Kein Absturz. Nichts. Völlig problemlos.

Was soll uns das jetzt sagen: Nichts. Rein gar nichts.

(Könntest du wenigstens *ansatzweise* beschreiben WAS und WIE du zu den Fehlern kommst (...grummel, grummel... "reproduzierbar"... grummel... grummel)

[blackfin]

Zitat:

Das zweite mal konnte ich in Editor keine Tasten mehr drücken. Neuladen des Projekts brachte nix.

Das hatte ich jetzt auch schon einmal. Kann es sein, dass es teilweise daran liegt, wenn man irgendwie "zu oft" zwischen Code und Formular umschaltet?
Achja: System: Win7 x64 Ultimate.

Mal sehen, wenns nochmal auftritt, weiss ich vielleicht mehr, was genau die Schritte davor waren.

[Win32.API]

Das Problem trat auf, als ich ein größeres Projekt mit XE kompilieren wollte. Ich konnte es aber auf folgendes reduzieren: a<(

Diese drei magischen Zeichen veranlassen Delphi dazu in einer schleife soviel Speicher zu allozieren, dass es knallt.


Edith meinte gerade noch, dass hier auch nen W7 x64 werkelt.

[MEissing]

Zitat von Win32.API:

Das Problem trat auf, als ich ein größeres Projekt mit XE kompilieren wollte. Ich konnte es aber auf folgendes reduzieren: a<(
Diese drei magischen Zeichen veranlassen Delphi dazu in einer schleife soviel Speicher zu allozieren, dass es knallt.

Du sprichst in Rätseln...

[mkinzler]

Zitat:

Warum muss eigentlich ein Typ geändert werden bei demselben Namen ?

Weil string von Anfang an ein generischer Typ war. D.H. man kann sich nicht auf dessen Implementierung verlassen

[Win32.API]

Zitat von MEissing:

Zitat von Win32.API:

Das Problem trat auf, als ich ein größeres Projekt mit XE kompilieren wollte. Ich konnte es aber auf folgendes reduzieren: a<(
Diese drei magischen Zeichen veranlassen Delphi dazu in einer schleife soviel Speicher zu allozieren, dass es knallt.

Du sprichst in Rätseln...

Einfach a<( in die IDE tippen/kopieren und im Taskmanager beobachten.

[himitsu]

Zitat von Robotiker:

Es ist leider noch etwas komplizierter, da das bei 64-Bit nicht mehr einheitlich ist:

Also hatte sich Windows am meisten und, abgesehn von dem eingefrohrenem INT, fast komplett an die früher mal getroffenen Konventionen gehalten.
Aber was interessiert uns Delphianer das, wo wie doch eh nur Win16/32 können.

Zitat:

Zumal gibt es für Student/Hobby-Entwickler keine Versionen

Da wurde etwas angekündigt, welches "kurz Zeit" nach dem XE-Release erscheinen soll, aber genaueres weiß man nicht.