Na, schon Delphi XE gekauft?

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1046311)

Es muss/wird natürlich eine neue Version der RTL geben

Logisch, aber imo wird das "Chaos" noch größer als bei der Unicode Umstellung. Da isses nich damit getan zu sagen, ok meine 32bit Datentypen sind nun 64bit, fettich.

[blackfin]

Irgendwie dreht sich der Thread wieder thematisch zurück zu den anderen drölftausend :D

[Stevie]

Zitat:

Zitat von blackfin (Beitrag 1046315)

Irgendwie dreht sich der Thread wieder thematisch zurück zu den anderen drölftausend :D

Daran sieht man, wie fesselnd die neuen Features von Delphi XE sind! 8-)

[mkinzler]

Wie groß die Zeiger in der VMT snd ist eigentlich egal, wenn man nicht and der RTL vorbei direkt die Strukturen ausliest oder manipulierst

[blackfin]

Zitat:

Daran sieht man, wie fesselnd die neuen Features von Delphi XE sind!

Kann man wenigstens das Unterwasser-Game direkt aus der IDE heraus spielen?...

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1046317)

Wie groß die Zeiger in der VMT snd ist eigentlich egal, wenn man nicht and der RTL vorbei direkt die Strukturen ausliest oder manipulierst

Du meinst, so wie zum Beispiel in der Rio.pas von Delphi? Oder in der IntfInfo.pas?
Ich wollte damit sagen, dass es haufenweise Sourcecode gibt, der teilweise sogar von Delphi Profis wie Halvard Vassbotn oder Barry Kelly stammt und bestimmt an vielen Stellen Verwendung findet. Und der wird mit an Sicherheit grenzender Wahrscheinlichkeit dann nicht mehr funktionieren.

Das wollte ich mit

Zitat:

Zitat von Stevie (Beitrag 1046314)

Da isses nich damit getan zu sagen, ok meine 32bit Datentypen sind nun 64bit, fettich.

zum Ausdruck bringen.

Zitat:

Zitat von blackfin (Beitrag 1046318)

Zitat:

Daran sieht man, wie fesselnd die neuen Features von Delphi XE sind!

Kann man wenigstens das Unterwasser-Game direkt aus der IDE heraus spielen?...

:lol:

P.S.: Das geht auch schon in Delphi 2010! Einfach die url in der Startpage eingeben :P

[himitsu]

Gib einfach ganz oben in der Adressleiste der Willkommensseite www.embarcadero-info.com/game ein.
[add] das P.S. stand vorhin noch nicht da. :shock:

Du kannst dir auch gerne einen Link in die Willkommensseite einbauen.

[blackfin]

:lol::lol::lol:
Dann möchte ich aber auch gerne beim Absturz der IDE die AV-Adresse als Highscore zu Twitter hochladen!

[himitsu]

@Daniel: Wann kommen eigentlich die ersten XE-Videos, wo du uns die coolsten Features vorstellst/zeigst?

[Daniela.S]

Also ich hab's gekauft weil ich sowieso von einer einzelnen Delphi Lizenz auf RAD Studio gewechselt habe.

[Union]

Zitat:

Zitat von quantum (Beitrag 1046210)

2. Kompilierung dauert nach jeder Kompilierung länger.

Zitat:

Zitat von himitsu

Hey, angeblich ist der Compilerjetzt fast doppelt so schnell ... du mußt also jedesmal nur halbsolange mehr warten, wie vorher. :stupid:

Nein, der Compiler ist fünf x so schnell. Allerdings nur der für C++ :wall:

[himitsu]

Zitat:

Zitat von quantum (Beitrag 1046210)

2. Kompilierung dauert nach jeder Kompilierung länger.

Mir ist das jetzt erst so richtig aufgefallen.
Mir ist zwar noch nicht aufgefallen, daß der Compiler langsamer wird,
aber schau mal auf den Speicherverbrauch vom Delphi (der IDE), ob dieser anwächst.
In TDE hatte/hab ich das Problem, daß im Compiler ein Speicherleck vorliegt.
Da der Inlinecompiler den Speichermanager der IDE mit nutzt, wird es also mit jeder Compilierung voller. Nach schonmal 'ner viertel/halben Stunde ist dann die IDE mit einem OutOfMemory verreckt ... vielleicht äußert es sich bei dir nur anders.

[quantum]

Beispiel siehe da: Delphi Bugs

[himitsu]

Uhhhh, schon die ersten Zwei(Drei) mit einem XE im Profil.

Einer mit dem Wartungsvertrag (so wie er Werbung dafür macht), dann der größe XE-Befürworter (ME...) und der Test-User mit seiner Raubkopie :stupid:

[jbg]

Zitat:

Zitat von quantum (Beitrag 1046494)

Beispiel siehe da: Delphi Bugs

Also das "Compiling takes longer and longer and ..." kann ich nicht nachvollziehen. Ist da vielleicht ein Virenscanner im Spiel?

[mirage228]

Zitat:

Zitat von quantum (Beitrag 1046494)

Beispiel siehe da: Delphi Bugs

Das mit dem EventHandler stimmt. Lässt sich aber durch Tippen von Self. vor "EventHandler" "beheben" (D2010).

[Stevie]

Bin gerade durch diesen Blog Eintrag auf TVirtualMethodInterceptor aus der Rtti.pas aufmerksam geworden. Endlich!!! Delphi kann nun AOP (wenn auch eingeschränkt und nicht komplett bugfrei)

Beispiel:

Delphi-Quellcode:

type
  TFoo = class
  public
    procedure Bar; virtual;
  end;

procedure InterceptorBefore(Instance: TObject; Method: TRttiMethod;
  const Args: TArray<TValue>; out DoInvoke: Boolean; out Result: TValue);
begin
  ShowMessage('Before: ' + Instance.ClassName + '.' + Method.Name);
end;

procedure InterceptorAfter(Instance: TObject; Method: TRttiMethod;
  const Args: TArray<TValue>; var Result: TValue);
begin
  ShowMessage('After: ' + Instance.ClassName + '.' + Method.Name);
end;

{ TFoo }

procedure TFoo.Bar;
begin
  ShowMessage('TFoo.Bar');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  interceptor: TVirtualMethodInterceptor;
  foo: TFoo;
begin
  foo := TFoo.Create;

  interceptor := TVirtualMethodInterceptor.Create(TFoo);
  interceptor.Proxify(foo);
  interceptor.OnBefore := InterceptorBefore;
  interceptor.OnAfter := InterceptorAfter;

  foo.Bar;

end;

Klasse Sache das (hab mich schon ne Weile mit AOP in Delphi und den Möglichkeiten beschäftigt). Ist leider nur ein experimenteller Status soweit ich das bei nem ersten Test sehen konnte, weil beim freigeben des Objekts noch AV oder andere Exceptions geworfen werden (liegt wohl daran, dass ausnahmslos alle virtuellen Methoden intercepted werden, was nicht so gesund ist)

Aber immerhin das erste Feature in Delphi XE, was mich begeistert. ;)

[Ralf Kaiser]

Gibt es eigentlich schon irgendwo weiterführende Informationen über die Änderungen/Neuheiten in der RTL/VCL? Was man hier lesen kann ist ja nicht wirklich viel. Ich vermute (oder besser: hoffe) allerdings, dass das Wiki in diesem Bereich einfach noch nicht auf dem aktuellen Stand ist...

[Hunni]

Hallo,

ich habe mir Das RAD Studio XE auch gerade Herunter geladen (Maintenance Vertrag Pro Version), aber irgend wie vermisse ich die PHP Personality. Diese sollte doch eigentlich dabei sein oder täusche ich mich ?

Ansonsten habe ich es gerade erst installiert und muß dann man später am Abend mit dem testen anfangen


Torsten

[mkinzler]

RadPHP muss extra Heruntergeladen und Installiert werden. Es ist weiterhin eine eigenständige IDE

[himitsu]

RadPHP mußt du extra runterladen.

Hier die DVDs
http://www.delphipraxis.net/154179-d...ml#post1046247
und die WebInstaller gibt's auch noch irgendwo.

[Hunni]

Zitat:

Zitat von mkinzler (Beitrag 1046561)

RadPHP muss extra Heruntergeladen und Installiert werden. Es ist weiterhin eine eigenständige IDE

OK

Danke für die Info

Torsten

[Mavarik]

Leute Leute...

Wie war das? Ich arbeite mit D2007 und das ist auch gut so!

Was ich heute gemacht habe:

1. Info gelesen Delphi XE ist da...
2. Videos angesehen (Überrascht auch auf Deutsch) Danke Matthias (Denke das warst doch du?!)
2.1. Wer um alles in der Welt braucht das alles? Besonders da es sich bei den Erweiterungen scheinbar fast ausschliesslich um zugekaufte tools dreht...(So hab ich es jedenfalls verstanden)
3. Foreneinträge gelesen.
3.1 Geschockt über die Nachricht das Integer bald nicht mehr Integer ist... Lol

Mein Fazit ganz alleine für mich...:
Alle meine Projekte basieren ausschliesslich auf Record-Strukturen und viele davon werden nativ als Records in Dateien gespeichert.
Und falls die Daten zu einem MySQL Server gehen, werden Sie leider Intern immer noch in Records verarbeitet...(Bitte keine Kommentare dazu)
Das ist schon der TOT für D2010, da Unicode nicht abschaltbar...(@Embac hätte ich das früher gewusst, hätte ich D2010 nicht gekauft! Angeblich sollte das gehen... Hab ich scheinbar falsch verstanden...)
Ein Projekt mit 4 Mio Zeilen hat es schon nicht von Delphi 6 nach Delphi 7 geschafft (aufgrund der Inkompatibilität)
Sicherlich können das viele Jung-Coder nicht nachvollziehen... Aber nach über 28 Jahren Programmierung sind halt tausende
Proceduren, Funktionen und techniken zusammen gekommen die halt mit den neuen Compilern nicht zurecht kommen...
Früher wurde halt viel mit "Move(Daten^", "mem[SEGA000:X] := XY" (lol), "ASM Mov AX,MyVar" usw. gearbeitet... Zugegeben das meiste davon ist schon umgebaut. Aber die gefühlten 4 Mio S[5] oder Move(Int,S[1],4); S[0] := 4; usw. lassen sich nicht mal eben umsetzen...

Ach ja: Das Einzige was immer noch nicht drinn ist... CF... Naja...

Grüsse Mavarik :coder:

PS.: Und wer braucht PHP? Es gibt doch Delphi ASP.NET.. Ach ja Schuldigung das wurde ja leider entfernt...bzw. Durch ein wieder zugekauftes Prism ersetzt... Eigentlich sollte ich auch nicht mehr programmieren sondern nur noch zukaufen... Aber dann wäre der Spass weg! Und darum geht es doch, oder?

[blackfin]

Zitat:

wer braucht PHP? Es gibt doch Delphi ASP.NET

Wieviele Server da draussen sind Linux (ohne Mono) im Vergleich zum Rest? :D

[Mavarik]

Zitat:

Zitat von blackfin (Beitrag 1046601)

Wieviele Server da draussen sind Linux (ohne Mono) im Vergleich zum Rest? :D

Leider immer noch viel zu viele...:twisted:

[ralfschwalbe]

@Mavarik: Du sprichst mir aus der Seele!!!!!!!!!!!!!

Besonders das "(Bitte keine Kommentare dazu)" hat mir besonders gefallen. :lol: Es können sich wirklich manche (leider) nicht vorstellen, dass es Projekte oder Umstände gibt, bei denen mal nicht schnell tausende Stellen im Code umstellen kann. Dafür bekommt man dann aber Hinweise, dass der Ansatz der Programmierung "überdacht werden sollte oder falsch gewählt ist". Das weiß ich auch! Aber siehe oben...
Wenn ich was Neues anfange, dann mach ich's schon richtig, aber Altes siehe oben...

[Mavarik]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046608)

@Mavarik: Du sprichst mir aus der Seele!!!!!!!!!!!!!

Danke!

Zitat:

Zitat von ralfschwalbe (Beitrag 1046608)

Dafür bekommt man dann aber Hinweise, dass der Ansatz der Programmierung "überdacht werden sollte oder falsch gewählt ist". Das weiß ich auch! Aber siehe oben...
Wenn ich was Neues anfange, dann mach ich's schon richtig, aber Altes siehe oben...

OT:Ja genau... Das bringt mich wieder dazu: "@Daniel Geburtsdaum als Pflichtfeld im Profil" damit am Postings besser einschätzen kann /OT

Aber auch mit neuen Projekten ist das so ne Sache... Es ist halt viel einfach Uses MyUnits; zu schreiben und auf 400 Procs zurückzugreifen als wieder alles neu zu Programmieren.
Und natürlich TMyEdit, TMyMaskEdit, TMyGeldEdit, TMyISAMEdit usw. Ich nutzen von fast alles Controls eine Ableitung weil ich die auf meine Anforderungen an Eingabe-Komfort angepasst habe... Abgesehen von TMyReturnForm... :stupid:

Es ist eben viel einfacher sich ein neues Projekt aus unzähligen vorhandenen Units "zusammen zu clicken" alles immer wieder bei Null an zu fangen... (Außerden sind dadurch nahezu alle Programm gleich zu bedienen und gleiches Look and Feel)

:coder:

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

[Mavarik]

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.

Nicht ganz... Mal abgesehen von {$A1} Alle Proceduren und Funktionen melden doch ein Typenfehler... Nach 6h Umbau versuchen habe ich aufgegeben...

Grüsse

[Sherlock]

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.

Warum sollte jemand nicht die (damals von Borland als solche gepriesenen) Basistypen wie String, Integer, Char, Real etc. verwenden? Es gab nunmal auch Software-Entwicklung vor Delphi 5 (eigentlich gilt das alles ja erst ab 2009, aber ich will mal die wahre Dramatik der Situation hervorheben).

Mavarik: Du hast ja sowas von Recht.

Sherlock

[ralfschwalbe]

Genau, dann hast Du keine Probleme....

Aber wer hat vor 10 Jahren einen Record mit AnsiChar oder LongWord gebaut?

Bei mir ist (fast) überall folgendes zu finden:

Code:

tMyRec = record
a1 : array[1..24] of char;
a2 : array[1..20] of char;
c1 : cardinal;
usw...
end;

Durch Compilerschalter des Projektes ({$A1}) liegt alles schön hintereinander. Da kann man nicht einfach so weiterarbeiten (mit Delphi ab 2009 meine ich). Da will ALLES umgestellt werden!

da war einer schneller... ;-)

[mkinzler]

Deshalb gibt es ja generische Tapen und fixe Typen. Die generischen sind veränderlich, die fundamentalen bleiben konstant!

Wer jetzt generische nimmt, barucht sich nicht zu wunder, wenn diese sich ändern. das ist ihre Natur.

Code:

Generische Typen:
    -string

    -Integer
    -Cardinal

Fixe (fundamentale) Typen:
    -ShortString
    -AnsiString
    -UnicodeString

    -Shortint (Int8)
    -Smallint (Int16) 
    -Longint (Int32) 
    -Int64 
    -Byte ( UInt8) 
    -Word ( UInt16) 
    -Longword (UInt32) 
    -UInt64

Jetzt soll der Integer als bisher generischen Typ zu einem fundamentalen werden. das finde ich nicht gut, da es den entsprechenden fundamentalen Typ (Longint) und einen Alias (Int32) schon gibt!

[ralfschwalbe]

Es soll nichts zu etwas anderen werden. Es soll nur angemerkt werden, dass es Umstände gibt, wo das Sch... ist. Und sag bitte nicht "Ihr habt es alle gewusst!" Wer hat vor 10 Jahren dran gedacht, das es wirklich mal 64bit OS gibt, wo der Integer keine 4 Byte mehr hat, oder das ein Char mehr als 1 Byte platz braucht.

[mkinzler]

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

Man darf sich halt nur auf das verlassen, was zugesichert ist. Wer einen generischen Typ verwendet muss sich bewusst sein, das der sich ändern kann.

Aber man hat ja ein Einsehen. Der generische Integer wird ja abgeschafft. 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!!

[Bernhard Geyer]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046624)

Wer hat vor 10 Jahren dran gedacht, ... oder das ein Char mehr als 1 Byte platz braucht.

Also ich war vor 8 Jahren darüber eine große Delphi (6) Anwendung von String auf Widestring umzustellen :mrgreen:

[himitsu]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046624)

Wer hat vor 10 Jahren dran gedacht, das es wirklich mal 64bit OS gibt, wo der Integer keine 4 Byte mehr hat, oder das ein Char mehr als 1 Byte platz braucht.

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:


@Sherlock: Ich hab nie behauptet, daß man diese generischen Typen nicht verwenden soll.

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.

[mleyen]

Zitat:

Zitat von mkinzler (Beitrag 1046625)

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.

[ralfschwalbe]

@Bernhard Geyer: Dann hast Du Glück gehabt. Gabs ne Anforderung nach mehreren Sprachen oder hast Du nur aus Langweile getan? :wink: Und zum Thema "Integer bleibt 4 Byte"; hätte man das mit string und Char nicht auch so machen können? :roll::lol::stupid:

Verzeihung, ich schweife schon wieder ab...;-) Ketzerei, Ketzerei...

[mkinzler]

Zitat:

Zitat von mleyen (Beitrag 1046631)

Zitat:

Zitat von mkinzler (Beitrag 1046625)

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.

[himitsu]

Ich finde es ehrlich gesagt blöde, daß solche Änderungen in der Natur der Typen, wie mit dem Integer, gemacht werden sollen.
Ebenso die Idee Char weiterhin als AnsiChar zu belassen.
Und das nur damit weniger von den Unmassen rumheulen, welche "fehlerhaft" Codes verwenden, der nach soeiner Umstellung nicht mehr laufen würde.

Klar, für die fehlerhaften Altlasten wäre das super, aber für "ordentlich" programmierte Codes oder für Neuprogrammierungen ist das ein graus.

Man nehme nur mal die kranken Funktionen wie AnsiLowerCase, welche jetzt urplötzlich Unicode sind, obwohl sie ANSI heißen. :wall: