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 !