Na, schon Delphi XE gekauft?

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