Na, schon Delphi XE gekauft?

[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

[Insider2004]

Was mich ärgert:

Man kauft für 1000 oder 2000€ eine Delphi Version inklusive Bugs. Diese werden erst in der neuen Version gefixt. Die dann wieder den gleichen Betrag kostet. Die Updates, die es zwischendurch gibt kann sich Emba schenken. Da sind eh nur 10 oder 20 Fixes drin.

[Bernerbaer]

Es scheint, als ob ich mit meiner Analyse in diesem Thread nicht ganz falsch gelegen bin (obwohl ich da noch als Zitat "Bash0r" bezeichnet wurde. So wie ich diesen Thread interpretiere, werden neben mir, noch viele andere dieses Update auslassen oder, was ich nicht hoffe, den Delphipfad verlassen.

[jbg]

Nochmal ein Update meines Binary Patches für den ErrorInsight Speicher Bug. Die letzte Byte-Ersetzung führte zu einer Exception im .NET ErrorInsight code, womit das komplett ausfiel.

Hier also der korrigierte Patch.

• Die Datei $(BDS)\bin\Borland.Studio.Delphi.dll wegsichern (die braucht man wenn ein Update kommt)
• Die Datei $(BDS)\bin\Borland.Studio.Delphi.dll wegsichern, ja das meine ich so
• Wenn du bis jetzt immernoch nicht die Datei $(BDS)\bin\Borland.Studio.Delphi.dll weggesichert hast, dann ist das die letzte Warnung.
• Borland.Studio.Delphi.dll in Hex-Editor (z.B. HxD) öffnen.
• Nach der Byte Sequenz "17 0B 28 47 05" suchen und die "17" durch "16" ersetzen.
• Nach der Byte Sequenz "3E 33 EB 09 1F" suchen und die "3E" durch "E6" ersetzen.
• Nach der Byte Sequenz "3E 33 E8 11 04 1F" suchen und die "3E" durch "E6" ersetzen.
• Datei speichern, aber vorher die Sicherungskopie anlegen.

[himitsu]

Ja und natürlich das must have für jeden echten Fan ... das Wallpaper

http://cc.embarcadero.com/Item/28014

[sh17]

Zitat von himitsu:

Ja und natürlich das must have für jeden echten Fan ... das Wallpaper

http://cc.embarcadero.com/Item/28014

Könnte auch eine festgegangener IDE-Start sein - Vielleicht ist das Intro-Bild ja Fullscreen....

[blackfin]

Das Wallpaper sieht mir ja nach richtig viel Arbeit aus....
5 Minuten Photoshop vom Praktikanten, der sein erstes Projekt machen darf und damit 1 Tag vor Release beauftragt wurde?

Wir brauchen ein Wallpaper!....Aber..ich hab doch nur diese paar Jpeg's!....Egal, hau einen Bevel und einen Gradient drüber, und wenn alle Stricke reissen mach irgendwo noch nen lens flare rein...obwohl, nein, für den lens flare ist keine Zeit mehr!

[MEissing]

Zitat von jbg:

Nochmal ein Update meines Binary Patches für den ErrorInsight Speicher Bug.

Auch ein Update aus der Entwicklungsabteilung:
Man hat das Problem identifiziert und hat einen Hotfix erstellt; dieser wird zur Zeit getestet und bald freigegeben.

[alzaimar]

Zitat von MEissing:

...Man hat das Problem identifiziert und hat einen Hotfix erstellt; dieser wird zur Zeit getestet und bald freigegeben.

Und täglich grüßt das Murmeltier