TObject.GetHashCode hides virtual method of base type TObject

[Rollo62]

Hallo zusammen,

ich bin gerade beim Frühjrahrsputz, und natürlich finde ich wieder ein Thema was erst einfach aussieht,
aber wo man sich immer tiefer reinwurschteln muss.

Ich habe die PegTopCommon library für ein Projekt ausprobiert, von der ich nur einen kleinen Teilbereich bräuchte.

Beim Kompilieren habe ich aber immer die unschöne Warnung s.o.

Ich habe (einen) der Verursacher unten mal rausextrahiert, und separat getestet.

Das Problem ist wohl Folgendes:
- jede Klasse ist von TObject abgeleitet
- TObject enthält eine virtuelle GetHashCode Funktion
- Die PegTop Klassen machen genau das wie oben, und benutzt dämlicherweise den speziellen Namen der Funktion mit
anderer Signatur

Interessant zu dem Thema auch;
http://www.delphi-treff.de/object-pascal/vererbung/
http://blog.marcocantu.com/blog/6hidden_delphi2009.html
http://codebetter.com/davidhayden/20...alsobject-obj/
http://docwiki.embarcadero.com/Libra...ct.GetHashCode


Meine Frage ist wie sollte man mit so einer Situation umgehen, kann man das per overload erledigen (so einfach in dem Fall jedenfalls nicht).
Die grosse Frage ist aber sollte man das overloaden, immerhin ist das ja fast wie ein Keyword zu sehen, und wer weiss
was sich im Weiteren Objektleben so daran stört.
Einfach ignorieren ist für mich auch keine Lösung, solche Warnings will ich nicht im Code sehen.

Ich werde PegTop wohl rausschmeissen, anyway, aber noch habe ich den Code im Test Laufen und vielleicht gibt es doch das eine oder andere wo PegTop sich lohnt.
Interessieren würde mich schon was die sich dabei gedacht haben und wie man das evtl. fixen kann.

Delphi-Quellcode:

unit Unit1;

interface

uses
   System.Classes
  ;


type
  TPegtopAbstractHash = class
  protected
  public
    constructor Create(InitialCapacity: Integer = 100); virtual;
  end;

  TPegtopIntHash = class(TPegtopAbstractHash)
  private

    // Hier kommt Warning
    // hides virtual method of base type TObject
    function GetHashCode(Key: Integer): Integer;


  public
    constructor Create(InitialCapacity: Integer = 100); override;
    destructor Destroy; override;
  end;




implementation

{ TPegtopAbstractHash }

constructor TPegtopAbstractHash.Create(InitialCapacity: Integer);
begin


end;

function TPegtopIntHash.GetHashCode(Key: Integer): Integer;
begin
  Result := 0;
end;


constructor TPegtopIntHash.Create(InitialCapacity: Integer);
begin
   inherited Create( InitialCapacity );
end;

destructor TPegtopIntHash.Destroy;
begin

end;


end.

[Sir Rufo]

Delphi-Quellcode:

TPegtopIntHash = class(TPegtopAbstractHash)
  private

    // Hier kommt Warning
    // hides virtual method of base type TObject
    function GetHashCode(Key: Integer): Integer; overload;


  public
    constructor Create(InitialCapacity: Integer = 100); override;
    destructor Destroy; override;
  end;

[Stevie]

Zitat:

Zitat von Sir Rufo (Beitrag 1329303)

Delphi-Quellcode:

    function GetHashCode(Key: Integer): Integer; reintroduce; overload;

fixed

[Rollo62]

Hallo ihr beiden,

dankesehr, ja ich hatte schon vermutet das es irgendwie machbar ist, mit reintroduce hatte ich noch nicht gecheckt.

Die Frage ist für mich aber vor Allem auch: Sollte man das überhaupt machen ?
Greift man da nicht evtl. zu tief in irgendwelche TObject oder Rtti Strukturen ein,
die mir dann ganz woanders um die Ohren fliegen ?

Rollo

[Sir Rufo]

Was brauchst du denn da? Etwa eine Hash-Funktion?

Da gibt es auch was eingebautes in Delphi http://docwiki.embarcadero.com/Libraries/de/System.Hash

[Rollo62]

Nein ich brauch sie nicht.

Ich will nur nicht das ich mir durch so eine Komponente wieder irgendwelche Probleme reinhole.
Zumal PegTop wie gesagt eigentlich nur wegen der Farbtabellen, Colorwähler, etc. nutzen möchten,
wie gesagt, werde ich auch schnell ersetzen.

Die Meldungen kommen ja beim Kompilieren der PegTop Libraries selbt, hat nix mit meinem Code zu tun,
denn ich versuche eigentlich alle Warnings bei zu verbannen.
(nur ein paar besondere Hints bekommen bei mir noch eine kurzfristiges Schonfrist :stupid: Wie: variable never used).

Aber bei etwas wie "GetHashCode" würde ich ungenre reinpfuschen, ohne zu verstehen wofür eine TObject Klasse das intern braucht.
Könnte sein das diese Hashes für Rtti, Attribute oder ähnliches sind, und wenn sie nicht konform sind läuft etwas aus dem Ruder.

Deshalb hab ich es bis jetzt eben noch nicht gefixt, sonder ignoriert.
Was der Bauer nicht kennt, frisst (verwurschtelt) er nicht, sollte doch besser der PegTop Entwickler selbst mal ran.


Rollo

[Sir Rufo]

Delphi-Quellcode:

TObject.GetHashCode

wird z.B. im

Delphi-Quellcode:

TDictionary<TKey,TValue>

verwendet, wenn

Delphi-Quellcode:

TKey

von

Delphi-Quellcode:

TObject

abgleitet ist.

[Rollo62]

Und wass passiert dann damit wenn die GetHashCode mit geänderter Signatur darin verwurstet wird ?

Delphi-Quellcode:

 function GetHashCode(Key: Integer): Integer; reintroduce; overload;

Die normale TObject.GetHashCode hat keinen Key Parameter.

Dann wird im Dictionary hoffentlich wieder die orginale Routine aufgerufen.
Und dann: gibt es Zwei verschiedene HashValues für dasselbe Object.
Wozu PegTop das braucht ist mir schleierhaft.

Warum man solchen Kernprozedurene von Delphi eine neue Signatur vergeben muss verstehe ich nicht,
deshalb ist mir auch die ganze Library nicht ganz geheuer.
Wer so etwas macht, und dann noch nicht einmal die Warnings richtig beseitigt, dem traue ich auch noch mehr Unsinn zu.

Rollo

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1329409)

Warum man solchen Kernprozedurene von Delphi eine neue Signatur vergeben muss verstehe ich nicht,
deshalb ist mir auch die ganze Library nicht ganz geheuer.
Wer so etwas macht, und dann noch nicht einmal die Warnings richtig beseitigt, dem traue ich auch noch mehr Unsinn zu.

Vielleicht hat derjenige das vor langer Zeit geschrieben und/oder kein "aktuelleres" Delphi, wo TObject das noch nicht hatte.

Da sich hier die Signaturen (Parametertypen) unterscheiden, kann man eigentlich niemals das Falsche aufrufen.

reintroduce schaltet nur die Compilerwarnung aus, also dass man die alte Methode "absichtlich" verdeckt hat und somit keine Warnung nötig ist.

[Rollo62]

Hallo himitzu,

ja ich stelle auch fest das eigentlich nichts Schlimmes passiert.
Womöglich war das wirklich mal im alten Code anders geregelt, hab ich nicht gecheckt.

Ich fasse halt die "private parts" von anderen ungerne an :stupid:
Man weiss ja nie was dann passiert ...

Rollo