TAD et POD: lever le doute

Salut,

Il y a quelques temps, une discussion a introduit en moi un doute que je souhaiterais lever.

J'ai toujours considéré les TAD (Types Abstraits de Données) comme étant un synonyme de "type définis par l'utilisateur", et, donc, pour moi, est TAD l'ensemble des types excepté les types primitifs.

De son coté, un type POD est un type composé exclusivement de données contigues en mémoire, au même titre que:

• les type primitifs
• les structures et unions "C style" (dans lesquelles aucune fonction membre n'est définie)

De mon point de vue, tous les POD (exception faite des types primitifs) seraient des TAD mais seuls les type primitifs ou contenant exclusivement des type POD sont des types POD.

Mais voilà, j'aurais aimé avoir confirmation que mon point de vue est correct, et, si ce ne devait pas être le cas, j'aurais aimé savoir où mon raisonnement est erroné ;)

A vous de jouer :D

Pour moi, la définition de TAD se rapproche plus de celle de "type opaque", ou de tout type associé à des fonctions.

En clair, ça serait plutôt tous les types non-POD, car un simple POD n'a rien d'abstrait.
Le problème, c'est que POD au sens C++ signifie juste "sans constructeur dans la classe" si je me souviens bien, ce qui rend ces déclarations orthogonales: On pourrait tout-à-fait faire une classe sans constructeur, mais qui resterait plus ou moins opaque (tout son contenu privé, accès uniquement par des fonctions membres, etc.).

Les PODs ce n'est qu'une classification un peu barbare des types.
C'est pas tellement malin.

Il vaut mieux privilégier des propriétés comme "peut se copier bit à bit" à "est un POD".
C'est d'ailleurs vers ça qu'on essaie de se diriger aujourd'hui.

POD, cela veut juste dire compatible avec le C. Et comme le dit loufoque, c'est lié à la façon de copier, mais aussi à l'alignement, etc.

Les TADs..., je les ai toujours associés à "générique". Le premier exemple de TAD que l'on m'avait montré, c'était la pile. La Pile stocke des éléments d'un type E, et fourni un certain nombre d'opérations dessus (push, top, pop, empty) et qui sont décrites avec le type E des éléments.

A relire wikipédia, je vois qu'il s'agit d'une spécification (mathématique) de l'interface d'un type, son abstraction. On ne s'intéresse pas au comment. juste au contrat.

Prenons les nombres flottant, il existe plusieurs spécifications IEEE de format. Mieux int, d'une machine à l'autre son format exact diffère. Pourquoi ne pourrait-il pas être vu comme un ADT ? Il est simple de spécifier mathématiquement les opérations qui s'y rapportent, non?. Et on ne s'intéresse pas vraiment à son implémentation, d'autant qu'elle est changeante.


Bref. Pour moi, TAD et POD sont deux concepts orthogonaux.

EDIT: Cela fait longtemps que l'on réalise des POD de listes et autres piles en C, et quel plus bel autre exemple TAD que FILE? Bref, il y a quantité de TAD en C, et vu que tous les types C sont des POD ...

Je tiens d'abord à vous remercier tous de vos réponses, et à vous présenter mes excuses pour ne pas avoir répondu plus tôt

Citation:

---

Envoyé par Médinoc

Pour moi, la définition de TAD se rapproche plus de celle de "type opaque", ou de tout type associé à des fonctions.

---

Nous sommes effectivement d'accord pour dire que les types qui ne sont utilisables qu'au travers de fonctions et dont nous n'avons accès à aucun membre sont des TAD mais...

Citation:

---

En clair, ça serait plutôt tous les types non-POD, car un simple POD n'a rien d'abstrait.

---

nous ferait presque nous poser la question de la limite dans laquelle nous considérons quelque chose comme concret...

En effet, je pourrais presque justifier le fait que

Code:

---

1 2 3 4 5 6

struct Personne { char nom[20]; char prenom[20]; int age; };

---

est une vue bien trop restrictive de ce qui fait une personne pour estimer que, bien qu'il s'agisse d'un POD, il s'agit aussi... d'un type abstrait...

Citation:

---

Le problème, c'est que POD au sens C++ signifie juste "sans constructeur dans la classe" si je me souviens bien, ce qui rend ces déclarations orthogonales: On pourrait tout-à-fait faire une classe sans constructeur, mais qui resterait plus ou moins opaque (tout son contenu privé, accès uniquement par des fonctions membres, etc.).

---

Mais là, nous allons vers le problème de l'ajout implicite - par le compilateur - des constrcteurs (par défaut et par copie), de l'opérateur d'assignation et du destructeur à toute structure pour lesquelles ils ne sont pas explicitement déclarés par le "codeur"...

Cela voudrait-il dire qu'il n'est plus possible de disposer de POD en C++ :question:, ou faut il rajouter - au minimum - la notion "explicitement déclaré par l'utilisateur" :question: ou encore est-ce la présence de fonction explicitement définie dans une structure qui fait que nous ayons un TAD non-POD :question:

Citation:

---

Envoyé par loufoque

Les PODs ce n'est qu'une classification un peu barbare des types.
C'est pas tellement malin.

Il vaut mieux privilégier des propriétés comme "peut se copier bit à bit" à "est un POD".
C'est d'ailleurs vers ça qu'on essaie de se diriger aujourd'hui.

---

Peut être...

Mais cela ne répond pas à ma question: peut on considérer les POD comme des TAD :question::aie:

Or, si je la pose sous cette forme, c'est parce que j'ai besoin d'une comparaison cohérente des deux concepts représnetés :aie:

Citation:

---

Envoyé par Luc Hermitte

POD, cela veut juste dire compatible avec le C. Et comme le dit loufoque, c'est lié à la façon de copier, mais aussi à l'alignement, etc.

Les TADs..., je les ai toujours associés à "générique". Le premier exemple de TAD que l'on m'avait montré, c'était la pile. La Pile stocke des éléments d'un type E, et fourni un certain nombre d'opérations dessus (push, top, pop, empty) et qui sont décrites avec le type E des éléments.

A relire wikipédia, je vois qu'il s'agit d'une spécification (mathématique) de l'interface d'un type, son abstraction. On ne s'intéresse pas au comment. juste au contrat.

Prenons les nombres flottant, il existe plusieurs spécifications IEEE de format. Mieux int, d'une machine à l'autre son format exact diffère. Pourquoi ne pourrait-il pas être vu comme un ADT ? Il est simple de spécifier mathématiquement les opérations qui s'y rapportent, non?. Et on ne s'intéresse pas vraiment à son implémentation, d'autant qu'elle est changeante.


Bref. Pour moi, TAD et POD sont deux concepts orthogonaux.

EDIT: Cela fait longtemps que l'on réalise des POD de listes et autres piles en C, et quel plus bel autre exemple TAD que FILE? Bref, il y a quantité de TAD en C, et vu que tous les types C sont des POD ...

---

Donc, tu serais proche de mon avis: si tout POD est un TAD, l'inverse n'est pas forcément vrai, en fonction de la capacité que l'on a de copier bit à bit l'objet :question:

Un POD c'est une classification clairement définie que le C++ utilise pour spécifier certains trucs.
Un TAD c'est une classification variable que certaines personnes ont inventé, et qui s'adapte en fait pour vouloir dire ce que tu veux.

Bref, ce sont deux choses qui n'ont rien à voir.

Citation:

---

Envoyé par koala01

Donc, tu serais proche de mon avis: si tout POD est un TAD

---

Je suis plutôt de l'opinion inverse. Un TAD est défini par les opérations possibles sans qu'on s'occupe de la représentation (le plus proche en C++ serait les concepts, qu'ils soient informels comme dans la version actuelle ou intégré au langage comme dans la version en préparation), la caractéristique essentielle d'un POD c'est d'avoir une représentation compatible avec le C.

En passant, les types opaques ne sont pas des types abstraits, c'est d'utilisation d'un ou plusieurs mécanismes du langage en vue de ne manipuler des types concrets que par l'interface présentée par le TAD qu'ils implémentent.

Citation:

---

Envoyé par loufoque

Un TAD c'est une classification variable que certaines personnes ont inventé, et qui s'adapte en fait pour vouloir dire ce que tu veux.

---

Je ne suis pas sûr que ce soit une terminologie aussi variable que tu l'entends. La définition de Wikipédia telle que citée par Luc est celle d'Aho dans un bouquin de 83 et correspond de très près à l'usage que j'en ai vu.

En fonction des langages, le même type peut être primitif ou "abstrait".