Discussion :

[Just-Soft]

Salut les dév;

D’une part on a la notion de pointeur; sujet assez classique et faisant peur aux développeurs (pas tous heureusement), d'autre part la notion objet.

Je démarre par l'hypothèse qu'un développeur code seulement des objets alors à quoi bon s'intéresserait-il aux pointeurs ? Je fais allusion bien sûr à la nouvelle génération de développeur, pourquoi lui demander d’apprendre tout ce qui est en relation avec les pointeurs ?
En d'autres termes, les pointeurs ont-ils place dans la programmation objet? Et dans quelles conditions les utilisés ?

Merci d'avance.

[ShaiLeTroll]

Tout dépend aussi le langage !

En C# ou Java, l'objet est prédominant voire la seule solution de développement, en Java, je crois que le pointeur n'existe pas, en C# faut jouer avec le Garbage Collector.
En C++, il y a objet statique et objet (à l'allocation) dynamique, en fait, en allocation dynamique C++, on alloue un pointeur sur un objet via le New (libérer par Release, je crois), mais il existe des objets SANS allocation explicite ! c'est d'ailleurs la différence entre le . pour les objets statiques (utiliser souvent dans les fonctions pour bénéficier de la libération automatique des blocs C++) qui est remplacé par -> pour les objets dynamiques ...
En Delphi, un objet est aussi un pointeur, en fait, il n'existe finalement que l'allocation dynamique avec le Create (et son Free)

Maintenant, je connais des développeurs C# (dont mon cousin) qui ne connaissent pas ce qu'est un pointeur, n'a jamais alloué de mémoire lui même, ne connais pas ce qu'est une convention d'appel, toutes ces petites choses indispensables pour faire des DLL à la vieille époque, le .NET gérant les assembly pour éviter au développeurs de se creuser la tête pour l'opérabilité et se concentrer sur un développement métier rentable pour sa société ...

[Paul TOTH]

Salut les dév;

D’une part on a la notion de pointeur; sujet assez classique et faisant peur aux développeurs (pas tous heureusement), d'autre part la notion objet.

Je démarre par l'hypothèse qu'un développeur code seulement des objets alors à quoi bon s'intéresserait-il aux pointeurs ? Je fais allusion bien sûr à la nouvelle génération de développeur, pourquoi lui demander d’apprendre tout ce qui est en relation avec les pointeurs ?
En d'autres termes, les pointeurs ont-ils place dans la programmation objet? Et dans quelles conditions les utilisés ?

Merci d'avance.

J'ai ce genre de discussion avec un collègue

par exemple, je n'hésite pas à caster un TTreeNode.Data en Integer ou TComponent.Tag on TObject...alors que lui va faire ce genre de chose :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
var
  i : integer;
  pi : ^integer;
begin
// ma version
  Node.Data := pointer(i);
  ...
  i := Integer(Node.Data);
// sa version
  new(pi);
  Node.Data := pi;
  pi^ :=  i;
  ...
  pi := Node.Data;
  i := pi^;
  Dipose(pi);
  Node.Data := nil;
end;

ou encore

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
begin
// ma version
  Comp.Tag := Integer(Button);
  ..
  Button := TButton(Comp.Tag);
// sa version
  Comp.Tag := ObjectList.Add(Button);
  Button := ObjectList.Items[Comp.Tag];
  ObjectList.Remove(Button);
end;

je ne peux que reconnaître que son code est plus fiable que le mien Mais je continue à travailler comme je le fais...ou à dériver les composants pour leur ajouter les propriétés dont j'ai besoin car je sais ce que je fais

Le tout objet et les pointeurs c'est pareil, un pointeur est un outil au même titre que l'objet. Les connaître c'est avoir un outil en plus pour coder, les ignorer c'est avoir un outil en moins

On pourrait étendre ta question aux tableaux dynamiques et aux collections d'objets...sur un grand nombre de données je préfère de loin avoir un tableau dynamique qu'une collection d'objets dont il faudra allouer chaque instance.

[LeGEC]

Salut,

Mon grain de sel :

Les pointeurs n'ont pas disparu de la programmation.
Plein de moyens ont été trouvé pour alléger la syntaxe, et plusieurs langages proposent des moyens de cacher les accès à ces pointeurs. Je trouve que c'est une bonne chose d'alléger la syntaxe, que ça permet d'y voir plus clair, de mieux comprendre, et de moins débugger.

Par contre, la structure sous-jacente est toujours là, et être à l'aise avec la notion de pointeur en général m'a l'air autant d'actualité qu'avant, sinon plus : plus on cache au programmeur l'accès aux pointeurs et la manière dont la mémoire est allouée, plus il faut que le programmeur soit capable de comprendre quels choix ont été faits pour bien utiliser les ressources.

Le terme "programmation objet" ne veut pas à dire qu'on s'est débarrassé des pointeurs, au contraire : il faut regarder comment a été implantée la politique objet du langage (cf la construction automatique d'un objet à sa déclaration en C++, le garbage collecting en Java, ou le modèle Delphi qui fait un mix (pas piqué des vers) de comptage de références et d'allocations explicites...), il faut se rendre compte de qu'est-ce qui fait quoi (qu'est-ce que ça veut dire "appeler une fonction dynamique"? pourquoi est-ce que mon débogueur me montre 3000 lignes d'assembleur?), quelles sont les forces et les failles de chaque système...

Qu'est-ce qui se produit effectivement quand on fait une opération aussi bénigne que "a := b"? Pourquoi est-ce que "obj1 = obj2" ne renvoie pas le résultat auquel on s'attend? Comment écrire prorprement une méthode "Clone"? Quand est-ce que je dois faire un "Destroy"? Autant de question simples derrière lesquelles se cachent des pointeurs. Alors pour les questions compliquées...

[Just-Soft]

je ne peux que reconnaître que son code est plus fiable que le mien Mais je continue à travailler comme je le fais...ou à dériver les composants pour leur ajouter les propriétés dont j'ai besoin car je sais ce que je fais

si je peux, qu'entend-tu par fiable maître Paul TOTH ?

[Paul TOTH]

si je peux, qu'entend-tu par fiable maître Paul TOTH ?

et bien son code utilise strictement les données comme étant ce qu'elles sont...un entier dans un entier, un objet dans un objet.

Dans mon cas je pars du principe que les deux sont compatibles, ce qui n'est pas forcément le cas si Tag passe en 64bits et pas Data

De la même façon j'utilise intensivement les string comme buffer binaires, car un "array of byte" est moins simple à manipuler qu'un string (copy, pos, +, etc...)...sauf qu'avec Delphi 2009 le string passe en unicode et le char sur 16bits, ce qui rend mon code incompatible

[Just-Soft]

donc, c'est plus une question de compatibilité et de portabilité !

[Paul TOTH]

donc, c'est plus une question de compatibilité et de portabilité !

oui tout à fait

[LadyWasky]

J'ai regardé les deux exemples tu as donné et je dois te dire que :
- Pour les mêmes aisons de "compatibilité" je préfère de loin coder comme ton collègue.
- Mais par contre, "caster" d'un type énuméré en type entier ou de caster un pointeur en cardinal, ça, ça m'arrive assez souvent.
- Les pointeurs me sont tout de même bien pratique de temps en temps
(Bon sur mon Oric Atmos sur lequel je développe en C, j'en ai utilisation systématique)
- Et même l'assembleur m'aide bien aussi l'occasion quand je souhaite travailler chaque bit de mes octets !

[Paul TOTH]

J'ai regardé les deux exemples tu as donné et je dois te dire que :
- Pour les mêmes aisons de "compatibilité" je préfère de loin coder comme ton collègue.
- Mais par contre, "caster" d'un type énuméré en type entier ou de caster un pointeur en cardinal, ça, ça m'arrive assez souvent.
- Les pointeurs me sont tout de même bien pratique de temps en temps
(Bon sur mon Oric Atmos sur lequel je développe en C, j'en ai utilisation systématique)
- Et même l'assembleur m'aide bien aussi l'occasion quand je souhaite travailler chaque bit de mes octets !

non moi je préfère de loin dériver l'objet que j'utilise et lui ajouter des propriétés

exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
type
// dérivé classique
  TMyNode = class(TTreeNode)
    FValue : Integer;
  end;
 
// astuce pour dériver les TButton du DFM sans ajouter le composant à la palette :)
  TButton = class(StdCtrls.TButton)
    FNode: TMyNode;
  end; 
 
  TForm1 = class(TForm)
     Button1 : TButton;
     ...
  end;
 
procedure TForm1.Button1Click(Sender : TObject);
begin
  Button1.FNode := TMyNode.Create(TreeView1);
  Button1.FNode.FValue := 1;
end;

[LadyWasky]

Alors là, c'est du grand Paul !
C'est vraiment très fort cette astuce, je n'y aurais jamais pensé.

Je suis certain que ça va me servir un jour !
J'en reviens pas... Ca fait longtemps que tu as fait cette "trouvaille" ?
C'est le genre d'astuce à la fois simplissime et complètement tordue que j'affectionne.

Ha non, il n'y a pas à dire, c'est du grand art.

[LadyWasky]

Rhooooooooooooo le délire...... j'en reviens toujours pas. (du coup je reviens et en remet une couche)
Si évident ! Je n'aurais jamais osé, si tant est que ça m'aurait traversé l'esprit, de "masquer" la classe originale de l'unité "parente" en la redéfinissant avec le même nom.

J'ai fait ça des milliers de fois avec les types énumérés pour les "étendre" (comme on fait pour rajouter des couleurs dans les propriétés publiées de type TColor par exemple).

J'en reviens pas dites donc, je me coucherais moins bête ce soir !

[Paul TOTH]

Alors non, ça fait pas très longtemps que j'ai découvert ça (proportionnellement au temps que j'ai passé sur Delphi)

mais c'est ce que j'utilise dans SIPInside pour redéfinir le look des boutons par exemple le bouton CONNEXION de l'image est un vrai TButton.

Dans de précédentes versions j'utilisais des TLabel et autre TBevel, visuellement le résultat est le même...sauf pour les non voyants Les "lecteurs d'écrans" utilisés par le non voyants nécessites de vrais composants Windows et non des TGraphicControl qui sont juste "visuels" justement

[Lung]

Alors là, c'est du grand Paul !
C'est vraiment très fort cette astuce, je n'y aurais jamais pensé.

Je suis certain que ça va me servir un jour !

+1

[Franck SORIANO]

Nous on a migré notre appli de Paradox vers une solution SGBD de cette façon :
On a définit nos propores composants pour remplacer ceux du BDE, en leur donnant le même nom que les composants BDE.
Ensuite dans chaque fichier source, il suffit de faire le uses de nos nouvelles unités après celui des unités du BDE, et tu remplaces d'un coup tous les composants BDE par les tiens....
En plus il suffit de faire un IFDEF dans les unités de tes composants perso pour les désactiver et tu recompiles une version Paradox...
Il faut juste faire attention à ce que tes compos soient 100% compatibles avec ceux que tu remplaces, surtout au niveau du DFM.

Mais bon, ça marche mais c'est quand même un coup à tout planter...

[anapurna]

salut

ca fait toujours plaisir de voir que personne ne lit vos reponse ;(

classe-portant-meme-nom-unites-differentes/

@+ Phil

[LadyWasky]

salut

ca fait toujours plaisir de voir que personne ne lit vos reponse ;(

classe-portant-meme-nom-unites-differentes/

@+ Phil

Bah c'est pas ça, c'est que j'étais juste passé à côté de ce fil de discussion sans le voir ! (pas vu, pas pris ! ).
Dans ce cas bravo à toi
C'est vraiment une super astuce. Parcontre, quand tu dis que c'est juste une figure de style, permet moi de te dire que c'est vraiment plus que ça. Ca peut quand même avoir une sacrée utilité cette trouvaille.

[exoseven]

je l'utilise aussi

je l'avais trouvé là sa section hack est intéressante à lire pour la culture générale

[Just-Soft]

Salut;

jamais imaginé que la discussion "pointeur et objet" convergerait vers tout ça mais vraiment bravo à tous.

[dragonno]

Salut^^
Hihi moi je suis débutant de chez débutant hein mais comme c'est beaucoup la création de jeux qui m'interesse, le fait de pouvoir créer les personnages en "objet" et pouvoir y accéder par des pointeurs j'ai lu quelque part que ç'était plus pratique, donc vive les pointeurs .