Delphi 10.1 Berlin

[Der schöne Günther]

Zitat von Daniel:

[...]

Ich bin positiv erstaunt wieviel Sachen angefasst wurden. Insbesondere was den Compiler angeht.

Ich habe auch nichts dagegen wenn es Arbeit erfordert. Aber ich sehe hier das Problem dass Lösungen die etwas schmutzig waren jetzt nur noch deutlich schmutziger zu lösen sind. Denn einen Ausweg sehe ich nicht. Aber ich bin auch nicht der Schlauste.

Naja, ich installiere "Berlin" erst einmal und schaue dann, wo wirklich an private Member herangegangen wurde (und keine protected). Dann jammere ich weiter.

[Daniel]

Mach doch einfach mal ein Thema auf und schreibe über ein konkretes Beispiel, bei dem Du betroffen bist.

Man liest sehr viel über die möglichen Auswirkungen und könnte meinen, dass Ihr alle ständig nur mit fehlerhaften Klassen anderer Entwickler konfrontiert werdet und besagte Class-Helper der einzige verbleibende Weg wären. Ich ziehe in Zweifel, dass die Menge an Beiträgen zu dem Thema, die man hier oder anderswo liest, repräsentativ ist.

[himitsu]

Zitat von jaenicke:

Das heißt dann wohl, dass ich Bugs wie den in TRSACypher nun nur noch durch direkten Speicherzugriff lösen kann...
Das bedeutet Umbaumaßnahmen hin zu echt bösem Code... aber wird dann wohl nicht anders gehen, wenn die Anwendungen nicht beim Beenden abstürzen sollen und das in 10.1 noch nicht behoben sein sollte...

Über die erweiterte RTTI kommst du dennoch ran. (ist dann halt nur ein bisschen hässlicher oder unperformanter)

Alternativ gibt es noch den Weg über eine Dummy-Klasse und einen bösen Cast. (ergibt einen schönen Compilerhinweis)

Delphi-Quellcode:

{
  TWinControl = class(TControl)
  private
    FAlignControlList: TList;
    FAlignLevel: Word;
    FBevelEdges: TBevelEdges;
    FBevelInner: TBevelCut;
    ...
}

type
  THackedWinControl = class(TControl)
  public
    FAlignControlList: TList;  // Pointer
    FAlignLevel: Word;
    FBevelEdges: TBevelEdges;  // Byte
    FBevelInner: TBevelCut;
  end;

THackedWinControl(Edit1).FBevelInner

Problem hierbei treten auf, wenn in einer anderen Delphi-Vesion die Klasse anders aufgebaut ist und das Gewünschte nun an einer anderen Speicheradresse liegt.
Von der Laufzeit her ist das genauso schnell, als wäre es schon immer Public, aber man sollte zu Programmstart die korrekte Position irgendwie prüben.

Man kann aber auch vorher per RTTI die Stelle suchen und dann im laufenden Code böse rumpointern.
PBevelCut(IntPtr(Self) + Offset)^ // IntPtr=NativeUInt

[Der schöne Günther]

Kann mir jemand sagen wieviel Festplattenplatz man diesmal für eine Vollinstallation braucht? Das Setup meinte, es würde dicke hinkommen, meine 40GB reichen schon. Bei 67% brach er dann ab, Festplatte voll.

[sh17]

Ich hab zwar nicht Vollinstallation, nur VCL,FMX, aber grad mal 4GB

[himitsu]

Das Setup zählt wohl immernoch seine Kopie nicht mit?
Oder vielleicht die Zustatzprogramme? (Prerequisites)
= Installiertes Delphi + einfach mal schauen wie groß die ISO ist.

@sh17: Keine Setupkopie mehr in C:\ProgramData\{ein paar Pfade mit GUID als Name} ?

[Bernhard Geyer]

Zitat von Der schöne Günther:

Kann mir jemand sagen wieviel Festplattenplatz man diesmal für eine Vollinstallation braucht? Das Setup meinte, es würde dicke hinkommen, meine 40GB reichen schon. Bei 67% brach er dann ab, Festplatte voll.

Das 18er Verzeichnis ist bei mir ca 5 GB groß. Weiß aber nicht was er "drumherum" so ablegt.
Und da ich Seatle schon habe, hat er evtl. auch nix am interbase machen müssen.

Daten sind für Delphi.

[Der schöne Günther]

Also C:\Program Files (x86)\Embarcadero\Studio\17.0 ist bei mir 23,6 GB groß.

Mit Vollinstallation meinte ich schon Delphi+Cpp Builder auf Windows, iOS und Android.

[Darlo]

Bei mir Delphi Seattle und Berlin beide jeweils knapp 15 GB.

[sh17]

Zitat von himitsu:

@sh17: Keine Setupkopie mehr in C:\ProgramData\{ein paar Pfade mit GUID als Name} ?

knapp 250MB

Das Android SDK zähle ich nicht mit, das ist ja extra (bei mir 50GB) und muss ja nicht x-Mal installiert werden