Na, schon Delphi XE gekauft?

[Robotiker]

Zitat:

Zitat von mkinzler (Beitrag 1046635)

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! :thumb:

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. :pale:

[himitsu]

Zitat:

Zitat von Robotiker (Beitrag 1046644)

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. :stupid:

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.

[mleyen]

Zitat:

Zitat von mkinzler (Beitrag 1046635)

NativeInt

Der steht nichtmal auf Wikipedia. Aber soviel zu dem:
In D2007 ist NativeInt 64 bit groß und in D2010 ist es 32 bit.

Delphi-Quellcode:

const
  snInt = SizeOf(NativeInt);
  tmp = snInt; // D11=8 | D14=4 ?!
  abc: NativeInt = Nativeint(MaxInt)*Nativeint(MaxInt); // doesnt fail in D11

Wäre RandomInt nicht passender? :lol:

Ich glaub ich schreib mir privat jetzt ne kleine Datentypunit mit Unittest, welches ich bei neuen Delphiversionen laufen lasse. (Int8-UInt64, Int, Ptr, Str und Chr)

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1046650)

Zitat:

Zitat von Robotiker (Beitrag 1046644)

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. :stupid:

Es wird dann imo wohl auf LLP64 oder LP64 hinauslaufen, entweder abhängig von der Zielplattform (wenn das dann nächstes Jahr geht :P) oder man einigt sich für alle Plattformen auf eine.

[MEissing]

Zitat:

Zitat von Win32.API (Beitrag 1046649)

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)

[himitsu]

Zitat:

Zitat von mleyen (Beitrag 1046656)

Ich glaub ich schreib mir privat jetzt ne kleine Datentypunit mit Unittest, welches ich bei neuen Delphiversionen laufen lasse. (Int8-UInt64, Int, Ptr, Str und Chr)

Ich wollt mir sowieso mal was scheiben, welches die Delphieigenen DCUs neu kompiliert, da kann man sowas gleich mit anpassen. :angel:
Mich stört es tierichst, daß z.B. die Indy-DCUs mit Debuginfos kompiliert wurden, selbt diese, welche es eigentlich nicht sein sollten.
Sowas macht richtig Spaß, wenn man mal wieder (ohne DebugDCUs) debuggen will und dennoch ständig in solchen Units landet. :wall:

[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" :D 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.

[p80286]

[QUOTE=himitsu;1046630
Wer so "alt" ist, der hat auch schon (fast) die 16-nach-32-Bit-Umstellung mitgemacht ... und genau dann hätte man sich denken können, daß es irgendwann mal weitergehen kann :zwinker:
[/QUOTE]

Die Umstellung hab ich ziemlich schnell mitbekommen und ich habe mir mit long... weitergeholfen.
Ich kann mich übrigens noch an die 8Bit-Zeiten erinnern, Da gab es allerdings schon 8 und 16Bit Typen parallel.

Und letztendlich laufen doch die meisten von uns irgendeinem Guru hinterher, der genau weiß was die Zukunft bringt (mich eingeschlossen).

Warum zum Teufel gibt es eigentlich keine Word16, word32, word64 usw. Dann wäre dieses Long/Short/wasweisichcardinal Jonglieren überhaupt nicht notwendig!

Gruß
K-H

[Hansa]

Zitat:

Zitat von mkinzler (Beitrag 1046625)

Deshalb bekommt man ja bei einer neuen Delphiversionen, das Nutzungsrecht für ältere hinzu.

Das ist nicht Dein Ernst oder doch ? :shock: Der Thread heisst : "Na, schon Delphi XE gekauft?" und nicht : "Na, schon D2005 gekauft ?" Es ist ja schön und gut, wenn ältere Versionen auch mitgeliefert werden, aber nur für den Fall der Fälle. Glaube jedenfalls kaum, dass jemand sich XE kauft, um mit D7 zu programmieren. 8-)

Zitat:

Zitat von himitsu (Beitrag 1046630)

...der hat auch schon (fast) die 16-nach-32-Bit-Umstellung mitgemacht ... und genau dann hätte man sich denken können, daß es irgendwann mal weitergehen kann :zwinker:

Ne, kann zumindest ich so nicht gelten lassen. Mavarik kann ich auch gut verstehen, habe ja selber den fehlenden Compiler-Schalter wegen Unicode angemahnt. Warum muss eigentlich ein Typ geändert werden bei demselben Namen ? Das heisst ganz klar : derselbe Quelltext verhält sich anders, je nach Betriebssystem/Compiler. Warum hat man denn überhaupt den alten 2 Byte integer plötzlich zum longint, also 4 Byte gemacht ? Im Quelltext steht ja nach wie vor : integer. Bei for-Schleife bis 20.000 ist das egal, aber wo nicht ? Wie wärs mit Datenbankfeld, welches maximal den Wert 6XXXX erwartet, aber eines vorgesetzt bekommt, was maximal 2.XXX.XXX.XXX enthalten kann ? Ich kann doch die tatsächliche Grösse einer Zahl nicht von dem verwendeten Betriebssystem abhängig machen. :shock:

Falls das nötig werden sollte : man freue sich der neuen eigenen Compiler-Schalter und $IFDEF's an jeder Ecke. :lol:

Delphi-Quellcode:

(*$DEFINE My32BitProg*)

(*$IFDEF My16BitProg*)
  MyInt = smallint;
(*$ELSE*)
  (*$IFDEF My32BitProg*)
     MyInt = integer;   // unter 64 Bit-Win überhaupt noch integer richtig ?
  (*$ELSE*)
    (*$IFDEF My64BitProg*)
     MyInt = ???
(*$ENDIF*)

Würde ja theoretisch auch so in der Richtung gehen, aber ist das wirklich gut ? Ich sage : integer hat eben jetzt 4 Byte und fertig. Wer grössere Zahlen braucht, der kriegt eben neue Typen. Was ich übrigens noch nirgendwo gesehen habe : wie siehts mit Datensicherung aus ? Wenn ich eine Datei mit den jetztigen smallint-Zahlen habe, Milliarden Messwerte (Anzahl, nicht Wert!!) etc. was nützen mich da 64 Bit integer ? Damit diese Datei nicht unnötig aufgebläht wird, muss ich das Programm von Hand auf smallint umbauen. Neucompilieren alleine reicht dann nicht mehr !

[himitsu]

Short (8), Small (16), Long (32) und LongLong/Double/Large (64)
so schwer ist es nun auch nicht :stupid:

[MEissing]

Zitat:

Zitat von Win32.API (Beitrag 1046664)

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:

Zitat von mkinzler (Beitrag 1046681)

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)

[Bernhard Geyer]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046632)

@Bernhard Geyer: Dann hast Du Glück gehabt. Gabs ne Anforderung nach mehreren Sprachen oder hast Du nur aus Langweile getan? :wink:

Das war meine erste größer Aufgabe im neuen Job. Hätten wir es nicht gemacht, würden wir vermutlich jetzt kleinere Brötchen (sprich weniger Kunden) packen müssen. (Habe Kunden auf mindestens 4 Kontinenten)

[Win32.API]

Zitat:

Zitat von MEissing (Beitrag 1046676)

Zitat:

Zitat von Win32.API (Beitrag 1046664)

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.

[gammatester]

Zitat:

Zitat von mkinzler (Beitrag 1046691)

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!

[himitsu]

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

Zitat:

Zitat von Sherlock (Beitrag 1046686)

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:

Zitat von Reelle Typen

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

Zitat:

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:

Zitat von String-Typen

Das reservierte Wort string funktioniert wie ein generischer Typbezeichner.

Zitat:

Zitat von Hansa

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

Zitat:

Zitat von himitsu

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

Zitat:

Zitat von himitsu (Beitrag 1046616)

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:

Zitat von himitsu (Beitrag 1046630)

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.

[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.

[MEissing]

Zitat:

Zitat von Win32.API (Beitrag 1046693)

Zitat:

Zitat von MEissing (Beitrag 1046676)

Du sprichst in Rätseln...

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

Ah.

Das Rätsel lüftet sich....?

Du meinst im Quellcode-Editor?
Du meinst im Adressfeld der Willkommens-Seite?
Du meinst Layout-Feld?
[...]

[Win32.API]

Lass ich mir Heute wirklich alles aus der Nase ziehen? :stupid:

Im Quelltext-Editor.

[Mavarik]

WOW..

Jetzt geht es aber a hier...

Für mich gibt es ÜBERHAUPT keinen Grund einen bestehenden Datentypen zu ändern...

Schon bei der Umstellung von String zu Longstring... Ich fand das als eine unverschämtheit! Aber wenigstens gabs es {H-} jede 2. Unit hat das noch...

Neuer Datentypen neuer Name... Kann doch nicht so schwer sein...
Das gleiche gilt für Routinen mit geänderter Parameterliste.

Oder geänderte Type sage nur SearchRec...

Aber das ist schnee von Gestern das hat man ja im laufe der Zeit umgebaut...
Aber ich hatte gehoft das die schlauer werden...

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...


Mavarik :coder:

[himitsu]

@Mavarik: Seit der Umstellung vom "ShortString" (früher String) auf AnsiString, wurde doch schon gesagt, daß der "neue" String ein generischer Typ ist.
Also war es auch Klar, das sich der String irgendwann mal ändern könnte und nur der AnsiString so bleibt, wie er ist.

Es wurde also absolut kein "bestehender Datentyp" geändert. (seit D2 und in Bezug auf Integer/Real/Char)
Von der Definition her ist der String immernoch generisch und er hatte sich intern an das Unicode angepaßt.

Was wird nur passieren, wenn dann mal auf UCS4 umgestellt wird und der Char dann mal 4 Byte groß ist. :roll:

Zitat:

Zitat von Mavarik (Beitrag 1046700)

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...

Das ist doch immernoch so?
Also wenn man die passenden/richtigen Datentypen verwendet hatte und nicht irgendwelche Pointeroperationen mit "falschen" Datengrößen verwendet.

[Bernhard Geyer]

Beim Typ "String" ist die Arbeit bezüglich Portierung (für Codegear) einfacher wenn man String = Wide/Unicodestring nimmt.
Alle API in der Unicode-Win32API sind nunmal mit PWidechars statt PChars definiert. D.h. hätte man einen anderen Typ genommen hätte man alle WinApi-Bibliotheken (Windows.pas, ...) entsprechend anpassen müssen. Die Frage ist wieviel Code dadurch dann nicht mehr gegangen wäre ist auch offen.

Bei Integer ist glaube ich das gleiche Problem. Wenn nun "der Rest der Welt" beim Sprung auf 64-Bit die länge von Integer gleich lässt müsste ebenfalls jede API-Funktion kontrolliert bzw. angepaßt werden.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1046702)

Was wird nur passieren, wenn dann mal auf UCS4 umgestellt wird und der Char dann mal 4 Byte groß ist. :roll:

Glaube ich nicht das das kommt. WinAPI/Java/.NET laufen alle mit UTF16 und können damit mehr als die Baseplane von Unicode. Es besteht also keine Notwenigkeit hier auf UCS4 zu wechseln (Lazarus hat sich selbst UTF16 gespart und läuft mit UTF8 obwohl das bedeutet das man mit fast jeder Schnittstelle nach UTF16 wandeln muss).

[Namenloser]

Zitat:

Zitat von Mavarik (Beitrag 1046700)

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...

Wenn man die richtigen Datentypen verwendet hat, gilt das auch in Zukunft noch, selbst für 64 Bit. Wer sich darauf verlassen hat, dass generische Typen immer die gleiche Größe behalten, ist selbst schuld - nirgens steht, dass ein Integer immer 32 Bit breit sein muss. Wenn du das dennoch als gegeben hinnimmst, bindest du dich logischerweise eben an eine bestimmte Plattform. Es ist dann nicht die Schuld des Compilerherstellers, wenn dein Code, der unter einer Plattform "zufällig" funktioniert hat, auf einer anderen versagt.
Oder beschwerst du dich auch, wenn dein X86 Inline-Assembler nicht funktioniert, wenn du hypothetischerweise irgendwann mal für's iPhone kompilieren willst?

[gammatester]

Zitat:

Zitat von mkinzler (Beitrag 1046696)

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.

Noch einmal: Diesen "neuen" String, der angeblich mit Delphi eingeführt wurde, gibt es in Delphi 1 nicht! Natürlich bleibt es Dir unbenommen, zu behaupten Delphi 1 sei kein Delphi :)

[gammatester]

Zitat:

Zitat von himitsu (Beitrag 1046702)

Es wurde also absolut kein "bestehender Datentyp" geändert. (seit D2 und in Bezug auf Integer/Real/Char)

Es ist mir unbegreiflich, wie Du so etwas behaupt kannst. Das Unicode-Debakel, als ein char mehr als ein 1 Byte bekam, liegt ja wohl noch nicht solange zurück. Und selbst Du bist doch wohl nicht der Meinung, daß eine Größenverdopplung, absolute keine Änderung ist.

Real: Noch in Delphi 3 ist Real der 6-Byte-Type, der später mal wohl Real48(?) genannt wurde. Auch keine Änderung? Raider heißt jetzt twix, sonst keine Änderung.

[mkinzler]

Delphi 1 ist zawr lange her, und in meiner Erinnerung wurde der neue Typ in D1 eingeführt, aber auch wenn es D2 war, seit da ist string ein generischer Typ

[blackfin]

Ohmann....

Wir sollten ein WoW-Arenateam gründen, da kriegt man wenigstens Punkte dafür, wenn man sich gegenseitig zerfleischt :D

[MEissing]

Zitat:

Zitat von Win32.API (Beitrag 1046699)

Lass ich mir Heute wirklich alles aus der Nase ziehen? :stupid:

Im Quelltext-Editor.

Hier passiert NIX.

[himitsu]

Zitat:

Zitat von gammatester (Beitrag 1046707)

Es ist mir unbegreiflich, wie Du so etwas behaupt kannst. Das Unicode-Debakel, als ein char mehr als ein 1 Byte bekam, liegt ja wohl noch nicht solange zurück. Und selbst Du bist doch wohl nicht der Meinung, daß eine Größenverdopplung, absolute keine Änderung ist.

Doch bin ich.
Delphi 2007: Char = ein generischer Typ (da Ansi-Compiler > AnsiChar)
Delphi 2009: Char = ein generischer Typ (da Unicode-Compiler > WideChar)

Also da hat sich an seiner Definition absolut garnichts verändert.


"Real48" war schon immer ein Fehler und dieser Fehler wurde dort gefixt.


PS: String ist kompatibel zu PChar (seit Delphi 2) und an der PChar-Definition hat sie wohl noch nie was geändert.
(also, seitdem man erkannt hat, daß 1-Byte zukünftig nicht mehr ausreichen wird und man irgendwann man upgraden muß)

[Daniel]

Och Leuts, was soll denn diese Wortklauberei?
Die Tatsache, dass ein Char seit Delphi 2009 mehr als 1 Byte belegt, war für viele Entwickler in ihrer Praxis eine signifikante Änderung. Dass dahinter am Ende immer noch ein "Zeichen" steht, ist natürlich korrekt, aber darum geht's doch hier gar nicht.

Die Rechthaberei bringt uns hier nicht weiter.

[Win32.API]

Zitat:

Zitat von MEissing (Beitrag 1046710)

Zitat:

Zitat von Win32.API (Beitrag 1046699)

Lass ich mir Heute wirklich alles aus der Nase ziehen? :stupid:

Im Quelltext-Editor.

Hier passiert NIX.

Bei mir hängt sich die IDE auf. Windows 7 64 Bit. Delphi XE 15.0.3890.34076 als Trial.

[gammatester]

Zitat:

Zitat von himitsu (Beitrag 1046711)

Doch bin ich.

Lächerlich! 2=1 oder was?

Zitat:

Delphi 2007: Char = ein generischer Typ (da Ansi-Compiler > AnsiChar)
Delphi 2009: Char = ein generischer Typ (da Unicode-Compiler > WideChar)

Also da hat sich an seiner Definition absolut garnichts verändert.

Wenn es denn eine Definition gibt, zeigt es doch gerade, daß sie sich geändert hat: von

Delphi-Quellcode:

type char = ansichar;

zu

Delphi-Quellcode:

type char = widechar;

Also hat sich neben der Semantik auch die Definition geändert.

Zitat:

"Real48" war schon immer ein Fehler und dieser Fehler wurde dort gefixt.

??? Wenn überhaupt, geht diese Ausage am Problem vorbei, daß sich die Bexdeutung von Real geändert hat.

[Sherlock]

Zitat:

Zitat von himitsu (Beitrag 1046695)

Zitat:

Zitat von Sherlock (Beitrag 1046686)

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:

Zitat von Reelle Typen

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

Zitat:

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

[Ralf Kaiser]

Zitat:

Zitat von Win32.API (Beitrag 1046713)

Zitat:

Zitat von MEissing (Beitrag 1046710)

Zitat:

Zitat von Win32.API (Beitrag 1046699)

Lass ich mir Heute wirklich alles aus der Nase ziehen? :stupid:

Im Quelltext-Editor.

Hier passiert NIX.

Bei mir hängt sich die IDE auf. Windows 7 64 Bit. Delphi XE 15.0.3890.34076 als Trial.

Bei mir sehe ich im Taskmanager, dass der Speicherverbrauch plötzlich ansteigt. Nach circa 20 Sekunden ist er bei 1GB angekommen und belibt dort stehen. Lösche ich die "magischen Zeichen" im Editor passiert erstmal nichts.

Erst wenn ich sie wieder eingebe dann geht der Speicherverbrauch plötzlich wieder runter auf den ursprünglichen Wert um dann sofort wieder hoch zu laufen. Ist schon seltsam...

EDIT: die selbe Konfiguration, waas Windows und Delphi betrifft