Na, schon Delphi XE gekauft?

[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

[Namenloser]

Warum ersetzt ihr nicht einfach per Search & Replace alle "Integer" durch "LongInt", wenn ihr geschlampt und generische an Stelle von fixen Typen verwendet habt? Wo ist das Problem?

Viel schwieriger haben es doch die, die ihren Code bereits darauf ausgelegt haben, dass Integer mitwächst (so wie es seit Jahren in der Hilfe steht): Denn wenn Integer jetzt NICHT mitwächst, müssen die ihren GESAMTEN Code ERNEUT durchforsten und schauen, wo ein mitwachsender Typ gebraucht wird und wo nicht.

Warum sollen jetzt die, die es richtig gemacht haben unter der Schlamperei der anderen leiden?

[Sherlock]

Zitat von 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

Den Teil hab ich wohl in der D5 Hilfe überlesen...und damals war die noch wirklich ausführlich.

Sherlock

[mkinzler]

Das ist seit D1 so.
Kurze Strings -> ShortString (alter Pascalstring)
Längere Strings -> AnsiString (klassischer Delphistring als Zeiger auf Speicherbereich)

[gammatester]

Zitat von mkinzler:

Das ist seit D1 so.
Kurze Strings -> ShortString (alter Pascalstring)
Längere Strings -> AnsiString (klassischer Delphistring als Zeiger auf Speicherbereich)

Ach ja? Wie deklarierst Du denn einen Ansistring bzw. ShortString in D1? Falls Dich nicht mehr erinnerst: D1 ist ein 16Bit Compiler!

[mkinzler]

Das mit dem String hat ja nichts mit 16/32Bit zu tun, sondern ob es der "alte" Pascalstring ist, bei dem an der ersten Stelle, die Länge stand und der deshalb nur maximal 255 Zeichen lamg sein konnte oder der in Delphi eingeführte "neue" String mit einer variablen Länge.

[himitsu]

@gammatester: OK, dann isses eben seit D2 so.

Zitat von Sherlock:

Den Teil hab ich wohl in der D5 Hilfe überlesen...und damals war die noch wirklich ausführlich.

Einige Auszüge aus der OH meines Delphi 4 ... nur damit keiner behaupten kann, er wußte von nichts.

Zitat von Reelle Typen:

Der generische Typ Real ist in der aktuellen Implementation mit dem Typ Double identisch.

Zitat von Integer-Typen:

Es gibt zwei generische Integer-Typen: Integer und Cardinal. Diese Typen sollten, wenn möglich, immer verwendet werden, da sie die optimale Ausführungsgeschwindigkeit für die zugrundeliegende CPU und das Betriebssystem gewährleisten

Zitat von String-Typen:

Das reservierte Wort string funktioniert wie ein generischer Typbezeichner.

Zitat von Hansa:

Was predigst Du ? Bzw. wo , wie was ? Ich sage jedenfalls : integer oder sonstwas hat 4 Byte. Basta. Auch unter Win128. Dann können sie ruhig kommen mit Bigint, SuperBigInt etc.

Zitat von himitsu:

Na das mit dem Integer und den sich "ändernden" Typen.

Zitat von himitsu:

Mavarik: Wenn deine Records (welche gespeichert oder übertragen werden) nur native Typen (LongInt statt Integer, LongWord statt Cardinal, Double statt Real und AnsiChar/WideChar statt Char) verwenden und auch noch "packed" sind, bzw. wenn eine bestimmte Ausrichtung explizit vorgegeben ist, dann gibt es keine Probleme, selbst wenn sich der Integer ändert oder nicht oder wenn nun Unicode verwendet wird.

Zitat von himitsu:

Innerhalb der Anwengung ist es nähmlich sehr gut, denn so würde mit dem Umstieg auf Unicode oder eben 64 Bit (falls sich der Integer doch noch ändert) automatisch umgestellt.

Wenn es aber darum geht Daten an andere Programme zu übergeben, wozu auch die Speicherung zählt, wenn sich zwischendurch mal die Struktur des Programmes ändern kann, bis dieses dann wieder ausgelesen wird,
dann sollte man eben nur fundamentale Typen verwenden, da diese gleich bleiben, auch wenn sich die Programmstruktur ändert.

.........

Die generischen (veränderlichen) Typen wurden mal eingeführt, da sie sich an das Betriebssystem, bzw an den Compiler für dieses System anpassen und dort die "optimalen" Typen nutzen, welche nativ vom System unterstützt werden.

In Unicodesystemen (eigentlich seit WinNT) ist die API nunmal nativ Unicode, also sind in einem Compiler dafür natürlich die Stantardtypen auch auf Unicode eingestellt.
> Char=WideChar PChar=PWideChar und String=(WideString)UnicodeString

Unter einem 16 Bit Windows ist der Integer halt 16 Bit, bei einem 32 Bit Windows eben 32 Bit und für ein 64-Bit-System wäre dieser nunmal 64 Bit. (entsprechend den Registergrößen der CPU)

Daß Delphi leider immer "etwas" hinterherhinkt, ist leider eine blöde Tatsache ... also weswegen sich leider alle so an die zu lange "statisch" erscheinenden 32 Bit und Ansi gewöhnen konnten.
(Mit Win2000 ist Windows seit dem Jahr 2000 im Konsumerbereich Unicode und Delphi schaffte erst 2008, mit Delphi 2009, den Sprung.
Windows und die CPUs sind auch schon seit vielen Jahren 64 Bit und Delphi hat auch das noch nicht geschaft.
OK, XP64 kann man vergessen, aber seit Vista im Jahre 2007 hält nun auch immer mehr 64 Bit im Konsumerbereich einzug und Delphi hat es wiedermal immernoch nicht hinbekommen. (wenn ich das jetzt hochrechne, dann komm ich für den 64-Bit-Delphi-Compiler auf das Jahr 2015-2017)

(weil ich grad so schön am schreiben war ... hier nochmal für die Anderen)

In einigen Spielekonsolen sind wir schon seit Jahren über die 64 Bit hinaus, also könnte/wird dieses bestimmt auch irgendwann in den PCs Einzug halten.
Wenn die PCs dann mal 128/256 Bit haben werden (PS: Die Grafikkarten machen das doch anscheinend schon, und immer mehr Programmierer verschieben schon einige Berechnungen in die GPU), dann wird Delphi hoffentlich auch schon ein Weilchen 64-Bittig sein.

[Sherlock]

Zitat von himitsu:

Zitat von Sherlock:

Den Teil hab ich wohl in der D5 Hilfe überlesen...und damals war die noch wirklich ausführlich.

Einige Auszüge aus der OH meines Delphi 4 ... nur damit keiner behaupten kann, er wußte von nichts.

Zitat von Reelle Typen:

Der generische Typ Real ist in der aktuellen Implementation mit dem Typ Double identisch.

Zitat von Integer-Typen:

Es gibt zwei generische Integer-Typen: Integer und Cardinal. Diese Typen sollten, wenn möglich, immer verwendet werden, da sie die optimale Ausführungsgeschwindigkeit für die zugrundeliegende CPU und das Betriebssystem gewährleisten

Also, nur wenn ich mich esoterisch mit irgendwelchen anderen Typen die sich viel zu sehr nach API oder NonVCL anhören herumgeschlagen habe, hab ich was richtig gemacht. Und doch sagte die Hilfe dmals eindeutig, (siehe fetter Text) welche Typen zu verwenden seien. Generisch heisst ja auch nicht wirklich "Achtung, nicht verwenden, das haben wir nur zum Spaß implementiert". Aber ich kauf mir das Zeug ja auch nicht, insofern bin ich raus aus der Diskussion.

Sherlock