Yo,
Dans des TAD, pour simuler des membres privés façon objet, est ce que ça vous choque d'avoir ceci :
?Code:
1
2
3
4
5
6
7
8
9
10
11 struct xyz { const char * champ_public1; int champ_public2; struct { char * ptr1; void * ptr2; } __private; };
Version imprimable
Yo,
Dans des TAD, pour simuler des membres privés façon objet, est ce que ça vous choque d'avoir ceci :
?Code:
1
2
3
4
5
6
7
8
9
10
11 struct xyz { const char * champ_public1; int champ_public2; struct { char * ptr1; void * ptr2; } __private; };
Ben, vu qu'avec un ATD bien concu, la structure des donnees n'est de toute facon pas disponible pour l'utilisateur, je ne vois pas trop l'interet...
Ah merde, c'est vrai
En fait je voulais pas vraiment parler de TAD, mais de simples structures
Je m'apperçois que certaines personnes sont partisanes de ne pas creer une fonction pour chaque operation, de laisser l'utilisateur acceder aux champs. Si la structure est const, on ne pourrait pas modifier les champs, c'est deja ça (enfin si les champs sont des scalaires).
En y reflechissant, c'est parfois plus simple de pas avoir d'accesseurs.
En fait, c'est un probleme recurrent, pouvoir avoir dans la structure la resource liberable et à la fois la meme resource mais en lecture seule, pour l'utilisateur.
Bon bein j'ai ma réponse : oui c'est choquant, il faudrait faire des accesseurs
:cry: A lire d'urgence :Citation:
Envoyé par Gruik
http://emmanuel-delahaye.developpez.com/tad.htm
Mais c'est bon, je connais..
Avoir une structure ne signifie pas qu'on va en faire un TAD à part entiere, c'est juste que j'ai mal choisi mes termes dans ma premiere question.
Comme qd tu dis "Une expression booléenne retourne 0 ou 1. Le reste c'est du pipeau", je suis en droit de dire "une structure est un type permettant d'agréger plusieurs variables en une seule variable, le reste c'est du pipeau."
Ya qu'a voir la librairie standard du C (struct tm, struct stat)
Ne pas confondre TAD (FILE, par exemple) et structures applicatives (celles que tu as cité ou div_t, par exemple).Citation:
Envoyé par Gruik
Tout est une question de conception. Il faut bien séparer ce qui est de l'implémentation pure (TAD) de ce qui est de l'application (structures 'visibles' et documentées).
Tu remarqueras que les champs de struct tm sont parfaitement définis (avec un joli préfixe tm_) et documentés, alors que rien n'est dit de FILE, dont on ne sait même pas si c'est une structure ou une banane magique.
Et pour répondre à ta question initiale, il n'y a aucune raison d'avoir des 'membres privés' dans une structure (ou alors des TAD).
Je m'étais fourvoyé dans cette mauvaise voie quand j'ai commencé ma CLIB/ED (il en reste quelques traces), et j'ai vite adopté la séparation en TAD/ structures, comme il se doit. Ne pas se laisser influencer par les pratiques curieuses d'autres langages... (j'espère ne pas avoir fait pété le troll-o-meter).
Oui effectivement, mon erreur était de vouloir melanger les 2