Discussion :

[ZZZzzz2]

Bonjour,

je viens de voir dans le code d'un de mes collaborateurs la chose suivante :

une variable de type TObjectList<TMachin> est passé en argument à une fonction qui attends un TObjectList. Comme la version générique de "TOjectList" n'hérite pas de la version classique (les classes génériques ont une implémentation "parallèle" à leur homologue non générique) il a simplement hardcasté en "TObjectList".

Et là je me dis "horreur !" ça ne marchera pas et provoquera des erreurs de violations d'accès et autres... et bien non, tout fonctionne bien, comme si le compilateur, lors d'un hardcast, essayait de faire une conversion "propre" d'un type en un autre. Personnellement je ne comprends pas, j'ai du louper quelque chose mais pour moi un hardcast ne fait que forcer le type pour permettre la compilation mais aucune opération de conversion. D'ailleurs la seule différence avec le "soft" cast est que dans ce cas le compilo vérifie d'abord que le type est compatible (hérite ou pour une interface implémente)...

Alors visiblement je me plante, quelqu'un pourrait-il m'expliquer comment cela fonctionne ?

Au debug j'ai pu voir que la fonction utilise les méthodes "Count" et "Get" de TOjbectList (en réalité de TList duquel il hérite), et qu'elles sont appelées tout à fait normalement dans la classe TList. Pour info la méthode "Get" n'existe même pas dans la version générique "TList<T>", elle a été renommée "GetItem"... alors y-a-t-il de la magie dans le compilo Dephi ou bien autre chose que j'ai zappé ???

[popo]

Si je ne dis pas de bêtise, la liste générique hérite de la liste basique. La différence entre une liste basique et une liste générique réside dans le fait que la liste générique gère elle-même les opérations courante sur la liste en se chargeant de caster dans le type passer entre les balises "<" et ">".

En forçant le cast d'un liste générique en une liste basique, la mécanique automatique apportée par la liste générique est rompue et l'objet utilise les méthode de son ancêtre

[ZZZzzz2]

Si je ne dis pas de bêtise, la liste générique hérite de la liste basique. La différence entre une liste basique et une liste générique réside dans le fait que la liste générique gère elle-même les opérations courante sur la liste en se chargeant de caster dans le type passer entre les balises "<" et ">".

En forçant le cast d'un liste générique en une liste basique, la mécanique automatique apportée par la liste générique est rompue et l'objet utilise les méthode de son ancêtre

Justement il n'y a pas d'héritage entre les deux classes (générique et non générique), c'est pourquoi je n'arrive pas à comprendre pourquoi cela fonctionne...

[guillemouze]

Peut etre que le compilateur te fait un cadeau
Il me semble que c'est le cas quand tu fais des cast entre string / WideString / PChar / PWideChar, il remplace le cast brutal par un appel de fonction du genre "_LStrFromPChar" (dans system.pas). Il fait peut etre pareil pour les generiques de base de la VCL ...

[Paul TOTH]

Justement il n'y a pas d'héritage entre les deux classes (générique et non générique), c'est pourquoi je n'arrive pas à comprendre pourquoi cela fonctionne...

je pense que ton collègue à beaucoup de chance

prenons TObjectList qui dérive de TList:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  TList = class(TObject)
  private
    FList: TPointerList; //  = array of Pointer;
    FCount: Integer;
    FCapacity: Integer;

TObjectList<> dérive de TList<>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  TList<T> = class(TEnumerable<T>)
  private
    FItems: array of T;
    FCount: Integer;
    FComparer: IComparer<T>;

FCount se trouve au même endroit dans les deux objets, et la fonction Get utilise FList qui se trouve au même endroit que FItems

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
function TList.Get(Index: Integer): Pointer;
begin
  if Cardinal(Index) >= Cardinal(FCount) then
    Error(@SListIndexError, Index);
  Result := FList[Index];
end;

il peut donc utiliser Count et Items[] sans que ça plante ^^

par contre, il suffit qu'il fasse appel à une méthode de TList qui modifie FCapacity et là il aura une belle erreur en modifiant FComparer

[ZZZzzz2]

je pense que ton collègue à beaucoup de chance

prenons TObjectList qui dérive de TList:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  TList = class(TObject)
  private
    FList: TPointerList; //  = array of Pointer;
    FCount: Integer;
    FCapacity: Integer;

TObjectList<> dérive de TList<>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  TList<T> = class(TEnumerable<T>)
  private
    FItems: array of T;
    FCount: Integer;
    FComparer: IComparer<T>;

FCount se trouve au même endroit dans les deux objets, et la fonction Get utilise FList qui se trouve au même endroit que FItems

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
function TList.Get(Index: Integer): Pointer;
begin
  if Cardinal(Index) >= Cardinal(FCount) then
    Error(@SListIndexError, Index);
  Result := FList[Index];
end;

il peut donc utiliser Count et Items[] sans que ça plante ^^

par contre, il suffit qu'il fasse appel à une méthode de TList qui modifie FCapacity et là il aura une belle erreur en modifiant FComparer

Ah oui, et je viens de comprendre pourquoi l'appel à " TList<T>.GetItem" se transforme automagiquement par un appel à "TList.Get"... ces deux fonctions ne sont pas déclarées "au même endroit" dans la classe mais il s'agit de méthodes non virtuelles, et donc indépendantes de l'instance. De ce fait, et comme on accède aux éléments par la propriété "Items" qui appelle "TList.Get" en interne la méthode est retrouvée statiquement par rapport à la classe "TObjectList". Ceci explique cela, effectivement il s'agit pour le coup d'un bon coup de bol et le code va être modifié car on ne peut pas laisser une telle chose. Je suis rassuré (je n'aime pas ne pas comprendre )